冷启动加载慢问题定位三板斧

适用范围

•  冷启动加载慢、卡顿
•  首页加载慢、卡顿
• 应用或元服务冷启动响应时延 > 85ms
• 应用或元服务冷启动首帧完成时延 > 600ms
•  应用或元服务冷启动加载完成时延 > 1100ms

 应用或元服务冷启动过程最大连续丢帧数 > 0帧

1 排查

1.1 Launch场景录制

1. 在Profiler界面左侧选中测试应用，左下角选中Launch图标，点击Create Session；

2. 点击Launch任务的开始按钮，Profiler会自动杀掉应用进程并重新拉起新进程回放冷启动过程；

1. 应用启动成功，所有占位符都加载完成就可以停止录制。

1.2 看Frame泳道

1. 选中右侧数据展示区的

Frame泳道，看丢帧次数（Jank Count）和最大连续丢帧次数（Max Consecutive    Jank Count），以下图为例：render_service（ArkUI渲染服务）丢帧18次，最大连续丢帧3次；桌面应用（ohos.sceneboard）丢帧4次，最大连续丢帧2次；应用（m.kugou.hmmusic）丢帧5次，最大连续丢帧2次

2. 双击render_service行，在FrameList视图中，逐行点击，看render_service丢帧是自已引起的，还是由于其他应用丢帧引起的，如下图所示：render_service的丢帧与应用有关

1.3 看ArkTS Callstack泳道

2.2章节步骤2排查之后，会存在两种情况：

• render_service丢帧与应用有关
• render_service丢帧与应用无关

1.3.1丢帧与应用有关

如果在存在大量render_service丢帧与应用有关，

1. 回到Statistics视图，双击应用行，在FrameList视图中，优先排查耗时最长的这一帧。点击右侧的跳转图标

2. 再继续点击跳转

3. 跳转完成后会直接定位到卡顿帧位置，左侧的白线是期望开始时间，右侧的白线是期望结束时间，如下图所示：m.kugou.hmmusic帧实际耗时超过了期望耗时，m.kugou.hmmusic进程处理完成后，把数据传给了render_service进程（用一根箭头指向render_service帧表示），同时引起了render_service丢帧。

4. 在泳道上拖动鼠标左键，选中这一帧的时间区间，点击ArkTS    Callstack泳道，可以看到代码执行耗时

initialRenderView 表示页面初始化

(program) 代表程序执行进入纯native代码阶段，该阶段无JS代码执行，也无JS调用native或者native调用JS情况（需要切换到Native Callstack泳道看具体的调用栈信息，一般很难通过这里分析出有效的信息）。    

rerender 主要发生在页面更新的场景

(BUILTIN) 表示JS标准库接口，Native实现，虚拟机提

5.优先分析耗时最长的调用栈（program除外），逐级展开，双击（ARKUI_ENGINE）行可以直接跳转到源码文件，很方便分析具体是哪里引起了耗时长

1.3.2 render_service丢帧与应用无关

丢帧图形一般是这种形状：没有箭头指向render_service卡顿帧，并且render_service帧实际耗时超过了期望耗时

2 定界

2.1 render_service丢帧与应用无关

这种场景一般是由系统导致，需要系统侧排查

2.2 组件的build时间过长引起了丢帧

3 解决

冷启动的过程大致可分成下面四个阶段：应用进程创建和初始化、App和Ability的初始化、Ability生命周期、加载绘制首页，因此解决冷启动过程中产生的性能问题，主要也是围绕这4个阶段。