性能优化套路实践 - 最近通话列表滑动流畅度例子

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检查问题，和代码的每次的执行时间有不一样的。误差范围内。

总结： 根据Incl Real Time进行从耗时时间从长到短排序，然后搜索关键字符串，找属于自己的代码的耗时方法，再看代码分析，优化即可。