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)
序号 | 泳道 | Trace | 描述 | 参数说明 |
---|---|---|---|---|
1 | mmi_service | H:service report touchId:2242, type: down [id: 0, x:709, y:2162] | mmi_service在屏幕上坐标开始变化的点, | |
2 | 应用 | H:FlushMessages && H:SendCommands | 通知图形侧进行渲染 | |
3 | 应用 | H:MarshRSTransactionData cmdCount: transactionFlag: | 通知图形侧进行渲染 | |
4 | render_service | H:RSMainThread::ProcessCommandUni && ReceiveVsync | 图形接收Vsync信号 | |
5 | RSHardwareThread | H:RSHardwareThread:CommitAndReleaseLayers | GPU渲染完成提交RSHD进行合成 |
(1)选取起止点这一区间,查看Frame 泳道,往后查看Frame应用侧帧渲染情况,是否出现异常帧、超长帧。如下图可以看出第560帧为超长帧,超长帧的耗时也会导致整个响应时延不达标。
(2)超长帧的场景一般需要结合应用主线程泳道查看组件渲染情况,具体分析参考【4.1.2应用帧耗时分析】;
(3) 选取起止点这一区间,查看ArkTS Callstack调用栈,查看耗时任务,如发现耗时任务,则继续查看耗时原因,一般结合应用进程UI主线程查看;
Symbol Name | 含义 |
---|---|
initialRenderView | 表示页面初始化 |
Program | 代表程序执行进入纯native代码阶段,该阶段无JS代码执行,也无JS调用native或者native调用JS情况(需要切换到Callstack泳道看具体的调用栈信息,一般很难通过这里分析出有效的信息)。 |
(BUILTIN) | 表示JS标准库接口,Native实现,虚拟机提供 |
anonymous | 匿名函数,具体需要查看代码确定此处是什么逻辑 |
(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 点
**
**
序号 | 泳道 | Trace | 描述 | 参数说明 |
---|---|---|---|---|
1 | mmi_service | H:service report touchId:type: | mmi_service在屏幕上坐标开始变化的点, | |
2 | 应用 | H:FlushMessages && H:SendCommands | 通知图形侧进行渲染 | |
3 | render_service | H:ReceiveVsync | 图形接收Vsync信号 | |
4 | RSHardwareThread | H:RSHardwareThread:CommitAndReleaseLayers | GPU渲染完成提交RSHD进行合成 |
( 上图中 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泳道标识
滑动场景通用流程
**
**
抛滑首帧响应时延 | 起点 | 终点 | 基线 | 首问责任领域 |
---|---|---|---|---|
input阶段 | 首个坐标变化对应irq/thp | 1首个坐标变化对应mmi_service | 多模 | |
TP事件分发 | 1首个坐标变化对应mmi_service | 2首次送显FlushMessage结束 | 应用 | |
首帧渲染显示 | 3找过对应的RS帧ReceiveVsync起始点 | 4H:RSHardwareThread::CommitAndReleaseLayers的结束点 | 图形 |
(表格中的1~4对应下图中的trace点信息)
序号 | 泳道 | Trace | 描述 | 参数说明 |
---|---|---|---|---|
1 | mmi_service | H:service report touchId:2242, type: down [id: 0, x:709, y:2162] | mmi_service在屏幕上坐标开始变化的点, | |
2 | 应用 | H:FlushMessages && H:SendCommands | 通知图形侧进行渲染 | |
3 | render_service | H:ReceiveVsync | 图形接收Vsync信号 | |
4 | RSHardwareThread | H:RSHardwareThread:CommitAndReleaseLayers | GPU渲染完成提交RSHD进行合成 |
注意:未提交的帧的SendCommands 下方无H:MarshRSTransactionData Trace 点
*
*
总结: 从上面的流程图可以看出,APP_LIST_FLING 泳道下的首个FlushMessages为应用送显的FlushMessages. 因此可以通过APP_LIST_FLING 快速定位滑动响应过程trace 点。
序号 | 泳道 | Trace | 描述 |
---|---|---|---|
1 | mmi_service | H:service report touchId:2242, type: down [id: 0, x:709, y:2162] | mmi_service在屏幕上坐标开始变化type 为move 的点 |
2 | 应用 | H: APP_LIST_FLING | 滑动过程 |
3 | render_service | RSHardwareThread 首个 CommitAndReleaseLayers | rs 渲染线程 |
以上就是本篇文章所带来的鸿蒙开发中一小部分技术讲解;想要学习完整的鸿蒙全栈技术。可以在结尾找我可全部拿到!
下面是鸿蒙的完整学习路线,展示如下:
除此之外,根据这个学习鸿蒙全栈学习路线,也附带一整套完整的学习【文档+视频】,内容包含如下:
内容包含了:(ArkTS、ArkUI、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、鸿蒙南向开发、鸿蒙项目实战)等技术知识点。帮助大家在学习鸿蒙路上快速成长!
鸿蒙【北向应用开发+南向系统层开发】文档
鸿蒙【基础+实战项目】视频
鸿蒙面经
为了避免大家在学习过程中产生更多的时间成本,对比我把以上内容全部放在了↓↓↓想要的可以自拿喔!谢谢大家观看!