鸿蒙开发5.0【List的滑动丢帧性能问题】分析思路&案例

1. 场景导入

基于ArkUI的List组件实现的滚动列表视图，在手指抛滑场景下，通过分析掉帧情况来判断List滑动是否流畅，保障用户极致流畅体验。

2. 性能指标

最大连续丢帧数：指从页面开始有响应变化到页面结束刷新的过程中，由于显示器画面刷新频率低于预设的画面帧率而未能正常呈现的最大连续帧数。一般而言，当连续值超过3时，用户可以明显感知到卡顿掉帧，数值越大卡顿时间越长。最大连续丢帧数越接近于0，用户流畅性体验越好。

2.2 性能衡量起止点介绍

以大于300mm/s的速度，连续3次抛滑，每次半屏。抓取滑动过程Trace，查看Frame泳道中应用进程和RenderService的最大连续丢帧数。

List组件的抛滑过程，可以通过应用进程下的H:APP_LIST_FLING泳道标识。性能衡量的起点为第一次抛滑开始点，衡量的结束点为第三次抛滑的结束点。

泳道	描述
H:APP_LIST_FLING	从手指按下开始拖动到抬手后的惯性滚动及最后尾动效的抛滑全过程。
H:touchEventDispatch	拖滑阶段，从手指开始拖动到抬起。
H:TRAILING_ANIMATION	抛滑尾动效阶段

Tip：尾动效阶段系统会进行降帧处理，所以如果要统计FPS情况，通常只会统计从抛滑开始到尾动效起点的这一阶段

3. 问题定位流程

3.1.1 查看操作录屏辅助定位

处理三方应用问题时，可以优先查看操作录屏，查看操作场景，看能否发现一些有助于定位的信息，比如卡顿的页面布局情况、卡顿的现象等等。

3.1.2 Trace 抓取

滑动帧率Trace抓取请参考【附录1: 滑动帧率Trace抓取方法】。

3.2 问题定位思路

滑动丢帧类问题的通用定位思路为先确认抛滑的起止点，然后看抛滑过程中最大连续丢帧数，如果大于0帧，则根据Trace信息进一步确认问题点，确认责任领域并对齐处理，处理流程如下图：

3.2.1 确认起止点

参考【2.2 性能衡量起止点介绍】

3.2.2 找问题点

3.2.2.1 判断丢帧进程

首先通过Frame泳道判断丢帧进程，其中绿色代表没有丢帧，其他颜色均为丢帧。其中“粉红色”代表该帧的期望时间，“红色”标识超时部分。

应用进程问题

如下图，应用进程连续丢了5帧，但可以看到只有261帧、263帧、264帧耗时较长，因此只分析这3帧即可。另外发现最后一帧序号也是264，这是因为前一帧耗时较长，导致该帧和前一帧都提交到了RS的264帧上，应用帧上的序号是被提交到的RS帧序号相对应的。

RS 进程问题

RS进程丢帧可能是应用进程导致的，如上图RS侧丢了1帧，但可以看到RS侧264帧丢帧原因是由于应用进程的264帧耗时较长，提交较晚导致。所以这种情况只分析应用侧丢帧原因即可。如果应用进程中没有丢帧且每帧耗时比较均匀，但是RS侧发生丢帧，则说明不是应用侧导致丢帧，此时只分析RS进程丢帧原因即可。

3.2.2.2 找丢帧Trace

选中Frame泳道，点击Statistics下面的应用进程右侧图标进入Frame List

过滤Jank Type为AppDeadlineMissed类型的帧，点击跳转应用进程。

详细分析丢帧Trace

3.2.3 根因分析方法

应用侧的渲染流程如下图所示，了解ArkUI的渲染流程有助于我们定位应用侧的卡顿问题出现在哪个环节

阶段	描述
Animation	动画阶段，在动画过程中会对相应的组件标记脏区
Events	事件处理阶段，比如手势事件处理。在手势处理过程中也会对组件标记脏区
UpdateUI	组件在首次创建或状态变量变更时会标记为需要rebuild状态，在下一次Vsync过来时会通过View的方法生成相应的组件树结构和属性样式修改任务。
Measure	执行组件的大小测算任务。
Layout	执行组件的布局任务。
Render	执行绘制任务，执行完成后会标记请求刷新RSNode绘制
SendMessage	将绘制数据提交到RS侧，请求刷新界面绘制

应用进程丢帧分析

跟据Trace图，初步分析耗时较长阶段。