Android列表滑动卡顿分析与优化

一 目标

尝试解决首页 HomeFragment 在低端机型上滑动存在卡顿的问题。

二 测试设备

华为荣耀 9i

Android 8.0

内存 4G

CPU 麒麟659

三 数据采样

刚进应用存在 MainActivity 的其他四个 fragment 的初始化、二楼的初始化。以及一些网络请求和弹窗弹出会，这些开销会加剧此时滑动首页列表的卡顿，采集数据应该进入首页后静置 10 s

A 手动滑动体感:

1 B3 滑动时存在明显卡顿

2 刚刚进来时候滑动卡顿

PS： B3运营位以下简称 B3

B 工具采集:

profiler:

观察 CPU 开销 在页面静置的时候和滑动的时候 CPU 的开销波动最大呈锯齿状，在该设备上滑动列表时 CPU 最高占用约 60%

内存开销页面静置时内存开销为 357 MB 滑动页面时候为 385 MB 左右

内存波动较小

systrace:


我们可以看到为什么在低端机上产生卡顿，高端机型则不容易卡顿。systrace 给了我们最主要的答案

整个卡顿分为四个类型

a: Scheduling delay 调度延迟 CPU 分配不到算力，线程延时等待

b: Expensive measure/layout pass 昂贵的测量或者摆放

c: Long View#draw() view 的绘制

d: Expensive Bitmap uploads bitmap Bitmap 的上载

显而易见(右上角 Alert type) 129 + 47 + 25 +3 = 204

因为线程调度所产生的延时卡顿有 129 例。占比达 63.2% 也就意味着即使去优化 view 的绘制测量也只存在 37.8% 的优化空间

Scheduling delay 如何解决？

值得庆幸的是市面上低于我们测试设备的 CPU 算力的机型不多，另外我们如何从代码层面想办法做优化

我们来看这一帧的表现:

Fullinvalidate 为高亮蓝色

完成总耗时 227ms RV Fullinvalidate 就耗时 180ms

个人结论 ： 看描述 notifyDataSetChanged 应该是采集时上拉加载的时候产生的耗时，我们的首页上拉没有做局部刷新

如果局部刷新拉取出来的下一页应该就能对这种类型的帧耗时有很大程度上的优化解决。

还一个感受是同机型线上包为什么比测试包感觉流畅？

分析原因是:

CPU 在测试包下有部分运算和调度能力被内存泄漏检测工具 LeakCanary 占用导致原本低端机型的 CPU 在测试包下显得表现更差

B3 卡顿分析

即使是通过标志位的问题能够 100% 解决来回滑动 B3 卡顿的问题 ，但是也没办法解决刚刚进来第一次滑动 B3 的卡顿。因为第一次的初始化展示是必要的，我们可以观察上图看到

滑动 B3 那一帧所耗时 400ms 其中 B3 初始化的两个 fragment 占比 50% 以上。首次进来 B3 必须要展示呈现给用户，但是预加载的 fragment 那一页可以等待用户点击的时候再去

初始化这样在滑动 B3 的时候我们至少可以解决 25~30% 左右的卡顿

Android禁止ViewPager预加载方案

这个方案存在一定风险 需要修改 Android ViewPager 源码

四 卡顿分析

滑动过程中两次弹窗？

猜测可能的卡顿原因：

1 item 中频繁的 removeAllViews 和 addView

2 bindViewHolder 方法复用时绑定数据的设置匿名监听

3 检查代码中是否存在 findViewById 推荐使用框架 getView 方法优先取缓存

4 是否存在过度绘制

5 内存泄漏检测

6 内存中重复实例

leakcanary 所捕获的 B3 的内存泄漏

优化数据采集:

修改 viewpager 的源码风险太大。在 B3 运营位采用了 fragment 懒加载的方式在

onSupportVisible
的生命周期再去初始化和加载这个 fragment 的数据和 view 我们再抓一个 systrace

根据上图可以看到在优化之后滑动进入 B3 的时候卡顿时间由 之前的 392 ms 到现在的 120 ms ，八个卡片 view 的加载变成了四个卡片 view 的加载。优化的数据和每次抓 systrace 都不一样但是这种优化

方式也至少能把首页滑动的卡顿优化约 30%

最终优化效果:

1 通过 fragment 的懒加载方式优化的第一次下滑经过 B3 卡顿的 30%的耗时，但是这个也是存在代价的，因为是懒加载用户在点击 B3 的锚点的时候会不如之前的预加载快。

2 通过增加标志位，RecyclerView 卡片滑动复用的特性。B3 有且只有一个，请求接口后在当前城市数据不会再变更，这样实际 B3 在来回滑动的时候不再需要去复用了，通过这种方式

解决的 B3 非第一次加载时候的卡顿 100%