冷启动加载耗时长,应用在设备上冷启动打开加载完成耗时XXXXms
应用在设备上冷启动打开加载完成耗时XXXXms
HarmonyOS
赞
收藏 0
回答 1
待解决
相关问题
HarmonyOS 如何统计应用冷启动耗时
393浏览 • 1回复 待解决
冷启动加载完成时延(离手帧为起始点)
753浏览 • 1回复 待解决
HarmonyOS hiappevent订阅的启动耗时事件中的冷启动、热启动详细的概念是什么?
134浏览 • 1回复 待解决
冷启动首帧完成时延问题分析
389浏览 • 1回复 待解决
冷启动加载慢问题定位三板斧
870浏览 • 1回复 待解决
如何提升应用冷启动速度?
455浏览 • 1回复 待解决
冷启动报错Error message
2076浏览 • 1回复 待解决
HarmonyOS Push点击冷启动跳转问题
420浏览 • 1回复 待解决
HarmonyOS冷启动相关性能分析
344浏览 • 1回复 待解决
#鸿蒙学习大百科#什么是应用的冷启动和热启动?
367浏览 • 1回复 待解决
HarmonyOS 设置冷启动的背景图
345浏览 • 1回复 待解决
"NAPI通信耗时长"导致丢帧分析
712浏览 • 1回复 待解决
UIAbility的冷启动过程是怎样的?
625浏览 • 1回复 待解决
#鸿蒙学习大百科#如何提升应用冷启动的速度?
300浏览 • 1回复 待解决
#鸿蒙通关秘籍# 如何应对冷启动响应时延超标导致的应用启动卡顿问题?
56浏览 • 0回复 待解决
冷启动性能指标起止点查找方法
810浏览 • 1回复 待解决
#鸿蒙学习大百科#如何定位应用冷启动缓慢的问题?
236浏览 • 1回复 待解决
#鸿蒙学习大百科#应用冷启动的流程是怎样的?
198浏览 • 1回复 待解决
#鸿蒙通关秘籍# 应用启动时如何优化大桌面时延以减少冷启动响应时间?
34浏览 • 0回复 待解决
#鸿蒙通关秘籍#如何使用lazy-import优化鸿蒙应用的冷启动性能?
44浏览 • 1回复 待解决
#鸿蒙通关秘籍#如何在鸿蒙应用中使用多线程优化冷启动性能?
56浏览 • 1回复 待解决
deeplink唤起其他应用在HarmonyOS上可行吗
366浏览 • 1回复 待解决
HarmonyOS 如何自定义App冷启动的闪屏页
798浏览 • 1回复 待解决
#鸿蒙通关秘籍#如何减少鸿蒙应用冷启动时首帧绘制的时间?
81浏览 • 1回复 待解决
#鸿蒙通关秘籍#如何让我的HarmonyOS应用在多个设备上协同工作?
98浏览 • 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)行可以直接跳转到源码文件,很方便分析具体是哪里引起了耗时长