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

---

📚往期笔录记录🔖：

🔖鸿蒙（HarmonyOS）北向开发知识点记录~
🔖鸿蒙（OpenHarmony）南向开发保姆级知识点汇总~
🔖鸿蒙应用开发与鸿蒙系统开发哪个更有前景？
🔖嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~
🔖对于大前端开发来说，转鸿蒙开发究竟是福还是祸？
🔖鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？
🔖记录一场鸿蒙开发岗位面试经历~
🔖持续更新中……

---

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 性能衡量起止点介绍</