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

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

1、场景导入

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

2、性能指标

2.1、性能衡量起止点介绍

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

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

image.png

3.问题定位流程

3.1、 常规定位前置流程

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

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

3.1.2、 Trace抓取

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

3.2、 问题定位思路

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

image.png

3.2.1、 确认起止点

起点确认

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

image.png

Trace点名称

含义

问题定位作用

DispatchTouchEvent , type=1

手指点击后离手

作为点击完成

终点确认

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

image.png

3.2.2、 关键泳道查看分析

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

    image.png

Symbol Name

含义

initialRenderView

表示页面初始化

Program

代表程序执行进入纯native代码阶段，该阶段无JS代码执行，也无JS调用native或者native调用JS情况（需要切换到Callstack泳道看具体的调用栈信息，一般很难通过这里分析出有效的信息）。

rerender

主要发生在页面更新的场景

(BUILTIN)

表示JS标准库接口，Native实现，虚拟机提供

aboutToAppear

组件即将出现时回调该接口，具体时机为在创建自定义组件的新实例后，在执行其build()函数之前执行

aboutToDisappear

aboutToDisappear函数在自定义组件析构销毁之前执行。不允许在aboutToDisappear函数中改变状态变量，特别是@Link变量的修改可能会导致应用程序行为不稳定

anonymous

匿名函数，具体需要查看代码确定此处是什么逻辑

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

image.png

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

image.png

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

image.png

image.png

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

image.png

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

image.png

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

image.png

4. 常见根因归档

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

4.1.1.  问题根因分析

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

image.png

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

image.png

image.png

4.1.2、 优化方案

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

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

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

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

    image.png

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

4.3.1、问题分析

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

    image.png​​​​​​​

    ​​​​​​​image.png

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

    image.png

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

    image.png

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

    image.png

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

    image.png

    image.png

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

  1. 组件没有复用,给组件加上@Resuable标识自定义组件具备可复用的能力](https://docs.openharmony.cn/pages/v4.1/zh-cn/application-dev/performance/list-perf-improvment.md)
  2. 组件层级嵌套太多，去掉多余的层级。

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

  1. 安装应用hap包，或者从市场下载应用
  2. 关掉手机上所有应用，打开需要抓trace的应用，将页面切换到需要分析的点击操作完成时延的场景
  3. 在profiler中选择需要抓trace的应用，并选取frame模板，然后create session。然后点击开始录制。

    image.png​​​​​​​

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

    image.png​​​​​​​

  5. 完成录制等待analyzing。

    image.png​​​​​​​​​​​​​​


更多关于HarmonyOS 鸿蒙Next 基于ArkUI页面切换类点击操作完成时延问题分析思路&案例的实战教程也可以访问 https://www.itying.com/category-93-b0.html

1 回复

更多关于HarmonyOS 鸿蒙Next 基于ArkUI页面切换类点击操作完成时延问题分析思路&案例的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


作为IT专家，对于HarmonyOS鸿蒙Next基于ArkUI页面切换类点击操作完成时延问题的分析，我们可以遵循以下思路并结合案例进行说明。

首先，确认时延的起止点。点击操作完成时延是从用户点击离手开始，到转场页面所有占位符加载完成结束。利用录屏工具（如Avidemux）来确定起点（即dispatchtouchevent type=1）和终点，并计算出整个耗时。

其次，分析是否超过标准时延（900ms，允许误差范围5%）。如果超过，需要进一步分析trace，查看耗时主要发生在哪个环节。这通常涉及函数调用耗时、转场页面绘制耗时、转场动画时延等关键泳道。

以案例说明，某应用首页点击新闻页面切换完成时延为1327ms，远超标准。通过trace分析，发现主资源下载耗时长（314ms以上）、子资源下载耗时长（347ms以上）以及js编译耗时长（超过52ms）。针对这些问题，可以提出优化建议，如预下载、预渲染资源，以及预编译JavaScript生成字节码缓存。

最后，如果问题依旧无法解决，可能是由于更复杂的系统或第三方问题，建议联系官网客服获取进一步帮助。官网地址是：https://www.itying.com/category-93-b0.html。

回到顶部