HarmonyOS 鸿蒙Next同页面内抛滑操作响应时延问题分析思路&案例

1. 场景导入

抛滑操作响应时延：应用页面内手指抛滑场景下，手指滑动，到页面发生变化的时间。

2. 性能指标

2.1 性能衡量起始点介绍

抛滑操作响应时延：应用页面内手指开始滑动，到页面发生变化的时间。推荐时间少于80ms

响应时延计算公式 响应时延=硬件耗时+软件耗时（整个耗时，包含我们在trace上看的软件的耗时，机器本身的一个硬件耗时，一般硬件耗时大概在30ms左右，在trace上的起点到终点的时间加上30ms左右的硬件耗时和测试给出的实际耗时能对的上即可。）

起点：手指接触屏幕并开始滑动；

终点：页面发生变化；

3. 问题定位流程

3.1 常规定位前置流程

3.1.1 查看操作录屏辅助定位

处理三方应用问题时，可以优先查看操作录屏，查看操作场景，看能否发现一些有助于定位的信息，比如页面滑动是否卡顿等。

3.1.2 Trace抓取

页面滑动Trace抓取请参考【附录1: 页面滑动Trace抓取方法】。

3.2 问题定位思路

抛滑场景处理流程如下

3.2.1 确认起止点

3.2.1.1 滑动操作响应时延起点确认

起点 mmi_service 对应的坐标开始变化的点 。（例如：H:service report touchId:26899, type: move [id: 0, x:629, y:2117]，其中type：down 表示手指按下，move表示手指滑动，up表示手指抬起）

1.点击搜索;

2.在输入框中输入mmi_service;

3.点击跳转到mmi_service 泳道；

从上图可以看出，第一个点和第二个点的坐标已经发生了变化。

3.2.1.2 滑动操作响应时延终点确认

终点 页面变化第一帧对应RS HardwareThread:CommitAndReleaseLayers 的终点。（对应图标5代表的点。）

终点Trace查找顺序：H: service report touchId: type:（多模输入mmi_service） -> H:FlushMessages（应用）-> H:SendCommands（应用）-> H:MarshRSTransactionData（应用） -> H:RSMainThread::ProcessCommandUni（RS服务render_service）-> H:ReceiveVsync（RS服务render_service）-> H:RSHardwareThread（RS送显线程RSHardwareThrea）

（1）选取起止点这一区间，查看Frame 泳道，往后查看Frame应用侧帧渲染情况，是否出现异常帧、超长帧。如下图可以看出第560帧为超长帧，超长帧的耗时也会导致整个响应时延不达标。

（2）超长帧的场景一般需要结合应用主线程泳道查看组件渲染情况，具体分析参考【4.1.2应用帧耗时分析】；

（3） 选取起止点这一区间，查看ArkTS Callstack调用栈，查看耗时任务，如发现耗时任务，则继续查看耗时原因，一般结合应用进程UI主线程查看；

（4）选取起止点这一区间，查看Callstack的Native调用栈，查看耗时任务，如发现耗时任务，则继续查看耗时原因，一般结合应用进程UI主线程查看；

（5）结合使用DevEco Testing 的UIViewer 可以看出组件的层级关系，逐级展开用于分析组件复杂度。冗余的嵌套会带来不必要的组件节点，加深组件树的层级，导致应用帧耗时较长，从而影响响应时延。

3.2.3 根因分析方法

滑动响应时延类问题主要根据3.2.2章节内容定位到问题点，如果想了解更详细的滑动时延范围内的Trace流程解读，见【附录2：滑动响应时延Trace点解读】

4. 典型问题

4.1 自定义布局计算以及页面层级嵌套导致达不到预期

问题描述：应用内向上抛滑浏览页面，响应时延96，预期80ms，超时16ms

4.1.1 问题trace点

(上图中 1 为起点，4为终点)

分析数据

1.测试数帧实际结果是102ms ，在以上trace可以看到，应用第一帧，上屏时间在66ms左右, 加上30多毫秒的硬件耗时，和录屏102ms能对应上。所以当前trace上页面发生变化的帧是对应的应用第一帧。所以终点应该是应用第一帧对应的RSHardwareThread 对应的CommitAndReleaseLayers的结束点，如上图。2.从Trace上看，总体是由于滑动开始的第一帧应用侧耗时过长 (31ms)，导致rs的执行延迟（错过了VSync信号，应用帧结束距离rs帧开始4.9ms），从而导致整体耗时过长。

4.1.2 应用帧耗时分析

第一帧后半段，WaterFlow 的 Item 中包含大量 LightArtViewContainer 、LightArtBlockView （14个左右）等组件，还有少量 LightArtImageView、LightArtLabelView，远超过能在App界面上看到的元素的个数，因此推测是 Item 的组件太多，导致布局计算复杂、耗时过长。JSMeasure 说明使用了自定义布局 ​onMeasureSize​，增加了布局计算耗时。

后面有一段ExecuteJS, 这里可以查看ArkTS Callstack, Request 中computeApiSign耗时较长，有16ms; 这里需要应用侧排查是否可以优化。

4.1.3 使用DevEco Testing查看页面层级

建议应用侧简化组件结构，减少不必要的组件，减少多余嵌套容器；优化布局的方式。

附录一 Trace抓取方式

1）电脑连接上设备，在DevEco Studio上打开Profiler，设备上运行需要测试的应用，在设备列表选择设备，选择要测试的应用，和主进程

2）创建Frame模板，并点击录制，待泳道都进入到recording状态后，在应用上复现测试场景

附录二 场景通用Trace流程点说明

H:APP_LIST_FLING ：List的单次抛滑过程，可以通过应用进程下的H:APP_LIST_FLING泳道标识

滑动场景通用流程

(表格中的1~4对应下图中的trace点信息)

注意：未提交的帧的SendCommands下方无H:MarshRSTransactionData Trace点

总结： 从上面的流程图可以看出，APP_LIST_FLING 泳道下的首个FlushMessages为应用送显的FlushMessages. 因此可以通过APP_LIST_FLING 快速定位滑动响应过程trace 点。