HarmonyOS鸿蒙Next中滑动卡顿场景一键定位神器：页面内滑动卡顿体检使用手册

HarmonyOS鸿蒙Next中滑动卡顿场景一键定位神器：页面内滑动卡顿体检使用手册

Harmony6.0鸿蒙应用体检工具重大升级，针对滑动卡顿场景开发者无需专业的trace分析知识，只需5分钟就能生成诊断报告，直接帮你找出影响滑动卡顿的耗时函数，定位效率极大提高。Harmony6.0体检诊断让每个人都成为应用性能专家。

第一章 申请版本

1. 访问“HarmonyOS 6 开发者预览版 Beta 定向招募”地址
2. 完善个人信息，并进行实名认证
3. 认证完成后点击“去填写”
4. 填写个人信息、职位、应用等信息
5. 填写完成后，点击“立即报名”即可
6. 提交成功后截图如下，在“我的活动”中查看报名状态，等待审核通过（2个工作日内核审核）
7. 审核通过后，在下载中心下载最新的DevEco Studio 6.0.0 Beta1版本即可

第二章 执行滑动检测

官方文档：

https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-zhenlv#section114240360418

1. 启动DevEco Studio，打开工程，连接手机。
2. 执行build操作，如果没有配置签名，请使用自动签名的功能配置签名。
3. 单击菜单栏Tools > AppAnalyzer，选择场景化检测、手动，勾选页面滑动。
4. 点击开始按钮，启动检测，检测过程中，手机需要保持解锁亮屏状态。
   • 工具会先对工程进行编译，安装到手机，并自动拉起应用。开发者不需要进行操作，在自动检测结束后会弹出提示手动操作。
5. 获得检测结果，下面列举了检测通过和未通过的示例。
   • 检测通过示例，如下图所示，无异常信息。
   • 检测未通过示例，例如下图结果，有多项检测未通过。
6. 点击左侧的菜单栏对应的选项，可以查看异常的具体信息。

第三章 分析滑动卡顿原因

官方文档：

https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-zhenlv#section117831333645

在UI线程应用自身方法耗时长检测区块体检工具会生成表格列出对滑动流畅影响最大的10个函数：

当开发者点击函数超链接，可以直接跳转到代码行，当开发者点击总耗时列的超链接，可以跳转到profiler并看到函数内部Callstack泳道。开发者可以根据表格信息检视代码进行优化。

耗时函数的callstack可能有以下四种情况：

一、函数单次执行耗时长

如果上方表格里，该函数的单次调用耗时长（即表格中的平均耗时），说明是函数本身耗时长，开发者自行优化函数，将函数放到子线程或者进行缓存，开发者可参考其他主线程优化思路。

二、函数调用次数多

如果函数本身耗时不长，但是函数调用次数多（例如在高频回调里打日志等操作）

确认函数是不是每次都要调用，能否通过一些全局或者缓存的方式降低调用次数，避免高频回调，开发者可参考高频回调场景。

三、组件创建次数多

• 如果函数名initialRender调用次数过多，如下图所示：

  此时需要点击总耗时列的超链接，打开trace向前排查主线程是否有阻塞。如下图所示：两帧之间出现空洞，说明为主线程阻塞的问题。

  解决方案：由于业务需求，需要加载的数据总量和绘制的组件数量是不能减少的时候，那么就可以考虑采用缓存，并行化之类的方案，开发者可参考其他主线程优化思路。

• 如果向前排查主线程没有阻塞，并且过多的listitem都出现在onIdle阶段。

  开发者可以排查list是否设置了过大的CacheCount，可参考缓存列表项。

• 如果既没有出现主线程阻塞，也没有设置过大的CacheCount，initialRender的总耗时仍然过高（比如120帧刷新率下超过了8.3ms），就需要考虑使用组件复用，开发者可参考组件复用和基于ScrollComponents实现瀑布流。

四、组件销毁次数多

如果函数名aboutToBeDelete调用次数过多，如下图所示：

此时也需要点击总耗时列的超链接，打开trace向前排查主线程是否有阻塞。如下图所示也是因为前面的主线程阻塞导致的，因为destroy只会发生在idle，如果主线程阻塞一直没有idle，就会积压；

解决方案：可以采用并行化，或者缓存的方式来优化业务逻辑。开发者可参考其他主线程优化思路。