1# 应用性能问题分析指导 2 3## 概述 4 5常见的应用性能问题，开发者可以从丢帧问题（如滑动列表时的丢帧、窗口动画不连贯）和响应速度问题（如应用启动白屏过长、滑动不跟手）两个角度去分析。在分析性能问题之前、验证性能优化方案之时，开发者会需要对应用的性能指标做检测。本文会先说明丢帧和响应速度问题相关的性能指标检测方法，然后再阐述两个角度下，略有不同的问题分析思路。 6 7本文主要是以Trace数据为切入点进行分析，相应的工具可以使用SmartPerf Host或DevEco Studio内置的Frame等。若开发者需要补充SmartPerf Host工具和Trace相关知识，可以分别参考《[性能优化工具SmartPerf-Host](performance-optimization-using-smartperf-host.md)》和《[常用trace使用指导](common-trace-using-instructions.md)》等应用开发文档。 8 9## 应用性能指标 10 11### 平均帧率 12开发者可以通过HiTrace命令工具抓取应用刷新时的Trace信息，并通过SmartPerf Host集成性能工具分析。例如，抓取某应用发生丢帧处的Trace信息如图1，则平均帧率计算过程如下： 13 14**图1 应用丢帧处的Trace数据** 15  16其中，帧率 = Occurrences / Selected range。 17 18| 计算帧率时，可参考的Trace标签 | 含义| 帧数| 平均帧率 | 19| --- | --- | --- |--- | 20| RSMainThread::DoComposition| 合成渲染树上各节点图层| 20| 32.5 | 21| Repaint | 硬件合成器合成绘制 | 18 | 29.27 | 22 23如果依据RSMainThread::DoComposition标签，从GPU合成图层的角度，去模拟最终呈现给用户的上屏帧数，平均帧率为32.5FPS。 24 25 26如果依据Repaint标签，从硬件合成器合成绘制的角度，去模拟最终呈现给用户的上屏帧数，平均帧率为29.27FPS。 27 28 29可见，不同trace标签的选取，对估算用户真实感知到的平均帧率，是略有不同的。 30 31在了解估算原理后，值得说明的是，SmartPerf Host针对部分标签，已经可以实现框选时间范围内平均帧率的自动计算。例如，框选的范围内存在RSMainThread::DoComposition泳道，平均帧率自动计算效果如图2所示，而其相应的平均帧率算法如下： 32 33帧数 = 框选时间范围内，完整的DoComposition个数。 34时间 = 框选时间范围内，从第一个完整的DoComposition开始到最后一个完整的DoComposition结束的时间。 35 36进而通过，平均帧率 = 帧数 / 时间，计算平均帧率。 37 38**图2 SmartPerf Host平均帧率自动计算** 39  40 41### 完成时延 42 43这里以点击应用tab，做页面跳转的场景为例，通过Trace分析其完成时延。 44在了解如何通过Trace分析应用的完成时延之前，开发者需要简单了解OpenHarmony中图形渲染的流程。在整个渲染流程中，首先由App侧响应用户的屏幕输入事件，由App侧处理完成后再提交给RS侧，由RS侧协调GPU等资源处理后，再将最终的图像送到屏幕上进行显示。图3即该过程中，几个常见的进程/标签名，及其在system侧、App侧、RS侧的时序分布。后文将结合Trace图示例，与标签含义说明，简要描述system侧、App侧、RS侧在图形渲染流程中的行为。 45 46**图3 页面跳转完成时延** 47  48 49在系统侧，如图4所示，用户点击屏幕后，CPU会收到硬件中断；aptouch进程会响应中断，判断哪些像素被点击、是否是手势；如果是手势，多模会收到手势信号，形成点击事件，执行应用注册的事件回调。 50 51**图4 system侧Trace** 52  53 | 系统侧进程标签 | 含义 | 54 | --- | --- | 55 | irp | CPU收到硬件中断 | 56 | aptouch_daemon | 响应中断，哪些像素被点，判断是不是手势 | 57 | mmi_service | 多模收到手势，会执行应用注册的回调 | 58 59在app侧，如图5所示，应用收到点击，运行onClick中的回调，UI后端引擎会在测量、布局做完后，将组件树信息序列化后传给RS侧。 60 61**图5 app侧Trace** 62  63 |APP侧trace标签示例 | 含义 | 64 | --- | --- | 65 |DispatchTouchEvent | 应用收到事件，开始运行onClick的回调 | 66 |MarshRSTransactionData cmdCount:36 transactionFlag:[7291，51] | App将组件树信息序列化后发给RS | 67 68图形图像子系统中的Render Service，是负责界面内容绘制的部件，如图6所示，它收到App侧序列化的组件树信息后，将其反序列化，更新统一渲染树后，翻译为GPU绘制指令，最后将GPU绘制好的图层，放到硬件合成器上做合成，层层堆叠，最终显示到屏幕上。 69 70**图6 RS侧Trace** 71  72RS侧trace标签示例 含义 73RSMainThread::ProcessCommandUni [7291，51] 反序列化组件树信息 74RenderFrame 将渲染树翻译为GPU绘制指令 75Repaint 硬件合成器合成绘制。 76 77App侧序列化与RS侧反序列化的Trace示例标签中都有 [7291，51]，分别是线程号与帧编号标识。可以看到被处理的帧信息，是按编号在App侧与RS侧一一对应的。 78 79不同开发者分析问题的目的不同，所关注的问题层级和入口也会不同，因此对响应时间的起点与终点的界定也有可能不同。这里以系统行为的硬件中断为起点，RS侧硬件合成器合成绘制、提交上屏为终点，测量响应时间。 80 81**图7 测量完成时延** 82  83如图7所示，该点击事件完成时延约为138.4ms。 84 85## 应用性能分析 86 87### 丢帧问题分析思路 88 89这里以某应用滑动场景发生丢帧为例，简要说明应用侧问题分析思路。 90 91#### 信息准备 92 93**确定问题现象** 94 95用户环境版本、数据量是怎样？用户做了什么操作？是否可以本地复现？复现概率如何？ 96 97**抓取所需日志信息** 98 99HiTrace、HiPerf、cpuProfiler、常规log等各类可观测性数据。 100 101#### 问题分析 102 103导致应用丢帧的原因非常多，可能是应用本身原因，可能是系统原因，也有可能是硬件层原因。不同卡顿原因在Trace中有不同表现，识别需要大量经验积累。 104 105分析过程，主要是结合App主进程和RenderService渲染进程Trace数据，先排查系统、硬件是否异常，再分析应用本身原因。 1061. 看线程状态和运行核，看是否被其他进程抢占资源，排除系统侧运行异常。 107 108 **看线程状态** 109 110 从图8可以看到，应用线程大部分时间处于Running状态，无特殊异常。 111 112 **图8 丢帧处应用主线程状态** 113  114 115 **看运行频率** 116 117 查看关键任务是否跑在了小核，以低频运行。从Thread Usage信息栏，如图9所示，可以看到丢帧处应用线程和前面正常帧类似，都主要运行在大核上。其运行频点，可以参考Freq Usage信息栏，如图10所示。 118 119 **图9 丢帧处应用主线程运行核** 120  121 **图10 Freq Usage频点信息** 122  123 出于兼顾高性能、低功耗的需求，多核工程机常采用异构架构设计，根据CPU频率，区分大中小核等。 124 1252. 找到 Trace中每一帧耗时的部分，大致定位是App侧问题还是RS侧问题，并结合Trace标签，初步定位原因。 126 从图11中橙色丢帧的位置，可以看到耗时主要在App侧，是BuildLazyItem方法耗时较长导致，可以大致推测，是列表懒加载时，Item里的自定义组件绘制时间较长导致的。 127 128 **图11 应用主线程与RenderService线程的TimeLine** 129  130 1313. 结合cpuProfiler查看ArkTS函数调用栈信息，或其他日志信息，排查应用代码。 132 例如，可以结合DevEco Studio中Frame工具，方便地跳回源码，定位具体是哪一个自定义组件绘制时间较长。 133 134 **图12 Frame工具抓取应用信息图** 135  136 137### 解决方案 138关于应用的流畅度优化，开发者可以尝试从如下几个方面入手： 139 140- 如果定位是App侧问题，需要进一步审视在UI线程中的处理逻辑，是否过于复杂或低效。 141- 如果定位是RS侧问题，需要进一步审视是否是界面布局过于复杂。 142 143最终，根据卡顿原因，结合业务场景和API找出适合解决方案，并用Trace等数据验证优化结果。 144 145### 响应速度问题分析思路 146 147这里以冷启动场景的响应速度为例，做具体分析思路的说明。 148 149#### 信息准备 150 151**确定问题现象** 152 153用户环境版本、数据量是怎样？用户做了什么操作？体验到了什么现象？是否可以本地复现？ 154 155**明确测试标准** 156 157为什么体验到这个现象会觉得性能有问题？衡量响应速度的起点和终点是哪里？ 158 159**抓取所需日志信息** 160 161HiTrace、HiPerf、cpuProfiler、常规log等各类可观测性数据。 162 163#### 问题分析 164 165分析应用冷启动场景，首先开发者需要简单了解OpenHarmony应用启动流程，如图13所示，大致分为五个阶段： 166**图13 OpenHarmony应用启动流程** 167  1681. AbilityManageService请求AppSpawn创建应用进程。 1692. AppManageService触发应用启动流程、应用进程加载应用包。 1703. AppManageService触发Ability启动流程、应用进程加载Ability资源、根据应用生命周期定义，触发生命周期回调。 1714. 创建UI Ability持有的Windows对象。 1725. 绘制UI界面首帧。 173 174这五个阶段，对应Trace中的标签信息如下： 175 176| 生命周期 | trace标签| 177| --- | ---| 178| 创建应用进程 | AppManageService::StartAbility()| 179| 启动应用 | OHOS::AppExecFwk::MainTread::HandleLaunchApplication()| 180| 启动UI Ability | OHOS::AppExecFwk::MainTread::HandleLaunchAbility()| 181| 创建窗口 | AbilityMonitor::OnWindowStageCreate()| 182| 绘制应用UI界面首诊 | JsRuntime::RunScript() RSMainThread::SendCommands()| 183 184而实际分析时，开发者可以借助SmartPerf Host提供的AppStartup模板，将各启动阶段自动拆解出来，如图14所示。关于AppStartup模板详细使用方法，请参考《[性能优化工具SmartPerf-Host](performance-optimization-using-smartperf-host.md)》中相关章节。 185 186**图14 AppStartup泳道图展示** 187 188  189之后，开发者可以结合应用启动各阶段Trace信息，对比应用前一个版本或竞品表现，找出差异点，大致分析是哪阶段时间增加了。 190 191**分析系统耗时点** 192 193如果分析是系统的问题，则查看系统对应的部分，一般情况要优先查看系统是否异常，例如： 194- 查看关键任务是否跑在了小核（App线程处于 Running 状态，但是执行耗时变长）。 195- 查看频率是否没有跑满 （App线程处于 Running 状态，但是执行耗时变长）。 196- 是否是高负载场景：查看 CPU 使用率，是否已经被跑满（App线程有大段的 Runnable 状态）。 197- 是否是低内存场景：查看是否低内存 （App线程有大段的 Uninterruptible Sleep 状态）。 198 199**分析应用耗时点** 200 201如果分析是应用的问题，则结合上面耗时的点，查看应用对应的部分，例如： 202- 是否某一段方法自身执行耗时比较久（App线程处于 Running 状态）。 203- 是否在等待子线程或子进程返回数据（App线程处于 Sleep 状态）。 204 205#### 解决方案 206 207一个性能问题点，在复杂应用中，通常会涉及多个问题。首先要把影响最大的因素找出来优化，影响比较小的因素可以先忽略。 208如果判断是系统的原因，首先看应用自身是否可以规避，否则转由系统来处理。 209如果判断是应用自身的原因，可以结合cpuProfiler查看函数调用信息，审查源码，摸索解决之道。 210应用的响应速度优化大多集中在：UI界面、视觉动效、指令逻辑等方面，开发者可以尝试从如下几个方面入手： 211- UI优化：从UI布局渲染角度，加快应用绘制性能，比如减少布局嵌套，减少元素渲染，缓存UI动效等。 212- 按需加载优化：根据界面展示或模块加载的需要，延迟加载相关内容，从而减少对首帧页面的性能消耗。 213- 并发优化：使用系统并发执行多个任务的能力，减少响应过程中任务执行的整体时间。 214- 代码逻辑优化：在相关生命周期中减少冗余、避免耗时，提升执行效率，包括善用数据结构、缓存、优化调整时序等。 215- 视觉感知优化：通过交互设计的优化，利用动效动画的形式，在视觉层面提升用户响应速度的感知。 216最终，根据延迟原因，结合业务场景和API，找出适合解决方案，并用Trace等数据验证优化结果。 217 218 219## 总结 220文章首先介绍了通过分析Trace的方式，检测应用问题所对应的基础性能指标： 221针对丢帧问题，展示了如何结合Render Service进程下相关线程的Trace标签，估算用户真实感知到的平均帧率。 222针对响应速度问题，展示了如何结合OpenHarmony图形渲染流程相关Trace标签，估算用户真实感知到的点击完成时延。 223文章还从丢帧问题和响应速度问题两个角度，对常见应用性能问题进行分析，总结两个角度共通步骤大致如下： 2241. 信息准备：确定问题现象、明确问题标准、抓取相关可观测性数据。 2252. 问题分析：参考相关可观测性数据，先分析排查硬件、系统原因，再分析诊断应用自身原因，大致定位问题。 2263. 解决方案：依据问题分析定位，回归代码本身，结合业务场景和API，找出适合解决方案，并使用相关可观测性数据验证优化方案。 227
