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

1、场景导入

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

2、性能指标

2.1、性能衡量起止点介绍

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

页面切换类点击操作完成时延推荐时间900ms。

3.问题定位流程

3.1、 常规定位前置流程

3.1.1、 查看操作录屏辅助定位

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

3.1.2、 Trace抓取

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

3.2、 问题定位思路

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

3.2.1、 确认起止点

起点确认

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

终点确认

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

3.2.2、 关键泳道查看分析

1. ArkTS Callstack子泳道ArkVM是需要最优先查看耗时情况的泳道，可以看到ArkTS侧一些方法的耗时,优先分析耗时最长的调用栈（program除外，program代表程序执行进入纯native代码阶段，该阶段无JS代码执行，也无JS调用native或者native调用JS情况，需要切换到Callstack泳道看具体的调用栈信息，一般很难通过这里分析出有效的信息），逐级展开,可以看到具体耗时的文件。

   

2. 还可以查看 Frame泳道里面的应用主线程子泳道，这个泳道显示app侧帧数据，这个里面如果有出现红色的帧表示异常，可以查看红色帧的耗时，如下图所示的第82帧。

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

3. 接着可以查看Callstack泳道（该泳道显示Native函数调用泳道，可以看到native函数调用栈）里面的应用主线程子泳道以及有内容显示的WorkerThread子泳道耗时情况。

4. 选中ArkUI Component泳道，可以看到组件的数量以及耗时，重点关注相对于其他组件耗时比较久的组件。

5. DevEco Testing 的UIViewer 可以看出组件的层级关系，逐级展开用于分析组件复杂度。冗余的嵌套会带来不必要的组件节点，加深组件树的层级，在创建和布局阶段会耗时比较久。

6. 如果点击页面切换的过程中有加载的loading动画，可以通过H:Animator 泳道，看出动画耗时，动画的耗时基本就是网络请求的耗时。

4. 常见根因归档

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

4.1.1.  问题根因分析

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

2.把耗时的栈一层层展开，发现是在cocos2d::experimental:AudioDecoder 里面耗时1s135ms，需要优化。在csloder里面耗时400ms左右，有优化空间，怀疑是在点击跳转的期间在加载资源。

4.1.2、 优化方案

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

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

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

点击完成时延900ms，通过视频可以看出点击后有一个网络请求的loading图，于是查看Trace的H:Animator 泳道，通过Trace看出网络请求耗时 637ms，此时网络耗时是导致不达标的主要原因。

4.3、 组件使用不合理导致点击完成时延较长

4.3.1、问题分析

查看Frame里面的应用主线程泳道，发现在点击事件后面有一帧超长帧。在Trace上圈出这段时间，再查看Trace的ArkTS CallStack泳道，其中VipImageView耗时 35ms，对应每个ListItem中加载的4张图片，parseURL耗时14.5ms；查看视图层级发现一个Image被包装了5层容器。可以考虑减少解析url的耗时，以及减少包装Image的层级。

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

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

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

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

​​​​​​​4.3.2、 根因分析

组件没有复用,给组件加上@Resuable标识自定义组件具备可复用的能力](​​https://docs.openharmony.cn/pages/v4.1/zh-cn/application-dev/performance/list-perf-improvment.md​​)

组件层级嵌套太多，去掉多余的层级。

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

1.安装应用hap包，或者从市场下载应用。

2.关掉手机上所有应用，打开需要抓trace的应用，将页面切换到需要分析的点击操作完成时延的场景。

3.在profiler中选择需要抓trace的应用，并选取frame模板，然后create session。然后点击开始录制。

4.当处理recording状态的时候 ,点击按钮响应等到页面切换完成且占位符加载完成停止录制。

5.完成录制等待analyzing。