Android Perfetto 系列 1：Perfetto 工具简介

字数统计: 5.1k阅读时长: 18 min

 2024/05/21

本篇是 Perfetto 系列文章的第一篇，主要是简单介绍 Perfetto 工具，包括 Perfetto 的历史、发展，以及 Perfetto 能做什么。

Android 官方将 Systrace 列为 legacy 工具，并推荐在 Android 10 及以上使用 Perfetto。写下本文时，Perfetto 在我的日常工作中已经基本取代 Systrace，我接触到的 OPPO、vivo 团队也在迁移。许多新接触 Android 性能优化的小伙伴面对复杂的界面和功能，希望我能把之前的 Systrace 文章用 Perfetto 来呈现。

技术核查：2026-10-14。 本文初稿和截图来自 2024 年，保留当时的使用体验。下面补充 Android 10/11/12 的数据源边界，以及 Perfetto v48.0/v49.0 的 UI 更新；具体可见数据仍取决于设备、采集配置和工具版本。

Paul Graham 说：要么给大部分人提供有点想要的东西，要么给小部分人提供非常想要的东西。Perfetto 其实就是小部分人非常想要的东西，那就开始写吧，欢迎大家多多交流和沟通，发现错误和描述不准确的地方请及时告知我，我会及时修改，以免误人子弟。

我想借这个系列，和大家一起对照 Perfetto 看 App、Framework、Linux 是怎么配合起来运行的。如果读过不少源码和性能文章，还是记不住流程，不妨把代码放回 Trace 的时间线上看看。

Perfetto 系列目录

如果大家还没看过 Systrace 系列，下面是传送门：

Systrace 系列目录：系统介绍了 Perfetto 的前身 Systrace 的使用，并通过 Systrace 来学习和了解 Android 性能优化和 Android 系统运行的基本规则。
个人博客：个人博客，主要是 Android 相关的内容，也放了一些生活和工作相关的内容。

欢迎大家在关于我页面了解微信群入口，讨论你的问题、你最想看到的关于 Perfetto 的部分，以及跟各位群友讨论所有 Android 开发相关的内容

正文

2019 年开始写 Systrace 系列，陆陆续续写了 20 多篇，从基本使用到各个模块在 Systrace 上的呈现，再到启动速度、流畅性等实战，基本上可以满足初级系统开发者和 App 开发者对于 Systrace 工具的需求。通过博客也加了不少志同道合的小伙伴，光交流群就建了有 6 个。这里非常感谢大家的支持。

所以就有了这个系列，我也有在星球里面写了几条为什么要更新 Perfetto 系列的原因（之前一直觉得 Systrace 系列就够了）：

按我在 2024 年接触到的团队情况，OPPO、vivo 的不少同事已经使用 Perfetto 抓取和分析 Trace。很多新人先接触的是 Perfetto；如果我一直守着旧的 Systrace 系列，就会错过这部分读者。
之前 Systrace 系列引用的源码已经比较老。系列后续会补充 Android 17（API 37）等新版本的变化，但每篇以注明的源码标签、设备和 Trace 为准，不把旧案例视为已在新版本复现。实际抓取与分析从 Android 12 起讨论，这不是 Perfetto 的最低支持版本。
个人对 Perfetto 的使用也没有很深入，有些高阶功能目前还只是浅尝辄止。可以通过重写 Perfetto 系列来进行这部分内容的强化
Perfetto 是个很强大的工具，他的背后是整个 Android + Linux 系统，所以在写这个系列的时候，应该是以他背后的这个 Android + Linux 为主，而不是仅仅局限于 Perfetto 这个工具。工具只是我们观测 Android + Linux 的方式，理解整个 Android 系统运行的规律，思考其运行的原理，通过工具挖掘问题，通过问题思考本质，这才是对开发者来说有意义的
很多 Android 系统运行相关的内容，Perfetto 的官方文档还是没有讲，这部分我这边可以作为补足；另外官方文档是英文版本的，中文博客可以补充这方面。
Perfetto 可以拿到 Google Dev Fest 上作为演讲内容～。

Perfetto

性能分析为什么需要全局视角

在介绍 Perfetto 之前，我们需要先明确，为什么性能分析需要 Systrace 和 Perfetto 这样的工具：以 Android 系统为例，影响性能的因素非常多，既有 App 自身质量，也有系统模块、Linux、硬件、厂商策略、系统负载、低内存、发热、Android 版本差异和用户使用习惯等因素。这些问题通常不是只分析某一个 App 或某一个模块就能定位清楚的，我们需要一个全局视角，从更高的维度来看 Android 系统的运行情况。

Perfetto 可以把多个数据源放到同一条时间轴上，帮助我们观察这些环节：

Input 事件是怎么流转的
你正在使用的 App 的每一帧是怎么从 App 产生到上屏的
CPU 的实时频率、负载、摆核、唤醒等
系统中的各个 App 是怎么运行的
….

App 开发者和 Android 系统开发者可以在重要逻辑处加 Trace 点。但“全局视角”不等于自动记录所有细节：需要设备提供相应数据源，并在 TraceConfig 中启用，权限和缓冲区丢失也会影响结果。普通调度事件可以说明线程何时在某个 CPU 上运行，未必记录调度器选择该 CPU 的完整原因。没有看到事件，不能直接认定它没有发生。

同样为了说明性能优化的复杂性，可以看看《性能之巅》这本书中对于性能的描述，具体来说就是方法论，非常贴合本文的主题，也强烈推荐各位搞性能优化的同学，把这本书作为手头常读的方法论书籍：系统性能工程是一个充满挑战的领域，具体原因有很多，其中包括以下事实，系统性能是主观的、复杂的，而且常常是多问题并存的

性能是主观的

软件故障排查常常可以围绕较明确的正确性条件展开：行为是否符合预期、故障能否复现。但 bug 不一定伴随错误日志，也不一定能从一条错误信息中看出原因。
与此不同，性能常常是主观性的。开始着手性能问题的时候，对问题是否存在的判断都有可能是模糊的，在问题被修复的时候也同样，被一个用户认为是”不好”的性能，另一个用户可能认为是”好”的

系统是复杂的

除了主观性之外，性能工程作为一门充满了挑战的学科，除了因为系统的复杂性，还因为对于性能，我们常常缺少一个明确的分析起点。有时我们只是从猜测开始，比如，责怪网络，而性能分析必须对这是不是一个正确的方向做出判断
性能问题可能出在子系统之间复杂的互联上，即便这些子系统隔离时表现得都很好。也可能由于连锁故障（cascading failure）出现性能问题，这指的是一个出现故障的组件会导致其他组件产生性能问题。要理解这些产生的问题，你必须理清组件之间的关系，还要了解它们是怎样协作的
瓶颈往往是复杂的，还会以意想不到的方式互相联系。修复了一个问题可能只是把瓶颈推向了系统里的其他地方，导致系统的整体性能并没有得到期望的提升。
除了系统的复杂性之外，生产环境负载的复杂特性也可能会导致性能问题。在实验室环境很难重现这类情况，或者只能间歇式地重现
解决复杂的性能问题常常需要全局性的方法。整个系统——包括自身内部和外部的交互——都可能需要被调查研究。这项工作要求有非常广泛的技能，一般不太可能集中在一人身上，这促使性能工程成为一门多变的并且充满智力挑战的工作

可能有多个问题并存

找到一个性能问题点往往并不是问题本身，在复杂的软件中通常会有多个问题
性能分析的又一个难点：真正的任务不是寻找问题，而是辨别问题或者说是辨别哪些问题是最重要的
要做到这一点，性能分析必须量化（quantify）问题的重要程度。某些性能问题可能并不适用于你的工作负载或者只在非常小的程度上适用。理想情况下，你不仅要量化问题，还要估计每个问题修复后能带来的增速。当管理层审查工程或运维资源的开销缘由时，这类信息尤其有用。
有一个指标非常适合用来量化性能，那就是延时（latency）

Perfetto 介绍

Perfetto 是一套开源的性能采集和分析工具，包含系统与应用数据采集、Trace Processor 和 Web UI。它可以把调度事件、应用埋点及其他已启用的数据源放在一起分析，也支持通过 SQL 查询 Trace。内存分析要区分 heapprofd 分配采样（Android 10+）与 ART 堆对象引用图（Android 11+）：前者关注分配及调用栈，后者关注对象保留关系，不包含对象内容或分配调用栈。量产 user 系统上的 heapprofd 还要求目标应用允许 debuggable 或 profileable，普通系统 Trace 不会自动包含这些数据。

Perfetto 的采集、分析和可视化可以分别使用；跨平台支持也应按组件判断，不能把 Android/Linux 系统数据源理解为在所有平台都可用。开发动态可以查官方仓库与版本记录。Android 官方推荐 Perfetto，但这不等于旧 Trace 的每项显示行为都与 Systrace 完全一致。

如果你已经习惯使用 Systrace，可以把旧文件放进 Perfetto UI；官方支持导入 Systrace HTML 内嵌的 ftrace/ATrace 数据，但不保证复刻旧查看器的全部界面和分析结果。旧截图中的 Legacy UI 入口属于当时的功能，不应依赖当前界面始终提供一键回退。

下图是 Perfetto 的架构图，可以看到 Perfetto 包含了三大块：

Record traces ：即数据抓取模块，可以看到抓取的内容和来源非常丰富，Java、 Native 、Linux 都有涉及到，相比 Systrace 要丰富很多。
Analyze traces ：主要是 trace 分析模块，包括 Trace 解析、SQL 查询、Metrics 分析等，这部分有专门的命令行工具提供，方便大家直接调用或者在工具链里面去调用。
Visualize Traces：Trace 的呈现、抓取等

这几个模块在后续的系列文章中都会详细介绍

Perfetto 的核心优势和功能亮点

结合日常使用和官方文档，Perfetto 的主要能力可以分为下面几类。

支持长时间数据抓取：通过后台服务采集，使用 Protobuf 记录。长时间抓取仍要配置缓冲区、写盘周期和文件大小；环形缓冲区会覆盖旧事件，不能把“进程一直运行”理解为“完整保存了全部历史”。见配置说明与数据丢失排查。
多种数据来源：Linux ftrace 是系统追踪的数据源之一，ATrace、SDK Track Event、内存分析等各有配置和支持范围，整个 Perfetto 并不只建立在 ftrace 上。
采集与触发：可以通过网页、命令行和 Android 开发者选项发起采集。Trigger 是控制已配置会话开始、停止或保存的机制，需要配套的触发配置，不是独立的数据源。
数据分析与可视化：
- Trace Processor解析数据后提供 SQL 表和视图，无需先转成 SQLite 文件。原始 Protobuf Trace 本身不是 SQLite 数据库。
- Python API可以把查询结果转为 pandas DataFrame；结果仍受采集完整性与查询口径约束。
- 浏览器的内存有限，多 GB Trace 不保证能直接加载；可使用本地原生 Trace Processor 配合 Web UI，仍需足够的主机内存。
- 支持固定轨道、查看 Binder flow、调度唤醒关系和关键路径，但这些分析都需要对应事件。线程被谁唤醒与设备从休眠被何物唤醒，也不是同一个问题。
- 函数调用栈需要对应的采样或分析数据及符号信息；普通嵌套 Trace slice 不等于完整调用栈。堆分配调用栈与 ART 对象引用图也应分别解读。
版本持续演进：UI、Trace Processor、SDK 和设备端采集组件可能不是同一版本。复用 SQL 或报告时，记录工具版本、系统版本与 TraceConfig，避免把升级导致的差异当作性能变化。

这里专门提一下 SQL。Trace Processor 在解析 Trace 后提供表和视图，便于重复分析。下面保留早期查询截图，展示按耗时、进程和调度状态筛选的思路（图来自内核工匠）。

旧查询的边界：图中的 OPF: 是特定 Trace 的命名，不是通用系统事件。锁竞争查询按名称中解析出的值和时间嵌套计数，不能据此直接认定同一对象的竞争线程数。复用时应按当前 schema 核对字段（例如 slice.id），排除未闭合的负 dur，并检查调度数据是否完整；未知的 Running 时间不能填成 0。

官方文档也提供 SQL 和结果示例，下面是早期 FrameTimeline 查询的截图。

有了 SQL，老板再问优化前后的数据，就可以用同一套查询分别跑两份 Trace，再把结果转成图表。这样准备报告方便多了。报告仍需交代设备、场景、样本数、时间窗口和数据完整性，不能只凭一份 Trace 就写出稳定的提升比例。

相比 Systrace 没那么好用的地方

Vsync-App 没那么直观

按本文 2024 年截图，Vsync-App 在 Perfetto 中没有 Systrace 那种贯穿视图的竖线，习惯旧界面的读者可能需要适应：

Perfetto 中，你可以把 Vsync-App Pin 到最上面来看 Vsync 信息

Systrace 中，Vsync 以竖线的方式贯穿整个 Trace，很容易辨别：

Vsync-App 可以作为节奏参考，但仅凭它无法判断是哪一帧、哪个进程导致卡顿。FrameTimeline 另外提供了帧级证据。Android 12+ 且采集了 FrameTimeline 数据时，可以比较 Expected Timeline 与 Actual Timeline，见官方说明。

Expected Timeline：切片是分配给应用这一帧的渲染时间预算，起点是 Choreographer 回调原定应运行的时刻，不是实际开始执行的时刻。
Actual Timeline：从 Choreographer#doFrame 或 AChoreographer_vsyncCallback 实际开始，到 GPU 完成与帧提交 SurfaceFlinger 两个时刻中的较晚者。它是包含等待和 GPU 工作的时间区间，不等于 CPU 运行时长，也不是应用这帧最终上屏的完整耗时。

比较两条轨道可以找到需要继续分析的帧，再查看 Jank Type、Present Type 与 Prediction Type。旧图中红色表示卡顿归因到该进程，黄色表示应用帧受 SurfaceFlinger 卡顿影响，浅绿色提示高延迟；不要只统计红色。蓝色是丢帧，旧图只写了 SurfaceFlinger 的情况，应用侧还可能是 UI 状态没及时交给 RenderThread。判定还要结合预测有效性及对应 Surface，详见第 7 篇。

下图说明 Actual Timeline 为什么会同时受 GPU 完成和提交时刻影响；它不是把 CPU 时间与 GPU 时间相加。

SurfaceFlinger 也有这两条轨道，但对应合成和显示阶段，不能把它们的持续时间当作应用主线程的耗时。

折叠功能比较烂，比较废屏幕

以下保留我在 2024 年旧版 UI 上的体验：普通宽屏里 Pin 几个关键线程后，下方空间就很小；碰到嵌套 slice 很深的轨道更是顶级折磨，当时我觉得折叠操作不如 Systrace 顺手。这里的嵌套 slice 也不等于函数采样调用栈。

解决办法：

少 Pin 几个关键线程（那还有啥乐趣）
把显示器竖起来（宽度就打折了）

最终我们找到了完美的方案：换成 LG 那个魔方屏幕，16:18 ，看 Perfetto 简直是绝配（办公室已经被我安利有三台了）

28MQ780

不差钱：LG 28MQ780 - 3599
平替：联合创新 28C1Q - 2999

版本更新：官方 CHANGELOG记录 v48.0（2024-10-11）引入支持嵌套轨道与多个工作区的 API，v49.0（2025-01-06）加入工作区切换和移动轨道菜单。可以只把当前分析所需的轨道放入工作区，减少固定轨道占用。上面的显示器体验和价格是 2024 年记录，不代表当前售价或购买建议。