鸿蒙开发5.0ArkUI启动【冷启动过程最大连续丢帧数问题】分析思路&案例

1. 场景导入

冷启动过程最大连续丢帧数：应用冷启动时，从点击应用离手开始到应用界面铺满全屏（启动页图标铺满全屏）这一段时间内的最大连续丢帧数称为冷启动过程最大连续丢帧数。

2. 性能指标

2.1 性能指标介绍

冷启动过程最大连续丢帧数的预期为动效环节0帧，加载环节6帧。冷启动过程只涉及动效环节。不同过程可能有差异，具体以测试标准为准。

冷启动过程最大连续丢帧数即在冷启动过程中的最大连续丢帧数，其性能衡量的起点为用户点击应用图标离手帧时间，止点为应用启动页图标铺满屏幕的首帧时间。

如果应用存在广告，则性能衡量方式有两种：

1. 离手帧到广告铺满全屏首帧作为性能衡量起止点。
2. 离手帧到应用启动图标铺满全屏首帧（减去广告时间）作为性能衡量起止点。

3. 问题定位流程

3.1 常规定位前置流程

3.1.1 查看操作录屏辅助定位

应用遇到问题时，可以优先查看操作录屏，查看操作场景，看能否发现一些有助于定位的信息，比如应用启动是否有明显卡顿，白屏等等。

3.1.2 Trace 抓取

冷启动过程最大连续丢帧数Trace抓取请参考【附录1: 冷启动Trace抓取方法】

3.2 问题定位思路

冷启动过程丢帧类问题的通用定位思路为先确认时延起止点，然后看起止点范围内的丢帧情况，未超过则说明达标，超过则根据Trace信息进一步确认问题点，确认责任领域并对齐处理，处理流程如下图：

3.2.1 确认起止点

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

起点Trace查找顺序：H:DispatchTouchEvent type=1（大桌面ohos.sceneboard） -> CPU Running Trace（多模子系统mmi_service）-> H:service report（多模子系统mmi_service）

1. 在大桌面泳道（ohos.sceneboard）搜索H:DispatchTouchEvent并且type&#