鸿蒙开发套件之DevEco Profiler助您轻松分析应用性能问题

鸿蒙开发套件之DevEco Profiler助您轻松分析应用性能问题 作者：shizhengtao，华为性能调优工具专家

应用的性能优化一直以来都是开发者所面临的一大难题，在2023HDC大会上全新亮相的HarmonyOS NEXT开发者预览版，其中鸿蒙开发套件DevEco Profiler，对应用卡顿这一问题的定位解决又提供了哪些能力呢？本文带你一探究竟。

一、Realtime Monitor，高效发现卡顿问题

Realtime Monitor实时监测应用运行过程中的一系列性能指标，并以可视化面板展示这些指标。开发者使用十分简单，只需在DevEco Profiler工具界面的左上角选择好您要观测的应用进程，这一功能即会自动打开。

在Realtime Monitor中，您可以看到如下指标项：

• 系统性能事件：借助HarmonyOS NEXT自带的性能检测能力，帮助您自动地发现一些与性能、稳定性相关的运行事件。
• 系统异常事件：借助HarmonyOS NEXT自带的异常检测能力，帮助您自动地发现一些异常的运行事件。
• 前台Ability：检测应用当前在前台显示的UIAbility，当发现异常指标时，您能够快速获知是在哪个UIAbility运行时产生的。
• CPU使用率：检测应用的CPU使用率和系统整体的CPU负载，持续过高的CPU占用往往会带来能耗过高的问题，是需要重点关注的。
• 内存使用量：检测应用的内存使用量和系统整体的内存负载，如果出现应用内存周期性上涨的情况，很可能有内存泄漏产生了，需要重点关注。
• 设备FPS：检测设备当前的FPS帧率，当应用界面静止而FPS很高时可能存在过度渲染问题，当应用界面变化大而FPS不高时则可能存在丢帧问题，也就是前面提到的流畅性问题。
• 设备GPU利用率：检测设备当前的GPU利用率，当FPS帧率不够时，通过GPU利用率和CPU利用率指标的对比，即可做一个初步的定界：瓶颈是在GPU侧还是在CPU侧。
• 器件能耗：检测应用使用各个物理器件的耗电量和总耗电量，帮助您快速分析应用当前的耗能分布情况。

借助这些实时的性能指标，您可以快速了解应用进程的运行性能，这样就能在应用产生某些性能问题时快速的发现和定界。

二、场景化分析，直击问题源码行

在DevEco Profiler工具的设计之初，我们便确定了一条核心理念，就是要提供场景化的低门槛调优工具，构建Top-Down式的UX交互设计，引导开发者分析性能数据时能够做到抽丝剥茧、层层递进，而不是一开始便直接陷入到数据海洋的细节之中。这在性能调优领域是十分重要的，我们希望将每一类性能问题背后的故障模型，通过界面设计直观地体现给开发者们。开发者们能够在拿到性能数据的第一时间，便完成对问题的初步定界和判断，然后有的放矢的去分析抓取到的数据，清晰的解决思路是解决性能问题的必备条件之一。除此之外还有极为重要的另一点则是，所有场景我们都希望能帮助开发者直接定位到问题代码行，通过工具定位到瓶颈函数后，可以直接双击函数栈帧，就可以快速在DevEco Studio的编辑器中打开相关源文件，开发者们可以马上进行分析优化。

在8月份HDC大会亮相的DevEco Profiler中，除了已经发布的用于函数热点和内存分析相关的基础调优模板之外，今年为各位开发者们带来了真正体现场景化这一理念的两大高级模板：Launch Insight和Frame Insight。

• Launch Insight：全面拆解应用冷启动过程，抓取不同阶段的耗时数据，帮助开发者快速分析冷启动过程的耗时瓶颈。
• Frame Insight：记录每一帧的渲染数据，自动标识其中的卡顿帧，并提供同时段的系统Trace信息和函数栈采样数据，帮助开发者高效分析卡顿位置和原因。

接下来，让我们一探Frame模板究竟，看看它到底是如何帮助开发者有的放矢、抽丝剥茧地分析丢帧问题的。

三、Frame Insight，高效定位卡顿问题

上一节我们提过，会将性能问题背后的故障模型直观地体现给开发者，因此在介绍Frame模板之前，首先需要各位开发者们先简单了解一下，在HarmonyOS NEXT中图形渲染的流程是怎样的，如果出现卡顿其可能的阶段和原因是什么。

在HarmonyOS NEXT中，图形系统采用了统一渲染的模式，遵循着一个典型的流水线模式，以60Hz刷新率为例，整个过程如下图所示，如果是90Hz，每个Vsync的周期就是11.1ms了。

在录制完成后，您可以观测到一系列数据泳道，如图所示。

在分析丢帧问题时，首先可以聚焦展开第一条Frame泳道。在这条泳道中，我们抓取了图形渲染过程的一些关键节点信息，并将其可视化了出来，如图所示。

通过这一条泳道，开发者们可以快速发现丢帧的位置，并完成初步的定界：如果是应用帧处理有红色出现，那需要进一步审视在UI线程中的处理逻辑，是否过于复杂或低效，又或者是被别的什么任务抢占了资源；如果是RenderService帧处理有红色出现，那需要审视是否是界面布局过于复杂。后者可以借助DevEco Studio内的ArkUI Inspector等工具进一步分析，本文不做过多阐述。针对前一种现象我们继续分析。

在找到了处理超时的帧之后，开发者们可以有两种选择，一种是分析system trace，另一种则是分析采样得到的函数热点。前一种方式需要对整个系统和关键的trace点有深入的了解，对于现阶段的开发者们可能还有些困难，所以我们还是建议开发者们直接分析函数热点。分析的方式很简单，找到ArkTS Callstack泳道，框选一下即可。这里有一个小技巧，开发者们可以点击泳道信息区的收藏按钮，将应用帧处理的泳道收藏置顶，可以有效防止上下文信息丢失。

将ArkTS Callstack泳道中红色帧的时段框选起来之后，就可以在下方详情面板中查看到这段时间的函数热点了。我们提供了两种函数热点展现形式供开发者选择，一种是Top-Down形式的一个树状列表；另一种则是许多开发者可能更耳熟能详的火焰图。开发者们可以选择自己习惯的方式去查看。一般来说，如果所选的时间段里，函数栈比较复杂的话，用火焰图找热点会更高效。