基于ArkUI页面切换类点击操作完成时延问题分析思路&案例

1、场景导入

ArkUI页面切换类点击操作完成时延，应用的UI界面有许多需要和用户交互的地方，按钮的点击是很常见的一种。点击按钮应用转场进入下一个页面。应用的点击完成时延，是从点击应用离手开始到转场页面所有占位符加载完成.

2、性能指标

2.1、性能指标介绍

应用或元服务内点击操作完成时延s标为900ms，允许误差范围5%。

2.2、性能衡量起止点介绍

通过Avidemux工具查看视频来确定点击完成时延起点和终点，然后计算出整个耗时的时间，计算出来的这个时间在后面分析trace的时候会用到。

3.问题定位流程

3.1、 常规定位前置流程

处理三方应用问题前首先需要先和三方应用及测试确认当前问题场景的静态KPI标准（S标）：

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

处理应用问题时，可以优先查看操作录屏，看看具体的操作场景，能否发现一些有助于定位的信息，还需要自己在单框架的手机上安装hap包运行应用操作观察帮助定位。例如可以初步看出网络请求的时间是否合理，应用布局的复杂度等。

点击操作完成时延Trace抓取请参考附录1: 点击操作完成时延Trace抓取方法。

3.2、 问题定位思路

点击操作完成时延类问题的通用定位思路为先确认时延起止点，然后看起止点时延是否超900ms，没有超过就是达标，如果超过900ms，就需要进一步分析trace看看耗时主要发生在什么地方，然后确定是系统问题还是三方问题，然后对齐问题。处理流程如下图：

起点确认

搜索dispatchtouchevent，找到type=1的那个dispatchtouchevent，就是点击抬手起点。

Trace点名称	含义	问题定位作用
DispatchTouchEvent , type=1	手指点击后离手	作为点击完成

终点确认

点击操作完成时延的终点位置在trace上没有明确的trace点，需要按照2.2里面所介绍的方法确定终点。然后根据视频上数出来的加载完成的整个耗时在trace上拉相同的时间找到终点位置。这样就有了整个完成时延的耗时区间。并在Markers泳道做好标记。

Symbol Name	含义
initialRenderView	表示页面初始化
Program	代表程序执行进入纯native代码阶段，该阶段无JS代码执行，也无JS调用native或者native调用JS情况（需要切换到Callstack泳道看具体的调用栈信息，一般很难通过这里分析出有效的信息）。
rerender	主要发生在页面更新的场景
(BUILTIN)	表示JS标准库接口，Native实现，虚拟机提供
aboutToAppear	组件即将出现时回调该接口，具体时机为在创建自定义组件的新实例后，在执行其build()函数之前执行
aboutToDisappear	aboutToDisappear函数在自定义组件析构销毁之前执行。不允许在aboutToDisappear函数中改变状态变量，特别是@Link变量的修改可能会导致应用程序行为不稳定
anonymous	匿名函数，具体需要查看代码确定此处是什么逻辑

每帧的预期耗时（ms） = 1000ms / 帧率 。如下图，鼠标点击选中超长帧，可以看到该帧的预期耗时Expected Duration 为8ms 276us，说明帧率是120，而实际耗时为93ms394us，远超预期耗时，就是超长帧，超长帧的耗时也会导致整个点击完成时延不达标。

4、常见根因归档

4.1、 因在点击操作的转场过程中加载资源、解析资源过长导致点击完成时延不满足

1，用DevEco Studio 的profiler的frame模板去抓trace，利用dispatchtouchevent type = 1 确定起点，通过视频数帧可以得出这个点击完成时延耗时2800ms，在trace上圈出这段时间来分析耗时。在ArkTS Callstack子泳道ArkVM并没有发现耗时，于是查看其他泳道，发现Callstack里面的子泳道workerThread有耗时异常。

2，把耗时的栈一层层展开，发现是在cocos2d::experimental:AudioDecoder 里面耗时1s135ms，耗时超过s标需要优化。在csloder里面耗时400ms左右,相对于s标900ms来说占比较大，有优化空间，怀疑是在点击跳转的期间在加载资源。

1：rawfile加载资源比较耗时，尝试改变加载资源的方式。加载方式参考链接文档https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/resource-categories-and-access-0000001774119914#section694911752315

2： AudioDecoderMp3: decodeTOPCM 耗时很长，音频解码耗时较多。

需要优化资源加载方式和音频解码优化。

4.2、 网络请求耗时久导致点击完成时延不满足

4.3、 组件使用不合理导致点击完成时延不满足 s标900ms， 实测999ms

3. 接着查看应用主线程泳道，发现在网络请求动画结束后面（网络请求示例在4.2中已展示）开始刷新列表内容，会看到有大量组件初始化的过程，还会调用很多aboutToDeleted，说明有旧的组件被移除。

下图为上图中红框展开的详细图，可以看出有很多的aboutToDeleted事件。

圈出有很多aboutToDeleted这段时间，切换到ArkVM泳道，可以看出每个aboutToDeleted所耗的时间。可以看出最多的aboutToDeleted耗时4ms左右，最少的也有几百us，再加上这个地方有大量的aboutToDeleted，累积起来耗时就比较多。可以用Resuable进行优化，从而达到组件的复用，避免创建和析构大量组件。

3.上述两步已经找出完成时延不达标的主要原因所在，接下来还可以利用 DevEco Testing 的UIViewer工具去判断组件是否有冗余的容器嵌套，冗余的嵌套会带来不必要的组件节点，加深组件树的层级，在创建和布局阶段会耗时比较久。

附录1：点击操作完成时延Trace抓取方法