场景
一个他人开发的模块经测试反馈在数据量较多时加载速度很慢。
分析
- 检测接口返回
在大数据量下接口也能迅速返回结果，排除后台问题 - 主代码分析
简单分析主Activity文件未见明显问题。页面有列表，且在大数据量下问题明显，猜测listview问题。查看adpter view复用，果然未复用view，改之。然而并未明显改善问题。 - 将listview 的 item layout 优化，效果不明显
-
运行Android Profiler分析
进入Android Profiler 选择CPU监测。点击开始监测按钮，对APP进行操作，结束监测。
选择CPU.png
开始监测.png - 分析结果
选择Android Profiler底部的Call Chat 分析函数执行时间。对系统 API 的函数调用显示为橙色，对应用自有函数的调用显示为绿色，对第三方 API（包括 Java 语言 API）的函数调用显示为蓝色。主要关注绿色部分（具体含义参考 cpu-profiler）。onMeasure执行太长时间。
结果分析.png
滚动鼠标滚轮放大，发现调用了N多 getView方法，远超过当前屏幕显示的item数量，可分析Listview并没有缓存复用之前的View
很多getView.png
-
总结原因
分析代码，使用ScrollView 嵌套了自定义的Listview，Activity渲染的时候会将整个Listivew全部渲染，有多少项渲染多少个item view ，不慢才怪
自定义Listview.png - 改正
CoordinatorLayout + AppBarLayout + RecyclerView
