操作指南

性能提升之旅的升级指南

阅读用时:9 分钟
Alice Yuan
开发者关系工程师

性能提升之旅的升级指南

欢迎来到性能聚焦周的第 4 天。现在,您已经了解了我们最近推出的一些实用工具和最佳实践,例如 R8 优化器、配置文件引导型优化(包括 基准配置文件启动配置文件),您可能想知道从何处开始性能改进之旅。

我们制定了一份分步性能升级指南,旨在帮助您的移动开发团队了解自身所处的位置,无论您是只有一名开发者且刚开始关注性能的应用,还是拥有一个专门负责提升 Android 性能的团队,都可以参考这份指南。

性能升级指南分为 5 个级别。我们将从级别 1 开始,介绍采用工作量最少的性能工具,然后逐步升级到级别 5,该级别非常适合有资源维护定制性能框架的应用。


您可以随意跳转到最符合您需求的级别:

级别 1:使用 Play 管理中心提供的字段监控功能

我们建议您首先利用 Play 管理中心内的 Android Vitals 指标查看自动收集的字段监控数据,以便轻松了解应用的相关信息。

Android Vitals 指标是 Google 推出的一项功能,可自动收集这些字段数据并将其呈现给您。

下面介绍了我们如何提供这些数据:

  1. 收集数据: 当用户选择启用后,其 Android 设备会自动记录所有应用(包括您的应用)的关键性能和稳定性事件。
  2. 汇总数据: Google Play 会收集您应用的用户提供的这些数据并对其进行匿名化处理。
  3. 呈现分析洞见: 这些数据会显示在 Google Play 管理中心内的Android Vitals 信息中心内。

Android Vitals 信息中心会跟踪许多指标,但其中一些指标被指定为 Android Vitals 核心指标 。这些指标非常重要,因为它们可能会影响您的应用在 Google Play 商店中的曝光度和排名。

Android Vitals 核心指标

GOOGLE PLAY 的核心技术质量指标

为了最大限度提高应用在 Google Play 上的曝光度,请让应用始终保持在这些指标的不良行为阈值以下。

用户感知崩溃率可能至少注意到 1 次崩溃情况的日活跃用户数所占的百分比
用户感知的 ANR 发生率可能至少注意到 1 次 ANR 的日活跃用户数所占的百分比
电池用量过高每小时电池用量超过 4.44% 的表盘工作时段所占百分比
新增:过度使用局部唤醒锁定累计非豁免唤醒锁定使用时间超过 2 小时的用户会话所占百分比

Android Vitals 核心指标包括用户感知崩溃率、ANR 发生率、电池用量过高,以及新引入的过度使用局部唤醒锁定指标。

用户感知的 ANR 发生率

您可以使用 Android Vitals ANR 信息中心 查看在实际使用中发生的问题的堆栈轨迹,并获取有关如何解决问题的分析洞见和建议。

crashesAnrs.png

您可以深入了解发生的特定 ANR,查看堆栈轨迹以及有关可能导致该问题的分析洞见。

insights.png

此外,您还可以查看我们的 ANR 指南,帮助您诊断和解决可能发生 ANR 的常见场景。

用户感知崩溃率

使用 Android Vitals 崩溃信息中心 进一步调试崩溃问题,并查看应用内发生的堆栈轨迹示例。

我们的文档还提供了有关排查特定崩溃问题的指南。例如,排查前台服务问题指南讨论了如何识别和解决发生崩溃的常见场景。

耗电量过高

如需减少 Wear OS 上耗电量过高的表盘工作时段,请查看Wear 指南,了解如何改善和节省电量

[new] 过度使用局部唤醒锁定

 

我们最近宣布,对于超过过度使用局部唤醒锁定阈值的应用,我们可能会从 2026 年 3 月 1 日 开始采取额外措施。

对于移动设备,Android Vitals 指标适用于屏幕关闭且应用在后台运行或运行前台服务时获取的非豁免唤醒锁定。如果唤醒锁定在 24 小时内持有至少 2 小时,并且影响了应用超过 5% 的会话(以 28 天的平均值为准),Android Vitals 会认为局部唤醒锁定使用过多。

如需调试和解决唤醒锁定使用过多问题,请查看我们的技术博文

请参阅我们的 Android Vitals 文档,继续了解如何更好地利用 Android Vitals。

级别 2:按照应用性能得分操作项进行操作

接下来,使用应用性能得分查找高杠杆操作项,以提升应用性能。

Android 应用性能得分是一个用于衡量应用技术性能的标准化框架。它会为您提供一个介于 0 到 100 之间的分数,分数越低,说明改进空间越大。

如需轻松获得成功,您应首先从 静态性能得分 开始。这些通常是配置更改或工具更新,可显著提升性能。

第 1 步:执行静态评估

静态评估会评估项目的配置和工具采用情况。这些通常是提升性能的最快方法。

前往记分板页面的“静态得分”部分,然后执行以下操作:

  1. 评估 Android Gradle 插件 (AGP) 版本。
  2. 逐步采用 R8 缩减功能 增量,或者最好使用 R8 的完整模式 来缩减和优化应用代码。
  3. 采用 基准 配置文件,该文件可从首次启动时提高代码执行速度,从而针对每次新应用安装和每次应用更新提升性能。
  4. 采用 启动配置文件 来改进 Dex 布局。构建系统使用启动配置文件,通过改进 APK 的 DEX 文件中的代码布局,进一步优化其中包含的类和方法。
  5. 升级到最新版本的 Jetpack Compose

第 2 步:执行动态评估

应用静态轻松获胜后,使用动态评估在真实设备上验证改进情况。您可以先使用实体设备和秒表手动执行此操作。

前往记分板页面的“动态得分”部分,然后执行以下操作:

  1. 使用实体设备设置测试环境。可以考虑使用低端设备来放大性能问题,以便更轻松地发现问题。
  2. 测量使用启动器时的启动时间。从启动器图标冷启动应用,并测量应用变为可交互状态所需的时间。
  3. 测量从通知启动应用所需的时间,目标是将通知启动时间缩短到几秒以内。
  4. 通过滚动浏览核心屏幕和动画来测量渲染性能。

完成这些步骤后,您将获得一个介于 1 到 100 之间的静态得分和动态得分,从而了解应用的性能以及需要重点关注的方面。

级别 3:利用本地性能测试框架

开始评估动态性能后,您可能会发现手动测量性能过于繁琐。可以考虑使用 Macrobenchmarks 和 UiAutomator 等性能测试框架自动执行性能测试。

Macrobenchmark 💚 UiAutomator

您可以将 Macrobenchmark 和 UiAutomator 视为协同工作的两个工具:Macrobenchmark 是测量工具。它就像一个在应用外部运行的秒表和帧速率计数器。它负责启动应用、记录指标(例如启动时间或丢帧)和停止应用。UiAutomator 是机器人用户。借助该库,您可以编写代码与设备的屏幕进行交互。它可以查找图标、点按按钮、在列表中滚动等。

如何编写测试

编写测试时,您需要将 UiAutomator 代码封装在 Macrobenchmark 代码块内。

  1. 定义测试: 使用 @MacrobenchmarkRule
  2. 开始测量: 调用 benchmarkRule.measureRepeated
  3. 驱动界面: 在该代码块内,使用 UiAutomator 代码启动应用、查找界面元素并与之交互。

以下是一个示例代码段,展示了如何测试 Compose 列表的滚动卡顿情况。

  benchmarkRule.measureRepeated(

    // ...

    metrics = listOf(

        FrameTimingMetric(),

    ),

    startupMode = StartupMode.COLD,

    iterations = 10,

) {

    // 1. Launch the app's main activity

    startApp()

    // 2. Find the list using its resource ID and scroll down

    onElement { viewIdResourceName == "$packageName.my_list" }

        .fling(Direction.DOWN)

}

4. 查看结果:每次测试运行都会为您提供精确的测量信息,以便您获得有关应用性能的最佳数据。

  timeToInitialDisplayMs  min  1894.4,   median 2847.4,   max  3355.6


frameOverrunMs          P50 -3.2,  P90  6.2, P95  10.4, P99  119.5

常见用例

Macrobenchmark 提供了多个开箱即用的核心指标。借助 StartupTimingMetric,您可以准确测量应用启动时间。借助 FrameTimingMetric,您可以了解应用在测试期间的渲染性能。

我们提供了有关如何结合使用 MacrobenchmarksUiAutomator 的详细完整指南,并附有 代码示例,供您继续学习。

级别 4:使用 Perfetto 等跟踪记录分析工具 

当您需要查看应用代码以外的内容时,可以使用 Perfetto 等跟踪记录分析工具。与仅查看您的进程的标准调试程序或性能分析器不同,Perfetto 会捕获整个设备状态(内核调度、CPU 频率、其他进程和系统服务),从而为您提供有关性能问题的完整背景信息。

请查看我们的 性能调试 YouTube 播放列表,观看有关使用系统跟踪记录、Android Studio 性能分析器和 Perfetto 进行性能调试的视频说明。

如何使用 Perfetto 调试性能

使用跟踪记录分析工具调试性能的一般工作流程是记录、加载和分析跟踪记录。

第 1 步:记录跟踪记录

您可以使用多种方法记录系统跟踪记录:

第 2 步:加载跟踪记录

获得跟踪文件后,您需要将其加载到分析工具中。

  1. 打开 Chrome 并前往 ui.perfetto.dev
  2. .perfetto-trace(或 .pftrace)文件直接拖放到浏览器窗口中。
  3. 界面将处理该文件并显示时间轴。

第 3 步:分析跟踪记录

您可以使用 Perfetto 界面或 Android Studio 性能分析器来调查性能问题。请观看 MAD 技巧 系列中有关性能的这一集,我们的性能工程师 Carmen Jackson 将在其中讨论 Perfetto 跟踪记录查看器。

使用 Perfetto 检查系统跟踪记录的场景

Perfetto 是一款专业工具,可以提供有关在捕获跟踪记录期间 Android 设备上发生的所有事件的信息。当您无法使用标准日志或基本性能分析器找出运行速度减慢的根本原因时,此功能特别有用。

调试卡顿(丢帧)

如果您的应用在滚动时出现卡顿,Perfetto 可以准确显示特定帧错过截止时间的原因。

如果是应用导致的问题,您可能会看到主线程长时间运行并执行大量解析;这表明您应将工作移到异步处理中。

如果是系统导致的问题,您可能会看到主线程已准备好运行,但 CPU 内核调度程序优先处理了其他系统服务,导致您的应用处于等待状态(CPU 争用)。这表明您可能需要优化平台 API 的使用。

分析应用启动缓慢问题

启动过程非常复杂,涉及系统初始化、进程派生和资源加载。Perfetto 可以准确地可视化此时间轴。

您可以查看是否在等待 Binder 调用(进程间通信)。如果 onCreate 等待系统 PackageManager 的响应时间过长,Perfetto 将清楚地显示该阻塞状态。

您还可以查看应用在启动期间是否执行了不必要的操作。例如,如果您创建和布局的视图数量超过应用需要显示的视图数量,您可以在跟踪记录中看到这些操作。

调查耗电量和 CPU 使用率问题

由于 Perfetto 可以查看整个系统,因此非常适合查找不可见的耗电问题。

您可以在“设备状态”轨迹下识别持有唤醒锁定并阻止设备进入休眠状态的进程。如需了解详情,请参阅我们的 唤醒锁定博文。此外,您还可以使用 Perfetto 查看后台作业是否运行过于频繁或不必要地唤醒 CPU。

级别 5:构建自己的效果跟踪框架

最后一个级别适用于拥有团队且有资源维护效果跟踪框架的应用。

在 Android 上构建自定义性能跟踪框架涉及利用多个系统 API 来捕获整个应用生命周期(从启动到退出)以及特定高负载场景中的数据。

通过使用 ApplicationStartInfoProfilingManagerApplicationExitInfo,您可以创建一个强大的遥测系统,该系统可以报告应用的启动方式、运行期间执行的详细操作以及终止原因。

ApplicationStartInfo:跟踪应用的启动方式

ApplicationStartInfo 从 Android 15(API 35)开始提供,可提供有关应用在实际使用中的启动情况的详细指标。这些数据包括是冷启动、温启动还是热启动,以及不同启动阶段的持续时间。

这有助于您使用生产数据开发基准启动指标,以便进一步优化可能难以在本地重现的启动过程。您可以使用这些指标运行 A/B 测试,优化启动流程。

目标是准确记录启动指标,而无需手动检测每个初始化阶段。

您可以在应用启动后的一段时间内延迟查询这些数据。

ProfilingManager:捕获运行缓慢的原因

ProfilingManager (API 35) 借助 ProfilingManager (API 35),您的应用可以以编程方式触发用户设备上的系统跟踪记录。这对于捕获您无法在本地重现的临时性能问题非常有用。

目标是当检测到特定高度关键的用户历程运行缓慢或遇到性能问题时,自动记录跟踪记录。

您可以注册一个监听器,该监听器会在满足特定条件时触发,或者在检测到卡顿、内存使用过多或耗电量过高等性能问题时手动触发。

请查看我们的文档,了解如何捕获配置文件检索和分析性能分析数据以及使用调试命令。

ApplicationExitInfo:跟踪应用终止的原因

ApplicationExitInfo (API 30) 会告知您上一个进程终止的原因。这对于查找原生崩溃、ANR 或因内存用量过多 (OOM) 而导致的系统终止至关重要。您还可以使用 API getTraceInputStream 获取详细的墓碑跟踪记录。

该 API 的目标是了解不会触发标准 Java 崩溃报告程序(例如低内存终止守护程序)的稳定性问题。

您应在 下次应用启动时触发此 API。

后续步骤

提升 Android 性能是一个循序渐进的过程。我们非常期待看到您如何使用这些工具提升性能!

明天观看 Ask Android

您已使用 R8 缩减了应用大小,并使用配置文件引导型优化优化了运行时。并测量了应用的性能。

欢迎明天观看 Ask Android 直播会话。立即使用 #AskAndroid 提问,专家将为您解答。

作者:

继续阅读