Android 性能优化的术、道、器

字数统计: 7.8k阅读时长: 27 min

 2022/01/07

黑客与画家

Paul Graham 在其著作 <黑客与画家> 中断言：“不同语言的执行效率差距正变得越来越大，所以性能分析器（profiler）将变得越来越重要。目前，性能分析并没有受到重视。许多人好像仍然相信，程序运行速度提升的关键在于开发出能够生成更快速代码的编译器。代码效率与机器性能的差距正在不断加大，我们将会越来越清楚地看到，应用软件运行速度提升的关键在于有一个好的性能分析器帮助指导程序开发。”
by Paul Graham 黑客与画家

谷歌搜索「Android 优化工具」，你会找到很多与此相关的内容。他们的问题在于要么是内容高度重复、要么是直接讲使用方法，很少会给你介绍整体性的架构，一不小心就会让人会种「一个工具搞定一切」的错误认知。以笔者团队的多年经验来看，在性能分析领域这种银弹级别的工具是不存在的。工具在发展，老问题会以新的方式变样出现，不掌握核心逻辑的话始终会让你浮于技术的表面。

本文首先系统性的梳理性能分析中的可观测性技术，它涵盖数据类型、抓取方法以及分析方法等三部分内容，之后是介绍谷歌提供的传统「三大件」分析工具。目的是想让你了解数据与测量的基本概念，以及与之对应的在安卓环境中可用的工具，这些可以让你少走一些弯路，直接复用前辈们的经验。

技术复核（2026-10-14）： 本文发表于 2022 年 1 月，Systrace 与 Studio 截图保留为历史示例，下文已补充当前入口与证据边界。介绍的三类工具是 Systrace、Perfetto 和 Android Studio Profiler，不代表每个性能问题都必须依次使用它们。

现在排查问题，应把系统跟踪、可重复测量与线上信号结合起来。FrameTimeline 需要 Android 12 / API 31 及以上，并且采集时包含对应数据。用 Macrobenchmark 指标中的 StartupTimingMetric、FrameTimingMetric 固化场景、控制条件，再比较优化前后。Baseline Profiles、Startup Profiles 是优化输入，不是测量结果或优化有效的证明。Android vitals提供来自符合条件、允许采集的设备的 Google Play 线上信号，不能覆盖全部用户与所有渲染路径，还需按产品补充埋点。

1 性能分析中的可观测性技术

这个操作到底有没有被执行？执行时间有多长？
为什么两个版本的前后差异这么大？
当 CPU 使用量变高的时候系统都在执行什么操作？
为什么启动速度变慢了？
为什么这个页面滑动总是会卡一下？

相信你不止一次被同事、被老板问到过类似的问题。最原始的想法应该是，首先是拿到相关的日志进行逐个分析。根据以往经验，通过查找关键字寻找蛛丝马迹。如果没有想看的信息，那就加上日志尝试本地复现。费时费力不说，也还费研发资源。但你有没有想过行业里有没有更高效的方法？可以提高一个数量级的那种，把我们的时间花在问题解决上而不是无聊的重复性体力活儿上？

答案当然是有的（否则就不会有这篇文章了），我们称他为可观测性技术。

可观测性通过记录与分析运行信息，帮助我们理解复杂系统。采集内容应围绕问题选择：更细的数据可能增加开销，却未必增加解释力。

如果你的程序部署了一个精心设计且运行良好的可观测性技术，可以大大加快研发软件的效率，因为即使我们使用了各种各样的前置性静态代码检测、人工代码审查，也无法 100% 拦截软件的问题。只有在真实环境里运行之后才知道是否真正发生了问题，即使这个环境可能是一个你的自动化测试用例。即使这样，你还需要翻阅你的日志，重读代码来找出问题。出于这些原因，每个工程团队都需要有一个功能完备的可观测性工具作为他们的基础设施之一。

可观测性技术是一个系统性工程，它能够让你更深入的了解软件里发生的事情。可用于了解软件系统内部运行过程（特别是对于业务逻辑或者交互关系复杂的系统）、排查问题甚至通过寻找瓶颈点优化程序本身。对于复杂的系统来说，你通过阅读代码来了解整个运行过程其实是很困难的事情，更高效的方法就是借助此类工具，以最直观的的方式获取软件运行的状态。

下面将从数据类型、数据获取方法、分析方法这三个主题来帮助你了解可观测性技术。

1.1 数据类型

Log、Metric、Trace 描述了系统运行的不同侧面，并不是三种文件格式，也不是把所有数据都归入「日志」后的穷尽分类；Profile 还可以描述代码层面的资源消耗。JSON、数据库或二进制流都可能承载多种信号。记录只能说明埋点与采集配置覆盖到的行为，不能还原系统的全部状态。可对照 OpenTelemetry 的信号定义。

数据类型

图中 Counter / State 是本文的简化分类，不等同于各遥测系统的标准指标类型。

Log 类型

Log 记录一次事件，通常包括时间、来源、等级和消息正文或结构化字段。逐行文本很常见，但也有结构化日志和二进制日志。带有合适时间戳与关联标识的日志可以生成指标，或帮助重建部分调用关系；缺失的关联信息不能靠转换格式补出来。

错误、警告、调试等级有助于筛选记录，但日志等级不等于性能问题的重要程度。一次调度延迟可能没有任何错误日志。应按问题选择信息，并考虑格式化、采集和存储的成本。

Metric 类型

Metric 记录 CPU 使用率、CPU 频率、上下文切换次数等数值。需要区分瞬时观测值、累计计数器和窗口内的聚合统计值。把累计计数转成速率时，要计算相邻记录的差值、经过的时间，并处理计数器重置。

例如，计算问题发生前五分钟的平均 CPU 使用率，要先说明窗口和分母：单核、整机全部核，还是某个进程。等间隔的使用率样本可用算术平均，不等间隔则应按覆盖时间加权。「越靠近问题权重越高」得到的是另一种统计量，不能直接称为这五分钟的平均使用率。缺失样本不能补成零，均值也可能掩盖短时尖峰。

数值型结构通常能减少解析工作，也可能节省空间，但 Metric 不一定采用固定字节编码，Log 也不一定采用 ASCII。实际开销取决于编码、标签及其基数、压缩和采样频率。枚举值可以描述状态，但对状态编号求平均通常没有业务意义。

Trace 类型

Trace 可以记录事件名称、时间点、区间、计数以及关联关系，适合观察函数执行、Binder 事务和跨线程、跨进程的工作流。父子关系、异步关联标识需要被记录，或按明确的协议推导；仅凭两个事件在时间上接近，不能确定因果关系。

Android 应用通过 Binder 与系统服务交互。跟踪一次事务可能需要客户端、服务端和调度数据。同步调用的长区间可能包含排队、等待和执行，不能直接当作 CPU 消耗。

手动 Trace 区间和方法入口/出口插桩能给出所覆盖代码的明确边界，但看不到未插桩的函数。密集的方法跟踪还会改变程序时序。统计耗时时，也不能把嵌套区间简单相加，否则会重复计算。

调用栈采样回答的是「采样时观察到了哪些栈，它们占多少采样权重」。它不记录每一次调用，也不给出精确的入口/出口时间，短函数可能被漏掉。缩短采样间隔可能改善覆盖，也会增加开销，并不保证结果更接近真实运行。Profiler 还包括插桩类工具，不是采样的专有名称。

1.2 数据获取方法

数据获取方法

静态代码与动态跟踪

静态插桩在源码、生成代码或库中加入记录点。新增缺失的记录点通常需要重新构建、部署；已有的开关则可以启用预先放好的记录点。一次记录缺少信息，并不意味着只能重编整个程序，也可以结合其他信号或重新采集。

动态跟踪可以挂接已有 TracePoint，也可以在不修改目标源码的情况下增加探针。它不要求所有探针都由应用预埋，也不要求使用动态类型语言。例如，Linux uprobes 可以在内核支持时跟踪用户态二进制中的指定偏移，kprobes 则面向内核代码。

Android 已有 eBPF 基础设施，但普通应用不会因此获得任意跟踪系统的权限。能否使用取决于内核配置、探针支持、权限和 SELinux 策略。应按目标系统与部署条件选择工具，不能概括为「只有内核开发者能用」，也不能认为所有零售手机都能直接使用。

无条件式抓取与有条件式抓取

无条件式抓取是在一个配置好的会话中持续记录选定数据源，不等待异常触发。开销取决于事件频率、调用栈采集、缓冲和存储方式。应减少无关数据，同时保留回答问题所需的事件。

有条件式抓取通过检测器决定何时开始或结束记录，检测器本身也有成本。异常发生后才开始抓取，无法恢复此前没有记录的数据；持续写入有限缓冲、异常后停止，则可能保留近期历史，但触发前同样有采集开销。这是两种不同策略，不能统称为「不出问题时没有任何影响」。

落盘策略

持续写文件能支持更长的记录，但会增加 I/O 和存储开销。另一种方式是把近期数据放进内存环形缓冲，触发后结束并保存。可保留多久取决于容量与事件速率：旧记录会被覆盖，生产端也可能独立发生丢失。

Perfetto 区分覆盖旧数据、丢弃新数据等缓冲策略，也支持定期写入文件。触发成功不代表根因一定仍在缓冲中。解释「没有看到某事件」之前，应检查采集时长、数据源、缓冲大小和丢失统计。参见缓冲机制与采集配置。

1.3 分析方式

分析方式

数据可视化分析

时间线把事件放在进程、线程或其他轨道上，便于对照时间与已记录的关联关系。Systrace、Perfetto 提供这类视图，KernelShark 则用于相关的 Linux 跟踪分析。区间重叠可以提供线索，但本身不构成因果证明。

旧 Systrace 查看器属于 Catapult 项目。Trace Event Format 定义的是特定格式，不意味着任意 JSON 日志都能直接显示为 Trace。现在也可以使用 Perfetto 导入受支持的格式，具体以格式列表为准。

数据库分析

把采集数据整理成表后，可以重复查询、聚合与比较。例如，Perfetto Trace Processor 通过 SQL 暴露 Trace 数据，Python 可以组织查询和结果，形成自动化分析。服务端常见的 Elastic 技术栈则提供结构化日志搜索等能力，有自己的查询模型。

文本、可视化、SQL 是互补手段：先搜索定位事件，再看时间线上下文，最后统计多次出现的情况。不能按「一个模块必须用文本、多个模块必须用可视化」划死边界。转换数据时要保留单位、时间边界和关联标识，才不会在换工具后改变问题的口径。按目的选方法，才能事半功倍。

2 谷歌提供的 Andorid 性能分析工具

本文介绍的三类工具是 Systrace、Perfetto 和 Android Studio Profiler，这是原文写作时团队常用的入口。具体先用哪个取决于所缺的证据；例如，堆内存问题可能应先用内存工具。下面保留原来的工具顺序，最后的表格用于比较能力边界，不代表固定的排查流程。

2.1 初代系统性能分析工具 - Systrace

Systrace 是 Android 历史上的系统跟踪工作流，能可视化选定的应用、Framework 和内核事件。它从来不是唯一的性能工具。系统跟踪通常比逐个方法记录入口/出口干扰小，但开销不为零，也会随类别和事件量变化。新问题优先使用当前的 Android 系统跟踪与 Perfetto。

Systrace

Systrace 的设计思路

Android 会在输入分发、绘制、进程通信等流程中标记部分操作。通过 android.os.Trace、Native ATrace API 产生的用户态标记，与 sched_switch、cpu_idle 等内核事件不是同一种来源；历史采集链路可以经由 ftrace 把它们收集在一起。

上图同时展示了 tracing_mark_write 标记与内核事件。Framework Java 代码、应用代码可以写 Trace 区间，Native Framework 也有对应的 ATrace 接口。最终能看到哪些信息，还取决于类别、应用选择、权限、内核支持与缓冲丢失。它能让系统的部分运行过程可见，不能把整个 Android 变成完整的白盒。

实践中的应用情况

系统 Trace 可以帮助分析启动慢、点击响应慢、列表滑动、窗口动画和无响应区间。在相关数据源齐备时，调度、Binder 等信息还能帮助区分执行和部分等待。

ANR 还需要结合触发原因与线程栈；闪退可能需要 logcat、异常栈或 Native tombstone。不能仅凭一张时间线解释所有故障。旧 Systrace HTML 对应的是历史查看器流程；新采集应使用当前系统跟踪工具，并在 Perfetto UI 中打开受支持的 Trace。

2.2 新一代性能分析全栈工具 - Perfetto

Perfetto 提供系统与应用跟踪的采集、可视化和分析组件，是当前 Android 系统跟踪的主要方向。格式兼容也不等于具备每个旧查看器的全部功能。

其服务模型区分生产者、数据源、跟踪服务与消费者，因此不仅能收集 ftrace，也可以把不同来源的数据放入同一份记录。

提供的亮点功能

生产者提供已配置数据源的记录，服务负责会话与缓冲。内核 ftrace 和 Android 用户态标记是重要来源，但进程统计、堆分析等有不同采集路径。原生 Trace 使用 protobuf 消息，不是 SQLite 数据库文件。

Perfetto

Perfetto 可以在内存中缓冲，也可以持续写文件。长时间采集仍受缓冲容量、事件速率、存储与开销限制。官方 Android log 数据源文档明确标注为 userdebug-only，因此不能指望普通 user 版本的 Trace 一定带有 logcat。轨道或样本缺失不等于没有活动。

网页、命令行和 Android 的系统跟踪应用是不同采集入口。Trigger API 激活的是获授权消费者预先配置好的会话中的触发名称：START_TRACING 在触发后开始记录；STOP_TRACING 可结束已在记录的会话，保留有限的触发前历史。应用能发出 trigger，不代表它能任意配置全系统采集。

Trace Processor 解析 Trace 后，通过 UI、命令行和 API 提供 SQL 表，无须先导出 SQLite 文件。Python、DataFrame 可以组织自动化分析。大文件可考虑 Native Trace Processor，但内存和解析成本仍有限制；「300 MB」不是任何查看器通用的崩溃阈值。

例如，计算 SurfaceFlinger 的 CPU 消耗，要先明确指整个进程还是某条线程，再统计选定窗口内实际运行的调度区间。把嵌套函数的 wall time 相加会重复计算，也会混入等待。判断哪些线程运行在大核上时，还要按设备实际拓扑映射 CPU 编号。

实践中的应用情况

Perfetto 适合作为许多系统时序问题的首个分析入口。但它并不是能任意添加动态探针的 eBPF 跟踪框架，也无法补出数据源没有记录的事件。

不能仅凭 protobuf 编码就断言开销很高或可以忽略；应在目标负载下测量所选数据源、采样、缓冲与文件写入的影响。命令行 Trace Processor 支持脚本化 SQL 与文本输出，分析方式并不限于网页。

2.3 Android Studio Profiler 工具

Android Studio 把应用开发与性能分析集成在一起。当前 Profiler 工作流围绕任务与录制结果组织界面，旧的「CPU、Memory、Network、Battery 四类面板」已不能作为通用入口说明。

Network Inspector 位于 View → Tool Windows → App Inspection，支持范围取决于网络库。Power Profiler 从 Android Studio Hedgehog 2023.1.1 引入；ODPM 电源轨需要受支持的 Pixel 硬件，并不是所有 Android 手机都具备的通用电量表。

目标任务支持时，优先使用接近 release 的 profileable 构建。Java/Kotlin 分配记录、堆转储等任务则需要 debuggable 应用。对比结果时记录 Studio、Android、应用构建与采集配置，避免把 Debug 模式或插桩开销的变化误当成优化效果。

提供的亮点功能

下图的历史 CPU Profiler 菜单提供几类不同证据：

System Trace：记录选定的调度、绘制与插桩区间。界面的聚合或过滤不等于「所有短事件都被丢弃」；需要更广的系统视角时，可把受支持的录制文件导入 Perfetto UI。
Java/Kotlin 采样或方法跟踪：调用栈采样估计执行被观察到的位置；入口/出口插桩能展示调用边界，但干扰更大，两者不能当作同一种测量。
Native 采样：历史工作流以 simpleperf 收集 Native 栈，并非完整的 C/C++ 入口/出口记录。simpleperf 既支持硬件 PMU 事件，也支持软件事件；可用事件、栈回溯与符号取决于目标环境。参见 simpleperf 文档。

CPU Profiler

这是保留用于解释原案例的旧版 Studio 菜单；当前任务名和可用录制选项以 Studio、Android 版本为准。

实践中的应用情况

响应慢和卡顿是常见的时序问题，性能分析还包括内存、功耗等方面。面对不熟悉的绘制问题，可以先用系统 Trace 定位长区间，再用方法或 Native 分析补充证据。是否继续下钻取决于尚未解释的问题，不要求每次都依次运行三种工具。

假设拿到一个性能很差的应用，你又不熟悉它的代码，该从哪里找起？这个历史案例中，egl_core 上的 onDrawFrame 存在较长区间，选中部分的经过时间约一秒。区间名称本身不能证明它对应哪个源码方法，也不能证明消耗了一秒 CPU，需要对照源码埋点与调度信息。

Java 录制把范围缩小到 Utils.onDraw。选中区间显示 wall time 约 1 s，而 CPU time 仅 402 μs，这份记录更像是在等待，而非持续计算了一秒。两者对应的优化方向不同。

Native 视图出现了 Java_com_gl_shader_Utils_onDraw → sleep → nanosleep 调用链，因此 sleep 是解释延迟的候选原因。但三图来自不同录制，显示的 CPU time 也不能拼成一份统一的 CPU 账本。本文没有提供可重新解析的完整采集文件与示例源码；要验证修复，还需确认源码中的 sleep，结合新采集的调度信息，并在移除后用相同场景复测。

Studio 的集成使应用开发者能够方便地下钻；涉及全系统行为时，仍可能需要额外工具与权限。

2.4 综合对比

触发、缓冲和落盘是不同维度，不能把所有工具都归为「无条件抓取、持续落盘」。下面按用途与证据边界比较。

工具	主要用途	证据与限制
Systrace	历史 Android 系统跟踪	选定的内核事件与用户态标记；旧查看器工作流
Perfetto	系统与应用跟踪	配置好的事件、计数、调用栈等来源；内存/文件与 trigger 模式；UI、SQL 分析
Android Studio Profiler	面向应用的分析任务	按任务、构建条件提供系统 Trace、采样、方法记录、堆或分配数据
simpleperf	CPU 事件计数与调用栈采样	硬件或软件事件；采样权重不是调用次数；文本与可视化报告
Snapdragon Profiler	受支持的 Snapdragon 平台	CPU、GPU 及部分平台的 DSP 分析；DSP 并非全部平台可用
历史 Mali Graphics Debugger / Graphics Analyzer	受支持设备的图形 API 调试	Arm 表明 Graphics Analyzer 最后包含于 Performance Studio 2024.2；按当前 Arm 工具说明选择工作流
Android logcat / dumpsys	事件日志 / 服务诊断	日志缓冲与服务快照、报告是不同来源；是否持久化取决于采集和输出方式
Android GPU Inspector	受支持的 Android GPU 系统/帧分析	受设备、驱动、Android 版本与图形 API 限制
eBPF 工具	可编程跟踪与聚合	按程序与挂接点产生事件、统计或调用栈；需要对应权限与内核支持
ftrace	Linux 跟踪基础设施	内核事件、函数跟踪及受支持的动态探针；缓冲与输出策略可配置

GPU 工具应按实际 GPU、驱动、系统与 API 支持矩阵选择，不能仅凭 SoC 厂商品牌判断是否兼容 Mali 或 Adreno。

3 关于「器、术、道」

技术上的变革、改进更多是体现在「器」层面，Linux 社区以及谷歌所开发的工具发展方向朝着提高工具的集成化使得在一个地方可以方便查到所需的信息、或者是朝着获取更多信息的方向发展。总之，器层面他们的发展轨迹是可寻的，可总结出发展规律。我们需要在工具快速迭代的时候准确的认识到他们能力以及应用场景，其目的是提高解决问题的效率，而不是把时间花在学习新工具上。

「术」层面依赖具体的业务知识，知道一帧是如何被渲染的、CPU 是如何选择进程调度的、IO 是如何被下发的等等。只有了解了业务知识才能正确的选择工具并正确的解读工具所提供的信息。随着经验的丰富，有时候你都不需要看到工具提供的详细信息，也可以查到蛛丝马迹，这就是当你业务知识丰富到一定程度，大脑里形成了复杂的关联性信息之后凌驾于工具之上的一种能力。

「道」层面思考的是要解决什么问题，问题的本质是什么？做到什么程度以及需要投入什么样的成本达成什么样的效果。为了解决一个问题，什么样的路径的「投入产出比」是最高的？整体打法是什么样？为了完成一件事，你首先要做什么其次是做什么，前后依赖关系的逻辑又是什么？

后续的文章中，会依照「器、术、道」方式讲解一个技术、一个功能，我们不止想让你学习到一个知识点，更想激发你举一反三的能力。遇到类似的工具或者类似的问题、更进一步是完全不同的系统，都能够从容应对。牢牢抓住本质，通过评估「投入产出比」选择合适的工具或信息，高效解决问题。

4 关于「The Performance 知识星球」

历史说明： 下面保留的是这篇 2022 年文章中的社群规划。The Performance 已于 2026 年停止运营，不再接受新成员；这里记录当初想做的事情，不是当前服务承诺。

为了更好地交流与输出高质量文章，我们创建了名为「The Performance」的知识星球，主理人是三个国内一线手机厂商性能优化方面的一线开发者，有多年性能相关领域的工作经验，提供Android 性能相关的一站式知识服务，涵盖了基础、方法论、工具使用和最宝贵的案例分析。

目前星球的内容规划如下（两个 ## 之间的是标签，相关的话题都会打上对应的标签，方便大家点击感兴趣的标签查看对应的知识）

#The Performance# — 可以提早阅读「Android 性能优化 - 系统性课程」的电子书，每周会放出已经写好的章节。「Android 性能优化 - 系统性课程」是我们规划的一本讲 Android 性能优化的电子书，目前开发者社区有相当多高质量的性能优化理论知识和实践文章和开源库，但是目前市面上缺乏一个完整的、系统性的、包含了性能优化原理、工具、实践等内容、面向初级开发中和中级开发者、面向 App 开发者和系统开发者，且持续更新的 Android 性能优化工具书。书的大纲 (暂定) 我们已经基本上列好了，预计会花费一年左右的时间来完成，在星球中会放出写好的章节，让大家提前看到。
Part 1: → 性能工程
Part 2: → 以性能角度分析 Android 交互与核心系统
Part 3: → 以性能角度分析 Linux 内核核心子系统设计与实现
Part 4: → 问题场景分析思路
Part 5: → 分析与调试工具
Part 6: → 质量守护 - 性能监控方法与工具
#性能工具# — 分享 Android 开发中使用到的性能分析工具以及其使用方法，同时也提供 1V1 的 Systrace、Perfetto 等性能工具的视频指导。性能工具的使用，最好还是以视频的方式展示会直观很多，文章是静态的，很多地方比较难讲清楚，1V1 的视频会议指导也算是一个学习的方法
#案例分析# — 典型案例分析思路总结、球友提供的案例分析与讨论。案例分析是学习的一个很重要的途径，阅读大量的实际性能案例对以后自己分析和解决性能问题是非常有帮助的，同时也欢迎大家提供案例和解决方法，怕泄露信息的话，我们会对关键信息进行打码
#经典解读# — 经典方案、课程重读，例如优秀的三方库解析、Android 开发高手课重读等。比如可以对方案进行深度的剖析，横向对比等；对 Android 开发高手课进行重读和查漏补缺
#知识分享# — 优秀文章、博客、工具分享。业界有很大大牛的博客、经过实际业务考验的开源方案、各种性能工具等，我们会寻找这些优秀的内容，分享给大家
#知识沉淀# — 微信群聊精华、微信问答、博客留言解答等
#性能面试# — Android 性能相关的面试题搜集和解答，也算是刚需了吧
#编程语言# — 编程语言相关的使用技巧分享
#效能提升# — 效能提升分享，包括开发者开发效能、工作效能提升方法、工程效率、工具推荐等，磨刀不误砍柴工嘛
#行业动态# — 性能相关新技术第一时间解读报告，包括但不限于下面的内容
行业峰会、学术峰会新思路解读报告
论文、行业、书籍介绍、视频
Android 大版本性能相关介绍
Android 新硬件性能相关内容介绍
Android 性能相关开源项目解读
#大咖分享# — 每月定期邀请行业大咖进行经验分享、案例分析
#工作内推# — 各大厂商内推工作机会介绍