冷启动加载耗时长？

Question

应用在设备上冷启动打开加载完成耗时XXXXms

Answer 1

使用工具

DevEco Studio-Profiler-Launch

定位过程回放

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

   

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

   

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

4. 选中右侧数据展示区的Frame泳道，看到render\_service卡顿18次，卡顿占比4.9%；桌面应用卡顿4次，卡顿占比12.1%；应用卡顿5次，卡顿占比10%

   

5. 双击render\_service行，在FrameList视图中，逐行点击，看到render\_service的7处卡顿都与应用有关

   

6. render\_service还有7处卡顿与桌面应用有关，由于桌面应用的卡顿不在分析范围内，优先分析应用的卡顿

7. 返回Statistics视图，双击m.kugou.hmmusic行，在FrameList视图中，先排查Duration 82ms耗时最长的这一帧。点击右侧的跳转图标

   

8. 再继续点击跳转

   

9. 跳转完成后会直接定位到卡顿帧，左侧的白线是期望开始时间，右侧的白线是期望结束时间，很明显实际结束时间远远超出了期望结束时间。

   

10. 选中这一帧的时间区间，点击ArkTS Callstack泳道，可以看到代码执行耗时

    

11. initialRenderView，表示各个页面的初始化，耗时超过了36ms，展开可以看到具体是哪些页面初始化耗时长。

    

12. （program）代表程序执行进入纯native代码阶段，该阶段无JS代码执行，也无JS调用native或者native调用JS情况。需要切换到Native Callstack泳道看具体的调用栈信息 Native Callstack是按照线程来组织堆栈的，这里也看不出什么，就先放在这里。

    

13. rerender主要发生在页面更新的场景，耗时超过4ms，展开可以看到耗时主要发生在forEach+isElse循环渲染更新，耗时2ms 899μs。

    

14. aboutToAppear的耗时主要集中在display.getDefaultDisplaySync这个接口，耗时2ms+

    

15. （BUILTIN）表示JS标准库接口，Native实现，虚拟机提供，总耗时2ms 367μs，其中onPageStateChanged耗时2ms 111μs，可见耗时集中在index.ets文件中的onPageStateChanged函数。

    

16. 整体看了一遍，大概可以判断，主要耗时集中在initialRenderView（组件初始化）和rerender（组件更新），根据经验判断，（program）耗时长大概率也是因为组件创建更新导致的（组件创建更新主要靠arkUI引擎来完成，发生在native侧），所以我们把分析重点放在组件创建更新。

17. 回到initialRenderView，首先分析耗时最长的Special.ets文件，从下图可以看出来，Special.ets文件加载耗时长的原因是状态变量发生了变化。下面以标记①为例：

    完全展开后，双击（ARKUI\_ENGINE）行可以直接跳转到源码文件，很方便分析具体是哪里引起了耗时长