鸿蒙开发5.0ArkUI启动【冷启动过程最大连续丢帧数问题】分析思路&案例

1. 场景导入

冷启动过程最大连续丢帧数:应用冷启动时,从点击应用离手开始到应用界面铺满全屏(启动页图标铺满全屏)这一段时间内的最大连续丢帧数称为冷启动过程最大连续丢帧数。

2. 性能指标

2.1 性能指标介绍

冷启动过程最大连续丢帧数的预期为动效环节0帧,加载环节6帧。冷启动过程只涉及动效环节。不同过程可能有差异,具体以测试标准为准。

冷启动过程最大连续丢帧数即在冷启动过程中的最大连续丢帧数,其性能衡量的起点为用户点击应用图标离手帧时间,止点为应用启动页图标铺满屏幕的首帧时间。

如果应用存在广告,则性能衡量方式有两种:

  1. 离手帧到广告铺满全屏首帧作为性能衡量起止点。
  2. 离手帧到应用启动图标铺满全屏首帧(减去广告时间)作为性能衡量起止点。

1

3. 问题定位流程

3.1 常规定位前置流程

3.1.1 查看操作录屏辅助定位

应用遇到问题时,可以优先查看操作录屏,查看操作场景,看能否发现一些有助于定位的信息,比如应用启动是否有明显卡顿,白屏等等。

3.1.2 Trace 抓取

冷启动过程最大连续丢帧数Trace抓取请参考【附录1: 冷启动Trace抓取方法】

3.2 问题定位思路

冷启动过程丢帧类问题的通用定位思路为先确认时延起止点,然后看起止点范围内的丢帧情况,未超过则说明达标,超过则根据Trace信息进一步确认问题点,确认责任领域并对齐处理,处理流程如下图:

2

3.2.1 确认起止点

​冷启动过程的起点确认:冷启动首帧完成时延的起点是多模子系统收到硬件传递过来的离屏信号的Trace开始点。

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

3

  1. 在大桌面泳道(ohos.sceneboard)搜索H:DispatchTouchEvent并且type=1(0,1,2分别代表按下,抬起,移动)的Trace点,该Trace点代表大桌面收到点击离手事件的Trace;
  2. 然后找到多模子系统泳道(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开始位置就是起点。

冷启动过程的止点确认: 即启动图标铺满全屏,找到ohos.sceneboard(大桌面进程)泳道下的H:LAUNCHER_APP_LAUNCH_FROM_ICON泳道。该trace点的终点就是冷启动过程的止点。

4

3.2.2 确认是否存在丢帧

确认冷启动过程起止点之后,圈出起止点范围,点击Frame泳道,在下方详情界面可以看到render_service泳道,ohos.sceneboard大桌面泳道,erviceAbility元能力泳道和应用进程泳道的丢帧情况,通过Max Consecutive Jank Count确定最大连续丢帧数 ,当存在大于****0 的值时,说明存在丢帧。之后通过分析trace进一步定界是系统侧问题(RS,大桌面,元能力)还是应用侧问题。系统侧丢帧交由系统侧分析,应用侧丢帧需进一步分析原因或找伙伴确认。(如何定界是系统侧问题还是应用侧问题见3.2.3)

5

3.2.3 确认问题,分析根因

冷启动过程的丢帧问题需要定位到问题点,确认是业务侧还是系统侧的责任领域即可,之后的根因分析由相应领域进行分析。

3.2.3.1 如何界定丢帧是否是应用侧导致

框选起止点范围后,点击Frame泳道,双击下方详情界面列表中的render_service数据可以看到RS线程丢帧时,正在进行中的线程(Preceding Flows),如图正在进行的线程是应用线程和大桌面线程,说明可能是应用线程或者大桌面线程导致RS线程丢帧。

6

根据上图分析出的进行中线程,双击下方详情界面列表中的大桌面线程数据查看大桌面丢帧,可以看到下一个线程(Following Flows),如图接下来要运行的线程是VSyncId为13594的RS线程,而不是丢帧的VSyncId为13625的线程,说明大桌面线程未导致RS线程阻塞。

7

根据上图分析出的进行中线程,双击下方详情界面列表中的应用线程数据查看应用线程丢帧,发现此时只有其自身线程在阻塞,且后续线程(Flowing Flows)就是丢帧的VSyncId为13625的RS线程,说明是应用线程阻塞导致了RS线程阻塞,即丢帧是应用侧导致。

8

通过以上的定位思路确定应用侧丢帧,丢帧位置为VSyncId:8090的应用线程,点击标记1可以跳转其对应的应用线程。

9

查看相邻的渲染周期(搜索应用线程泳道中相邻的两个H:ReceiveVsync的Trace点),VSyncId:8090相邻的下一个Trace点是VSyncId:8093,周期不连贯,即为丢帧。

10

3.2.3.2 应用侧丢帧原因分析方法

根据3.2.3.1界定了丢帧是应用侧导致,然后分析丢帧范围内相邻渲染周期之间的应用线程泳道,查看其线程运行情况,界面布局,函数调用栈执行情况等。比如下图我们可以看到:卡顿帧内组件布局明显较别处多,且业务侧在做UI组件的flushlayouttask,怀疑是因为业务侧冷启动过程预加载时组件嵌套导致组件变量更新时相关组件同步更新渲染,计算量大,导致卡顿丢帧。

11

如果想了解更详细的冷启动过程最大连续丢帧数的Trace流程解读,见【附录2:应用进程VSync期间的关键Trace解读】

4. 常见根因归档

4.1 因窗口预加载导致冷启动过程最大连续丢帧数不满足预期

4.1.1 问题根因分析

应用冷启动过程最大连续丢帧1帧,不满足预期。通过以上的定位思路确定应用侧丢帧,丢帧位置为VSyncId:8090的应用线程,查看相邻的渲染周期(搜索应用线程泳道中相邻的两个H:ReceiveVsync的Trace点),VSyncId:8090相邻的下一个Trace点是VSyncId:8093,周期不连贯,即为丢帧。

12

框选以上两个相邻渲染周期,分析应用线程发现:耗时帧内组件布局明显较别处多,且业务侧在做UI组件的flushlayouttask,怀疑是因为业务侧组件嵌套导致组件变量更新时相关组件同步更新渲染,计算量大,耗时增加。优化建议:优化组件布局,倾向用扁平化布局,尽量少用多层嵌套;

13

结论:耗时帧内组件布局明显较别处多,且业务侧在做UI组件的flushlayouttask,怀疑是因为在冷启动过程中业务侧组件在做预加载,且组件嵌套导致组件变量更新渲染时的计算量大,导致卡顿。

4.1.2 优化方案

优化建议:优化组件布局,倾向用扁平化布局,尽量少用多层嵌套,同时可使用loading的方式给预加载提供足够的时间;

附录1. 冷启动Trace 抓取方法

​Step1 :​打开DevEco Studio的Profiler(下图1) -> 选择设备进程(下图2)-> Frame模式(下图3)-> Create Session(下图4)-> 启动录制(下图5)。

注意:第二步选择进程时不要选择要录制的进程,因为要录制的进程需要处于未启动状态,这里是通过录制其他进程间接录制目标进程的启动Trace 信息。

14

Step2: 启动录制后,在设备上点击应用图标启动要录制的目标应用,等到应用首页加载后,点击停止结束录制。

15

Step3 ​录制完成后会工具会分析展示Trace数据。

16

附录2 应用进程VSync 期间的关键Trace 解读

应用进程VSync期间的关键Trace解读:

17

序号泳道Trace描述
1应用线程H:OnVsyncEvent now: [时间戳]收到Vsync信号,渲染流程开始
2应用线程H:FlushVsync处理用户输入、刷新视图同步事件、计算帧信息、提交绘制渲染等
3应用线程H:UITaskScheduler::FlushTask刷新UI界面,包括布局计算、渲染和提交等
4应用线程H:FlushLayoutTask执行布局任务
5应用线程H:CreateTaskMeasure[root][self:0][parent:0]创建布局测量任务
6应用线程H:CreateTaskLayout[root][self:0][parent:0]创建布局任务
7应用线程H:Measure[root][self:0][parent:0][key:]执行root节点布局测量任务
8应用线程H:Layout[root][self:0][parent:0][key:]执行root节点布局任务

以上就是本篇文章所带来的鸿蒙开发中一小部分技术讲解;想要学习完整的鸿蒙全栈技术。可以在结尾找我可全部拿到!
下面是鸿蒙的完整学习路线,展示如下:
1

除此之外,根据这个学习鸿蒙全栈学习路线,也附带一整套完整的学习【文档+视频】,内容包含如下

内容包含了:(ArkTS、ArkUI、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、鸿蒙南向开发、鸿蒙项目实战)等技术知识点。帮助大家在学习鸿蒙路上快速成长!

鸿蒙【北向应用开发+南向系统层开发】文档

鸿蒙【基础+实战项目】视频

鸿蒙面经

2

为了避免大家在学习过程中产生更多的时间成本,对比我把以上内容全部放在了↓↓↓想要的可以自拿喔!谢谢大家观看!
3

  • 6
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值