wensonli / blog Goto Github PK

问题：
最近在开发分页加载列表时发现这样一个问题，在滑动到列表底部等待加载下一页后，
再向上滑动列表，此时会出现几次页面卡顿现象。

分析：
出现卡顿现象的根本原因是在UI线程上有耗时操作超过16ms，导致Choreographer 在同步时进行了丢帧处理。

那如何定位到是哪个耗时动作导致的呢？

使用TraceView工具，具体使用方法参考这篇博文。

使用TraceView 抓取日子后对总耗时排序，通过app的包名搜索关键字，定位到 2个耗时元凶。onBindViewHolder 40ms， onCreateViewHolder 120ms。

google描述这2个函数对耗时是敏感的。

1 优化onBindViewHolder.
这个函数原来会根据从网络获取不同的状态，判断是否显示和隐藏背景,通过ImageView.setBackgroundResource()。

因为背景不是动态获取的，所以优化为默认在ImageView中显示，通过setVisibility显示和隐藏ImageView.

优化后再次抓取TraceView,滑动列表是会不断触发onBindViewHolder, 但耗时只有1ms左右。 显示应该避免setBackground这种耗时操作。

那如果你确实需要加载不同图片呢？可以使用Glide等图片加载框架，在快速滑动时显示默认图片，待停止滑动后，再加载显示图片图片。

2 优化onCreateViewHolder
这个函数主要是LayoutInflater inflate布局xml文件。

那如何优化布局xml文件呢？

手机开启开发者选项，打开调试GPU过度绘制开关。发现列表页面是一片红色啊。
查看布局文件1是否有重复的背景设置，有就去掉， 2尽量降低布局的深度。优化后再次查看页面已经变为绿色了。

3 固定高度，避免重复计算高度 RecyclerView.setHasFixedSize(true);

经过上述优化后平均耗时由120ms降为60ms。但是还是没有解决上滑卡顿问题。笔者陷入是深深的思考。

笔者发现这样一个现象，首次进入列表页面时onCreateViewHolder平均耗时30ms左右，多页加载后上滑平均耗时为60ms左右。难道onCreateViewHolder对这两种场景会区分? 查看RecyclerView源码，不太可能。LayoutInflater inflate会有区分？也不可能。

最后想这应该和列表的数据有关，加载一页数据量变大，导致刷新的量变大了。于是查看adapter的刷新，发现统一调用了notifyDataSetChanged。Ok，查看函数注释发现这样一段话：
This event does not specify what about the data set has changed, forcing
* any observers to assume that all existing items and structure may no longer be valid.
* LayoutManagers will be forced to fully rebind and relayout all visible views.

显然卡顿的真正元凶是错误的使用notifyDataSetChanged导致了这个原因。

修改为当加载下一页时调用notifyItemRangeInserted，优化后发现下滑新一页时不再触发调用onCreateViewHolder。

卡顿的问题彻底解决。

但是当滑动到最后一页报异常了IndexOut异常，显示是notifyItemRangeInserted传的参数有问题导致的。
检查代码加断点，发现参数没有问题啊。

笔者再次陷入深深的思考，stackoverflow上也遇到类似的问题，有人建议使用notifyDataSetChanged。
这不是又回过去了!
最后定位到因为原来的列表底部有footer 加载item，所以notifyItemRangeInserted的startPostion 需要再加1.

最后，所有问题得到解决!

总结：
1 优化布局文件，降低布局深度，避免直接setBackground。
2 正确使用notifyDataSetChanged，notifyItemRangeInserted等函数。
3 出现问题时，首先想是不是自己的代码问题，而不是先去怀疑底层接口问题。