基于ArkUI的冷启动加载完成时延问题分析思路&案例

📚往期笔录记录🔖：

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

1. 场景导入

应用冷启动加载完成时延慢，主要表现为一直卡在启动页和应用的首页长时间加载渲染，影响用户体验。

2. 性能指标

2.1 性能衡量起始点介绍

冷启动加载完成时延的性能衡量的起点：点击应用图标离手冷启动加载完成时延的性能衡量的终点：应用的首页所有的占位符加载完成

3. 问题定位流程

3.1 常规定位前置流程

3.1.1 查看操作录屏辅助定位

处理三方应用问题时，可以优先查看操作录屏，查看操作场景，看能否发现一些有助于定位的信息，比如页面布局、加载网络的动画时间等等。

3.1.2 Trace抓取

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

3.2 问题定位思路

应用冷启动过程：①离手 到 应用响应。表现为：点击后，应用桌面的响应的快慢，参考： 85ms②应用启动阶段 。应用还未送帧，使用启动页来提高用户体验，异常表现为，铺满全屏的启动页停留时间过长。参考: 600ms③首页加载阶段。应用帧送显后，启动页动效消失，首页开始加载渲染，到首页的所有占位符加载渲染完成。参考：1000ms。

（注：当流程图为否时，该阶段表示符合标准不需要分析）

3.2.1 在Trace确认起止点

起点确认：

H:DispatchTouchEvent type=1（大桌面ohos.sceneboard） -> CPU Running Trace（多模子系统mmi_service）-> H:service report（多模子系统mmi_service）

• 在大桌面泳道（ohos.sceneboard）搜索H:DispatchTouchEvent并且type=1（0，1，2分别代表按下，抬起，移动）的Trace点，该Trace点代表大桌面收到点击离手事件的Trace；

• 然后找到多模子系统泳道（mmi_se