【鸿蒙性能优化】冷启动响应时延问题分析思路&案例

1. 场景导入

应用启动可以分为冷启动和热启动：

冷启动： 当应用启动时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用， 这种启动方式就叫做冷启动；

热启动： 当应用程序已经在后台运行，此时用户再次打开应用程序时，应用程序仍然在内存中，可以直接从内存中加载并继续之前的状态，而不需要重新初始化和加载资源，这种称为热启动。

**冷启动响应时延：**应用冷启动时，从点击应用离手开始到桌面应用图标发生变化（通常指图标变大）的这一段时间称为冷启动响应时延。

2. 性能指标

2.1 性能指标介绍

冷启动响应时延推荐时间：85ms

2.2 性能衡量起止点介绍

应用冷启动响应时延的性能衡量的起点为用户点击应用图标离手帧时间，止点为桌面应用图标开始发生变化的首帧时间。

3.问题定位流程

3.1 常规定位前置流程

3.1.1、确认效果

处理三方应用问题前首先需要先和三方应用及测试确认当前问题场景的预期效果：

1. 三方应用：和三方应用确认问题场景是否认可该标准，如不认可，相关问题需评审关闭。
2. 测试：和测试确认是否按照预期效果执行的测试，测试步骤和性能衡量是否准确。

3.1.2 查看操作录屏辅助定位

处理三方应用问题时，可以优先查看操作录屏，查看操作场景，看能否发现一些有助于定位的信息，比如应用启动是否存在横竖屏切换，是否存在页面跳转，是否包含网络加载等等。

3.1.3 Trace 抓取

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

3.2 问题定位思路

冷启动响应时延类问题的通用定位思路为先确认时延起止点，然后看起止点时延是否超60ms，未超过则说明达标，超过则根据Trace信息进一步确认问题点，确认责任领域并对齐处理（通常冷启动时延类问题责任领域都在大桌面），处理流程如下图：

注：图中耗时基线均为参考值，仅供定界参考，实际各子系统是否超标需和对应子系统接口人确认。

3.2.1 确认起止点

冷启动响应时延起点确认：

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

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开始位置就是起点。

冷启动响应时延止点确认：

止点Trace查找顺序：

H:DispatchTouchEvent type=1（大桌面ohos.sceneboard） -> H:FlushMessages（大桌面ohos.sceneboard）-> H:SendCommands（大桌面ohos.sceneboard）-> H:MarshRSTransactionData（大桌面ohos.sceneboard） -> H:RSMainThread::ProcessCommandUni（RS服务render_service）-> H:ReceiveVsync（RS服务render_service） -> H:FlushBuffer（RS服务render_service）-> H:RSHardwareThread（RS送显线程RSHardwareThrea）

1. 在H:DispatchTouchEvent type=1Trace的末尾找到H:FlushMessages（图中1）-> H:SendCommands（图中2）->H:MarshRSTransactionData（图中3）的系列Trace，这些Trace代表大桌面提交图形渲染请求到render_service（RS图形渲染服务）。
2. 选中H:MarshRSTransactionData（图中3）后可以在详情界面点击箭头跳转到render_service泳道对应的Trace H:RSMainThread::ProcessCommandUni（图中4），这个代表render_service收到大桌面渲染请求的点。（H:MarshRSTransactionData后面会有个参数transactionFlag:[2664,523]，括号中两个数字分别代表提交请求的进程号和提交的序号，在H:RSMainThread::ProcessCommandUni也会有一个[2664,523]与其对应，两个Trace是通过这个进程号和序号关联起来的。）
3. 然后继续找H:RSMainThread::ProcessCommandUni（图中4）所在的H:ReceiveVsync（图中5）的Trace，接着找该Trace下的H:FlushBuffer（图中6），这里代表render_ser