HarmonyOS开发实战：时延类性能问题实践-Trace

概要

当应用在运行时出现明显的延迟或不流畅的情况，会影响用户体验，开发者需要定位、分析、解决应用时延问题。本文先简单介绍应用流畅度评测指标，然后基于Trace数据，介绍时延问题分析思路，并结合案例实践，实操定位分析并优化时延问题。

性能指标

性能指标介绍

滑动页面占位符加载完成时延的S标为40ms，A标为285ms。

滑动页面占位符加载完成时延

在可滑动页面中，滚动停止开始计算起，到屏幕内占位符（一般是图片）加载完成。

问题分析流程

信息准备

确定问题现象

• 应用运行环境版本、数据量是怎样？
• 应用运行时做了什么操作？
• 是否可以本地复现？复现概率如何？

确认验收标准

处理应用程序前首先需要和应用及测试确认当前问题场景的静态标准：

• 和应用方确认问题场景是否认可该标准，如不认可，相关问题需评审关闭。
• 和测试方确认是否按照静态标准执行的测试，测试步骤和性能衡量是否准确。

准备可观测性信息

处理应用程序时，可以优先查看操作录屏，查看操作场景，能否发现一些有助于定位的信息。然后针对性获取HiTrace、HiPerf、cpuProfiler、常规log等各种可观测数据。

点击领取→【纯血版鸿蒙全套最新学习资料】（安全链接，放心点击）希望这一份鸿蒙学习资料能够给大家带来帮助，有需要的小伙伴自行领取~

Trace抓取

抓取Trace前，可以打开ArkUI的一些debug开关。这样会增加一些详细的trace信息，比如显示具体引起组件标脏的变量、增加布局相关的信息、展示布局过程中所有涉及的组件层级等等。打开的方式，是连接设备后，通过hdc shell进入命令行交互模式，输入下表中所需命令。

| 开关命令 | 开关信息 | | ----------------------------------------- ------- | ------------------------------------------ | | param set persist.ace.debug.enabled 1 | 一些调试的Trace开关，包括状态变更更新的Trace | | param set persist.ace.trace.enabled 1 | ArkUI全局的Trace开关 | | param set persist.ace.layout.enabled true | 节点树布局的详细过程的Trace | | param set persist.ace.property.build.enabled | 属性设置构建的开关（仅支持root镜像下） | | param set const.security.developermode.state true | 开发者模式的开关（仅支持root镜像下） |

在设备相关debug开关打开后，通过Frame或SmartPerf Host等工具抓取场景Trace，开发者在抓取时，应结合问题现象，使Trace短小而有针对性，以方便后续问题定位。

问题分析

滑动操作占位符完成时延类问题的通用定位思路为先确认时延起止点，然后看起止点时延是否超S标的40ms，没有超过就是达标，超过就需要进一步分析Trace耗时主要发生在什么地方，主要分析网络耗时和帧渲染耗时，最后确定是系统问题还是三方问题。 处理流程图：

确认起止点

加载完成时延起始点 APP_LIST_FLING终点视为滑动停止，则是加载完成时延起始点。 滑动页面占位符加载完成，是以滑动停止为起始点，在Trace中APP_LIST_FLING泳道可以体现滚动视图的FLING惯性滚动状态的起止，惯性滚动停止则滚动停止，此时开始计算占位符加载时延。

查找步骤

1. 搜索APP_LIST_FLING。
2. 找到APP_LIST_FLING泳道，星标后即可置顶查看。
3. Trace标记了惯性滚动区间。
4. APP_LIST_FLING结束点=加载完成时延起始点。

加载完成时延终止点

APP_LIST_FLING终点视为滑动停止后，图片加载完成即页面不再发生变化（应用侧不提交Vsync信号到RenderService），则是加载完成时延终止点。

滑动页面滚动停止后，会出现两种情形。

1. 未触发上拉加载，滚动停止后的第一帧，分析异常帧。
2. 触发上拉加载，分析网络请求，分析异常帧。

加载完成时延

起始点与终止点时间间隔

定位问题点

1. 如果从应用UI上发现有网络加载的动作，则可以在ArkTS CallStack泳道查找是否发送网络请求，关键Trace点createHttp，继续查找请求响应点off(request)，parse数据解析，OnDataReload（LazyForEach刷新数