【鸿蒙性能优化】基于List的滑动过程卡顿率问题分析&案例

往期知识点整理

• 鸿蒙（HarmonyOS）北向开发知识点记录~
• 【鸿蒙性能优化】基于ArkUI的冷启动加载完成时延问题分析思路&案例
• 【鸿蒙性能优化】基于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 性能衡量起止点介绍

3.2.2 找问题点

3.2.2.1 判断卡顿帧进程

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

应用进程问题

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