【鸿蒙性能优化】基于ArkUI的冷启动加载完成时延问题分析思路&案例

1. 场景导入

应用冷启动加载完成时延慢,主要表现为一直卡在启动页和应用的首页长时间加载渲染,影响用户体验。

2. 性能指标

2.1 性能衡量起始点介绍

冷启动加载完成时延的性能衡量的起点:点击应用图标离手冷启动加载完成时延的性能衡量的终点:应用的首页所有的占位符加载完成

3. 问题定位流程

3.1 常规定位前置流程

3.1.1 查看操作录屏辅助定位

处理三方应用问题时,可以优先查看操作录屏,查看操作场景,看能否发现一些有助于定位的信息,比如页面布局、加载网络的动画时间等等。

3.1.2 Trace抓取

滑动帧率Trace抓取请参考【附录1: 冷启动Trace抓取方法】。

3.2 问题定位思路

应用冷启动过程:①离手 到 应用响应。表现为:点击后,应用桌面的响应的快慢,参考: 85ms②应用启动阶段 。应用还未送帧,使用启动页来提高用户体验,异常表现为,铺满全屏的启动页停留时间过长。参考: 600ms③首页加载阶段。应用帧送显后,启动页动效消失,首页开始加载渲染,到首页的所有占位符加载渲染完成。参考:1000ms。

(注:当流程图为否时,该阶段表示符合标准不需要分析)

3.2.1 在Trace确认起止点

起点确认:

H:DispatchTouchEvent type=1(大桌面ohos.sceneboard) -> CPU Running Trace(多模子系统mmi_service)-> H:service report(多模子系统mmi_service)

  • 在大桌面泳道(ohos.sceneboard)搜索H:DispatchTouchEvent并且type=1(0,1,2分别代表按下,抬起,移动)的Trace点,该Trace点代表大桌面收到点击离手事件的Trace;

  • 然后找到多模子系统泳道(mmi_service),找到H:DispatchTouchEvent前的一个CPU Running Trace,该Trace下有一个H:service report touchId:{id}, type: up [id: 0, x:{X}, y:{Y}]的Trace点,该Trace点的X,Y坐标和H:DispatchTouchEvent是对应的,且类型也是up,代表的是多模子系统收到点击离手事件的时间,H:service report这个Trace开始位置就是起点。

终点确认:(trace没有对应的打点,需要借助数帧视频确定)

终点距离应用响应的时间(949ms) = 4.065s(终点) - 3.116s(响应的时间)

trace上关键打点:(如上图)启动页打点:H:LAUNCHER_APP_LAUNCH_FROM_ICON, com.ohos.sceneboard(render_service 这个泳道动效打点)启动页消失动效打点:H:StartingWindowExitAnimation,当收到应用进程的第一帧时,启动页通过改变透明度消失。

**应用启动阶段和首页加载阶段的分界点:**我们可以粗略的将H:StartingWindowExitAnimation的起点作为分界点,准确的分界点是 H:PageRouterManager::RunPage 之后,应用的绘制第一帧那个位置。大体也在H:StartingWindowExitAnimation的起点的位置。

3.2.2 找问题点

3.2.2.1 相应阶段

响应阶段相对整个启动流程耗时相对较小,参考85ms。

3.2.2.2 应用启动阶段

快速定位 启动阶段是否有异常,如果 H:StartingWindowExitAnimation的起点的位置在启动页打点 之后,说明应用启动阶段异常。表现为:启动页停留时间长

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值