鸿蒙开发5.0【List滑动过程卡顿率问题】分析&案例

1. 场景导入

卡顿率是用来判断页面操作是否流畅的一个指标，可以衡量应用启动、页面内滑动、页面转场操作是否流畅。在应用内使用ArkUI的List组件实现的列表，在页面滑动过程中，通过卡顿率来判断页面滑动是否流畅。

2. 性能指标

期望上屏时间是和帧率有关，如120FPS，期望上屏时间为1000ms / 120FPS = 8.3m

2.1 性能衡量起止点介绍

以大于300mm/s的速度，连续3次，每次半屏。List组件的抛滑过程，可以通过应用进程下的H:APP_LIST_FLING泳道标识。性能衡量的起点为第一次抛滑开始点，衡量的结束点为第三次抛滑的结束点。

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

3. 问题定位流程

3.1 常规定位前置流程

3.1.2 查看操作录屏辅助定位

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

3.1.2 Trace 抓取

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

3.2 问题定位思路

滑动卡顿类问题的通用定位思路为先根据性能工厂的测试报告确认卡顿率是否达标。如果不达标则确认单次抛滑的起止点，在Present Fence泳道找到超时帧，根据Trace信息进一步确认问题点，确认责任领域并对齐处理，处理流程如下图：

3.2.1 确认起止点

问题起止点确认

参考[2.2 性能衡量起止点介绍](#2.2 性能衡量起止点介绍)

3.2.2 找问题点

3.2.2.1 判断卡顿帧进程

收藏Present Fence，H:APP_LIST_FLING，Frame泳道中的RS侧帧泳道和应用侧帧泳道。观察图形上屏超时是由应用侧帧超时引起的，还是由RS侧帧超时引起的。

应用进程问题

如下图，可以看到261，263，264帧耗时较长，最终264帧超时导致图形上屏时间超过了预期。

RS 进程问题

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

3.2.2.2 找丢帧Trace

点击卡顿帧查看详情，点击跳转应用进程

分析详细丢帧Trace

3.2.3