往期推文全新看点（文中附带全新鸿蒙5.0全栈学习笔录）
✏️ 鸿蒙（HarmonyOS）北向开发知识点记录~
✏️ 鸿蒙（OpenHarmony）南向开发保姆级知识点汇总~
✏️ 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？
✏️ 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~
✏️ 对于大前端开发来说，转鸿蒙开发究竟是福还是祸？
✏️ 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？
✏️ 记录一场鸿蒙开发岗位面试经历~
✏️ 持续更新中......
1. 场景导入
冷启动过程最大连续丢帧数：应用冷启动时，从点击应用离手开始到应用界面铺满全屏（启动页图标铺满全屏）这一段时间内的最大连续丢帧数称为冷启动过程最大连续丢帧数。
2. 性能指标
2.1 性能指标介绍
冷启动过程最大连续丢帧数的预期为动效环节0帧，加载环节6帧。冷启动过程只涉及动效环节。不同过程可能有差异，具体以测试标准为准。
冷启动过程最大连续丢帧数即在冷启动过程中的最大连续丢帧数，其性能衡量的起点为用户点击应用图标离手帧时间，止点为应用启动页图标铺满屏幕的首帧时间。
如果应用存在广告，则性能衡量方式有两种：
- 离手帧到广告铺满全屏首帧作为性能衡量起止点。
- 离手帧到应用启动图标铺满全屏首帧（减去广告时间）作为性能衡量起止点。
3. 问题定位流程
3.1 常规定位前置流程
3.1.1 查看操作录屏辅助定位
应用遇到问题时，可以优先查看操作录屏，查看操作场景，看能否发现一些有助于定位的信息，比如应用启动是否有明显卡顿，白屏等等。
3.1.2 Trace 抓取
冷启动过程最大连续丢帧数Trace抓取请参考【附录1: 冷启动Trace抓取方法】
3.2 问题定位思路
冷启动过程丢帧类问题的通用定位思路为先确认时延起止点，然后看起止点范围内的丢帧情况，未超过则说明达标，超过则根据Trace信息进一步确认问题点，确认责任领域并对齐处理，处理流程如下图：
3.2.1 确认起止点
冷启动过程的起点确认：冷启动首帧完成时延的起点是多模子系统收到硬件传递过来的离屏信号的Trace开始点。
起点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开始位置就是起点。
冷启动过程的止点确认：即启动图标铺满全屏，找到ohos.sceneboard（大桌面进程）泳道下的H:LAUNCHER_APP_LAUNCH_FROM_ICON泳道。该trace点的终点就是冷启动过程的止点。
3.2.2 确认是否存在丢帧
确认冷启动过程起止点之后，圈出起止点范围，点击Frame泳道，在下方详情界面可以看到render_service泳道，ohos.sceneboard大桌面泳道，erviceAbility元能力泳道和应用进程泳道的丢帧情况，通过Max Consecutive Jank Count确定最大连续丢帧数 ，当存在大于 0 的值时，说明存在丢帧。之后通过分析trace进一步定界是系统侧问题（RS，大桌面，元能力）还是应用侧问题。系统侧丢帧交由系统侧分析，应用侧丢帧需进一步分析原因或找伙伴确认。（如何定界是系统侧问题还是应用侧问题见3.2.3）
3.2.3 确认问题，分析根因
冷启动过程的丢帧问题需要定位到问题点，确认是业务侧还是系统侧的责任领域即可，之后的根因分析由相应领域进行分析。
3.2.3.1 如何界定丢帧是否是应用侧导致
框选起止点范围后，点击Frame泳道，双击下方详情界面列表中的render_service数据可以看到RS线程丢帧时，正在进行中的线程(Preceding Flows)，如图正在进行的线程是应用线程和大桌面线程，说明可能是应用线程或者大桌面线程导致RS线程丢帧。
根据上图分析出的进行中线程，双击下方详情界面列表中的大桌面线程数据查看大桌面丢帧，可以看到下一个线程(Following Flows)，如图接下来要运行的线程是VSyncId为13594的RS线程，而不是丢帧的VSyncId为13625的线程，说明大桌面线程未导致RS线程阻塞。
根据上图分析出的进行中线程，双击下方详情界面列表中的应用线程数据查看应用线程丢帧，发现此时只有其自身线程在阻塞，且后续线程(Flowing Flows)就是丢帧的VSyncId为13625的RS线程，说明是应用线程阻塞导致了RS线程阻塞，即丢帧是应用侧导致。
通过以上的定位思路确定应用侧丢帧，丢帧位置为VSyncId：8090的应用线程，点击标记1可以跳转其对应的应用线程。
查看相邻的渲染周期（搜索应用线程泳道中相邻的两个H:ReceiveVsync的Trace点），VSyncId：8090相邻的下一个Trace点是VSyncId：8093，周期不连贯，即为丢帧。
3.2.3.2 应用侧丢帧原因分析方法
根据3.2.3.1界定了丢帧是应用侧导致，然后分析丢帧范围内相邻渲染周期之间的应用线程泳道，查看其线程运行情况，界面布局，函数调用栈执行情况等。比如下图我们可以看到：卡顿帧内组件布局明显较别处多，且业务侧在做UI组件的flushlayouttask，怀疑是因为业务侧冷启动过程预加载时组件嵌套导致组件变量更新时相关组件同步更新渲染，计算量大，导致卡顿丢帧。
如果想了解更详细的冷启动过程最大连续丢帧数的Trace流程解读，见【附录2：应用进程VSync期间的关键Trace解读】
4. 常见根因归档
4.1 因窗口预加载导致冷启动过程最大连续丢帧数不满足预期
4.1.1 问题根因分析
应用冷启动过程最大连续丢帧1帧，不满足预期。通过以上的定位思路确定应用侧丢帧，丢帧位置为VSyncId：8090的应用线程，查看相邻的渲染周期（搜索应用线程泳道中相邻的两个H:ReceiveVsync的Trace点），VSyncId：8090相邻的下一个Trace点是VSyncId：8093，周期不连贯，即为丢帧。
框选以上两个相邻渲染周期，分析应用线程发现：耗时帧内组件布局明显较别处多，且业务侧在做UI组件的flushlayouttask，怀疑是因为业务侧组件嵌套导致组件变量更新时相关组件同步更新渲染，计算量大，耗时增加。优化建议：优化组件布局，倾向用扁平化布局，尽量少用多层嵌套；
结论：耗时帧内组件布局明显较别处多，且业务侧在做UI组件的flushlayouttask，怀疑是因为在冷启动过程中业务侧组件在做预加载，且组件嵌套导致组件变量更新渲染时的计算量大，导致卡顿。
4.1.2 优化方案
优化建议：优化组件布局，倾向用扁平化布局，尽量少用多层嵌套，同时可使用loading的方式给预加载提供足够的时间；
附录1. 冷启动Trace 抓取方法
Step1：打开DevEco Studio的Profiler（下图1） -> 选择设备进程（下图2）-> Frame模式（下图3）-> Create Session（下图4）-> 启动录制（下图5）。
注意：第二步选择进程时不要选择要录制的进程，因为要录制的进程需要处于未启动状态，这里是通过录制其他进程间接录制目标进程的启动Trace 信息。
Step2：启动录制后，在设备上点击应用图标启动要录制的目标应用，等到应用首页加载后，点击停止结束录制。
Step3：录制完成后会工具会分析展示Trace数据。
附录2 应用进程VSync 期间的关键Trace 解读
应用进程VSync期间的关键Trace解读：
| 序号 | 泳道 | 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节点布局任务 |