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

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

HarmonyOS
2024-05-28 22:43:42
浏览
收藏 0
回答 1
待解决
回答 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)行可以直接跳转到源码文件,很方便分析具体是哪里引起了耗时长

分享
微博
QQ
微信
回复
2024-05-29 23:53:23
相关问题
HarmonyOS 如何统计应用冷启动耗时
393浏览 • 1回复 待解决
冷启动首帧完成时延问题分析
389浏览 • 1回复 待解决
冷启动加载慢问题定位三板斧
870浏览 • 1回复 待解决
如何提升应用冷启动速度?
455浏览 • 1回复 待解决
冷启动报错Error message
2076浏览 • 1回复 待解决
HarmonyOS Push点击冷启动跳转问题
420浏览 • 1回复 待解决
HarmonyOS冷启动相关性能分析
344浏览 • 1回复 待解决
HarmonyOS 设置冷启动的背景图
345浏览 • 1回复 待解决
"NAPI通信耗时长"导致丢帧分析
712浏览 • 1回复 待解决
UIAbility的冷启动过程是怎样的?
625浏览 • 1回复 待解决
冷启动性能指标起止点查找方法
810浏览 • 1回复 待解决