HarmonyOS鸿蒙实战（ Beta6版）应用冷启动完成时延问题实践指南

应用启动可以分为冷启动和热启动：

• ​冷启动：当应用启动时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用， 这种启动方式就叫做​冷启动。
• 热启动：当应用程序已经在后台运行，此时用户再次打开应用程序时，应用程序仍然在内存中，可以直接从内存中加载并继续之前的状态，而不需要重新初始化和加载资源，这种称为热启动。

冷启动首帧完成时延：指的是应用冷启动时，从点击离手开始到应用进程首帧送显上屏显示的这一段时间，称为冷启动首帧完成时延。

冷启动首帧完成时延的参考值为680ms，在定位冷启动时延相关问题时可以将此作为性能是否达标的一个参考。

性能参考起止点介绍

冷启动首帧完成时延的性能衡量的起点为用户点击应用图标离手点时间，止点为应用首帧送显的时间。

注意：如果应用启动时存在广告，需要减去广告时间，即冷启动首帧完成时延计算要去除广告时间。

问题定位思路

冷启动首帧完成时延问题的通用定位思路为先确认时延起止点，然后看起止点时延是否超参考值680ms，未超过则说明达标，超过则根据关键Trace信息将时延区间分为七个阶段：

1. input阶段（参考值：8ms）。
2. TP事件分发（参考值：15ms）。
3. 触发应用启动（参考值：20ms）。
4. 进程创建（参考值：15ms）。
5. 应用加载（参考值：15ms）。
6. Ability资源加载界面布局（参考值：500ms）。
7. 首帧渲染显示（参考值：20ms）。

分析时，优先看第6阶段Ability资源加载界面布局是否超过参考值500ms（应用进程耗时），如果超过则根据应用进程Trace信息分析耗时原因，并和应用侧对齐处理。如果是其他阶段耗时超过参考值，则根据实际情况找到耗时Trace并和对应领域对齐是否存在问题（通常情况下都是应用侧耗时导致超标，其他阶段可视情况是否需要分析），处理流程如下图：

确认起止点

冷启动首帧完成时延起点确认：冷启动首帧完成时延的起点是多模子系统收到硬件传递过来的离屏信号的Trace开始点。

起点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_service），找到H:DispatchTouchEvent前的一个CPU Running Trace，该Trace下有一个H:service report touchId:{id}, type: up [id: 0, x:{X}, y:{Y}]的Trace点，该Trace点的X，Y坐标和H:DispatchTouchEvent是对应的，且类型也是up，代表的是多模子系统收到点击离手事件的时间，H:service report这个Trace开始位置就是起点。

冷启动首帧完成时延止点确认：冷启动首帧完成时延的终点是应用进程启动后的第一帧。

在应用进程中找到首个H:ReceiveVsync Trace点代表应用进程启动后收到的首个垂直同步信号，这里就会开始绘制应用的首帧。

<