1 减少过渡绘制
Item的过度绘制
不存在过度绘制，Item的布局的也不存在过度绘制
1. 自定义 View 时重写 hasOverlappingRendering 方法返回false。
无自定义View
2 布局优化
2.1 减少布局的嵌套层级
原则:
1，用RelativeLayout减少嵌套的层级。
2，同等层级情况下可以实现的选用LinearLayout而不是RelativeLayout。
item的的布局
就一层嵌套，这样的布局也不能用LinearLyaout来布局，所以嵌套层级无需优化。
2.2 当某些UI满足某种条件才显示复杂UI就用ViewStub
无满足某种条件才显示的复杂UI。这条无需优化。
2.3 有些大像素有规律的图片用.9去代替
无大像素有规律的图片，这条无需优化。
2.4 去掉无用的UI
无无用的UI。这里无需优化。
2.5 合并布局，用TextView代替图片加文字
虽然图片加文字可以合并的，但是那个图片是自定义View，合并改变代码过多。改了也不会带来特别大的性能好处。可以忽略。
3 分析代码耗时情况
3.1
onCreateViewHolder方法
找到一个耗时函数，看他的方法内容，inflate方法占了大部分，这个是就是加载Item的布局。但是我们的布局已经改成一层嵌套了。所以这布局无法再改了。
3.2
onBindViewHolder方法
这方法里面的bindCallLogListViewHolder()方法耗时。
点bindCallLogListViewHolder方法（76序号）
bindCallLogListViewHolder方法
看得出来，前面的这三个方法耗时。那么我们一一分析这个三个方法。
先看setPhoneCallDetails，点104序号的setPhoneCallDetails方法。
setPhoneCallDetails方法
同上序号147的setPhoneCallDetails和序号161getCallDescription耗时。
一直往下跟，跟到join这个方法。
join方法
BidiFormatter.unicodeWrap耗时。
代码是这样的：
join方法
得知道这个代码的作用是干啥的?
BidiFormatter.unicodeWrap的作用
那不是说不能改了吗？
当然不是了。
TextView有一个属性可以专门解决这种问题:
setTextDirection(View.TEXT_DIRECTION_LTR)
所以上述代码就可以改成：
image.png
image.png
给Textiview设置setTextDirection(View.TEXT_DIRECTION_LTR)这个属性。
改好运行修改后的代码。生成.TraceView对比修改的结果。
搜索join看优化成果，
join优化前
join优化后
是不是没有了BidiFormatter.unicodeWrap的耗时了吗？这不是废话吗？注销掉了肯定会没有了呢？至于数据为什么好像比优化前要跟耗时。这是traceView检查问题，和代码的每次的执行时间有不一样的。误差范围内。
网友评论