一直在用systrace的老伙计可以醒醒了，Perfetto才不只是个新版抓取工具那么简单。它把 trace 分析从“肉眼看曲线”直接拉进了“数据查询”时代，这才是“提效”两个字真正的分量。这篇文章不聊虚的，从录制姿势到 SQL 分析，再到团队怎么把分析能力沉淀成一套可复用的“HQ 工作流”，全部基于真实项目踩坑经验，希望对正在性能优化的朋友有点帮助。
1. 先说清楚：Perfetto 解决的是“看得懂”而不是“抓得到”
1.1 传统 Trace 分析的最大痛点
早些年用 systrace 分析卡顿和启动问题时，最痛苦的事情不是你抓不到数据，而是抓到了之后不知道怎么高效地看。一条动辄几十 MB 的 trace 文件，打开之后满屏的五颜六色，时间轴缩放到刚好能看清的程度，一帧的数据就横跨了好几个屏幕。遇到主线程被阻塞的问题，你得肉眼去滑、去对比、去猜测，这种效率其实非常低。
到了 Perfetto 这里，问题被拆成了两层：第一层是数据采集层，它做得更精细、分类更丰富；第二层是数据分析层，它引入了一个关键的概念——Trace Processor。什么意思呢？就是整个 trace 文件可以被加载进一个关系型数据库引擎里，然后你用 SQL 去查询任何一段 CPU 区间、任何一条 binder 事务、任何一次调度延迟。分析不再依赖肉眼，而是依赖逻辑。
1.2 提效 HQ 到底指什么
所谓“HQ”，我一开始也以为是个新工具或新框架的名字，后来在团队里反复讨论才发现，它更像是一套标准化的分析预期——High Quality。不是把 trace 打开截图完事，而是能够快速定位根因、量化影响范围、形成可复用的分析结论。
举个真实案例：某次线上反馈某页面滑动掉帧，光看 Perfetto 主线程状态，会看到一大片Running被拆得四分五裂、中间穿插着Sleeping。你如果只截个图发给开发，他大概率会反问“这能说明什么问题”。但如果把这段区间拉进 SQL 查询，分析出每个Sleeping之前的 wakeup 来源，直接指出“是被某个异步任务抢占，导致主线程拿不到 CPU”，结论一下变得可以执行。这就是提效 HQ：从“看到现象”进化到“看懂原因”。
1.3 哪些人适合看这篇文章
如果你已经开始用 Perfetto 做常规的启动优化或帧率分析，但总觉得每个 trace 看得很慢；或者你想在团队内统一一套分析流程，让经验不集中在几个人身上。这篇文章比较适合你。文章会涉及一些 SQL 示例，但都不复杂，按着抄就能用。
2. 录制 Trace：抓取阶段决定了分析的上限
2.1 别一上来就全选所有数据源
这是很多刚接触 Perfetto 的人最容易踩的坑。Perfetto 支持的数据源非常多：CPU 调度、频率变化、内存、GPU、电源、网络，甚至文件系统。你在 Android Studio 的 Profiler 里或者使用record_android_trace脚本时，常常会为了“省事”直接全选。
但录制时全选的结果往往是：冗长的 trace 文件、惊人的文件体积，以及打开时极长的加载时间。更麻烦的是数据量过大会导致周围关联信息被 buffer 覆盖掉，等你想看某个关键时刻的调度信息，结果数据已经被冲刷没了。
建议的做法是按需录制：
- 分析启动速度：选
sched、binder、cpu、freq，再加atrace自定义事件。 - 分析卡顿掉帧：选
sched、gpu、graphics（HWC 合成相关）以及input。 - 分析内存或 GC 问题：选
heap或dmabuf相关数据源。
这样录制出来的文件更小，加载更快，对应问题域的信息也更完整。
2.2 录制模式选择：命令行与端上录制
命令行录制是后端开发和性能优化同学最常用的方式。下面这段命令我基本会背下来了：
# 设置需要采集的类别，这里以调度和binder为例 adb shell "echo 'sched freq idle binder atrace' > /sys/kernel/trace/tracefs/trace_options" # 启动采集，使用特定的tag方便后续过滤 adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto-trace -c /data/local/tmp/trace_config.pb当然，这个命令需要配合一个 protobuf 格式的配置文件，用来声明缓存大小、持续时间和数据源。如果不想手写 pb 文件，直接用record_android_trace脚本可以省很多事情：
python record_android_trace -c sched,freq,binder -d 10 -o /tmp/startup_trace.perfetto-trace这条命令的含义是：抓取 10 秒的调度、频率和 binder 数据，输出到本地。我非常推荐在调试启动问题时用这种方式，因为命令行开启的录制可以精确地碰上一个冷启动过程：先输入命令，再开始录，然后点击桌面图标启动应用，整个过程完整且可控。
2.3 录制时长和 Buffer 的动态取舍
Buffer 大小决定的是“能记录多久之前的信息”。如果只在本地调试且问题稳定复现，1GB 的 buffer 通常足够；但如果是线上用户机型，可用的 buffer 受限于系统内存，往往只能配置 32MB 到 64MB。
这里分享一个计算技巧：假设你只需要分析 10 秒内的调度行为，估算一下每秒事件的规模。普通十几屏的几机调度事件，10 秒大约 50MB 左右。Buffer 建议设置为预估量的两倍以上，防止某一阵高频事件（比如大量 binder 调用）把 Buffer 冲爆，导致关键区间丢失。
录制过程中遇到的最大问题往往是TRACE_BUFFER_OVERFLOW，边缘时刻的数据不全。与其反复调大 Buffer，不如缩短录制时间。抓住问题主过程 10 秒就够了，不要贪多。
3. 打开 Trace 之后：从时间轴到结论的快速路径
3.1 熟悉 Perfetto UI 的核心操作逻辑
Perfetto UI 打开后，常见操作是按下W和S键放大缩小时间轴，按住鼠标拖动，用Shift + 鼠标滚轮横向滚动。很多人以为这是基本功没什么好说的，但真正高效的人会把标记工作做得非常到位。我建议从打开 trace 的第一秒就用M键标记关键时间点：进程启动起点、首帧时间、掉帧区间起点终点。
标记的最大好处是后续的 SQL 查询可以精确圈定窗口，不需要反复用视觉判断边界。例如，我想查某个区间内主线程的占用情况：
SELECT avg(utid != 0) AS main_thread_ratio, count(*) AS total_slices FROM sched_slice WHERE ts BETWEEN 150000000 AND 155000000 AND utid = (SELECT utid FROM thread WHERE tid = 12345)这种查询能直接量化主线程在窗口内的运行占比，比肉眼观察靠谱得多。
3.2 从 Track 到 Slice 到代码位置的定位链条
标准的问题定位路径是：
- 首先在 Perfetto UI 的顶栏搜索框输入进程名，找到目标进程。
- 找到主线程的
ThreadState和Slices层。 - 在疑似卡顿区间内，观察主线程的状态。
主线程的状态可以用不同的颜色区分：绿色 Runnable、蓝色 Sleeping、紫色 Uninterruptible。一旦发现有较长段的 Sleeping 夹在中间，就得双击这个区间，查看 Sleeping 前后的 wakeup 来源。Perfetto 会展示一个wakeup箭头，指向唤醒它的线程或者中断。这个信息直接决定了你要不要从某个异步任务入手排查。
如果问题区间在Binder调用上，还可以顺着 binder driver 的 slice 找到 Client/Server 进程的对应调用，分析 Binder 响应慢是对方进程主线程卡住，还是当前线程持有的锁冲突。
3.3 高效的 Filter 和 Focus 技巧
分享一个非常实用的技巧：当你在追踪一条跨进程链路时，用F键 Focus 某个切片，可以把这个切片所在的线程上下文提到最前，然后以它为中心查看前后事件。
另外，由于一个 trace 里可能包含几十上百个线程，把 UID、TID 不重要的线程全部关掉，能显著提升界面渲染流畅度。边拖动时间轴边对比的状态下，界面的卡顿会直接影响分析耐心。把无关键程隐藏之后，Perfetto 的 zoom 响应会快得多。
4. 提效的灵魂：SQL 驱动的 Trace 量化分析
4.1 为什么算“会用 Perfetto”的显著标志是写 SQL
Perfetto 的 web trace viewer 只是一个展示前端，它背后是 Trace Processor。用固定的 SQL 查询去批量分析 trace，得到的是精确的数字，而不是“好像这里比较堵”的模糊印象。
这里举几个具体场景：
- 场景一：验证某次启动优化是否有效，需要在多次 trace 中对比
startup的总时长。用 SQL 老阵地去查关键的stats表，直接得到均值、中位数、P95。 - 场景二：判断某个自定义埋点（
atrace里的slice）是否反复异常长，超过 50ms 的调用有哪些。 - 场景三：寻找 CPU 频率不足的时段，关联对应进程的
sched_slice。
4.2 我常用的几个 SQL 查法
Trace Processor 的表结构很多，但常用的其实集中在这么几张：
process与threadsched_sliceslicecountercpu_frequency
第一个实用查询：找到指定线程在某个时间窗口内的调度占比。
SELECT SUM(dur) / 1000000.0 AS running_ms -- 转为毫秒 FROM sched_slice WHERE utid = (SELECT utid FROM thread WHERE tid = 12345) AND ts BETWEEN 150000000 AND 155000000第二个查询：查看某进程主线程在窗口内被调度出 CPU 的频次，并统计每个唤醒源。
SELECT t.tid AS from_tid, p.name AS from_process, count(*) AS wakeups FROM sched_wakeup w JOIN thread t ON w.utid = t.utid JOIN process p ON t.upid = p.upid WHERE w.waker_utid = (SELECT utid FROM thread WHERE tid = 12345) GROUP BY 1, 2 ORDER BY 3 DESC这个查询的实战意义很大。它能找出到底是谁频繁把主线程唤醒，导致主线程在“非必要”地反复切换上下文。往往这里能直接定位到某个反复打点的日志模块或者后台同步任务。
第三个最适合做报告：输出主线程因为等待某个锁而阻塞的时间占比。
SELECT track.name, sum(slice.dur)/1000000.0 AS blocking_ms, count(*) AS cnt FROM slice WHERE slice.track_id IN ( SELECT id FROM track WHERE name = 'monitor contention' ) AND ts BETWEEN 150000000 AND 155000000 GROUP BY 1 ORDER BY 2 DESC将这些查询的结果放在一起，就形成了一张有说服力的性能分析报告，而不是一张时间轴的截图。
4.3 把 SQL 脚本沉淀成团队模板
提效最直接的方式是把常用查询写进团队内共享的*.sql文档。Perfetto UI 支持直接在左下角启用 SQL 脚本输入面板，粘贴进去就能执行。整套流程完全可以标准化：
- 新人拿到 trace，先跑一遍“启动时长统计”脚本。
- 再跑一遍“主线程唤醒源统计”脚本。
- 然后跑一遍“Binder 慢调用统计”脚本。
半个小时内就能得到一份基础结论，而不是花一下午在时间轴上滑动。
5. 常见排查坑位与避坑手册
5.1 Trace 加载慢、只显示进程名不显示应用名
遇到这些问题不要慌。加载慢往往是因为 trace 里的android_log数据量过大，或者没有关闭heapprofd的连续数据流。建议排查时排除掉不必要的日志类别。
只显示进程名不显示应用名的原因通常是缺少ps_with_threads快照。在采集配置文件里加上linux.ps数据源即可。
5.2 时间不同步：Perfetto 和 logcat 时间对应不上
同一个设备上抓到的 trace 内的计时是基于系统时钟的，而 logcat 默认输出boottime或者 Unix 时间，两者基准不同，容易对不上。建议采集时让 logcat 也使用clock.realtime或与 perfetto 对齐的时间源。在实践中，我通常先打印一行带时间戳的日志，然后通过SQL查询同一个 slice 的自定义日志事件，校准两者偏移量。
5.3 掉帧问题定位到 SurfaceFlinger 的坑
比较常见的误判是把掉帧完全归结到应用主线程慢，而忽略合成阶段的问题。Perfetto 能看到 SurfaceFlinger 的 release fence 时间戳和 GPU completion，如果应用每帧的提交还算平滑，但在sf进程的合成阶段耗时特别长，问题很可能出在图形内存分配或 HWC 硬件叠加层上。这一类问题单独靠看主线程是不行的。
5.4 不要忽视 Uninterruptible 状态
很多休眠状态是可以通过 trace 识别为主动Sleeping的，但 Uninterruptible（不可中断）状态往往意味着内核层面的磁盘 IO 或低内存处理。如果你在 trace 里看到主线程出现长段紫色块，且唤醒源指向 kswapd 或某个 block device，那大概率是内存紧张或者存储设备读写抖动，应用代码优化解决不了根因。
6. 从个人技巧到团队 HQ：建立可持续的 Trace 分析文化
6.1 制作基于 Perfetto 的报告模板
先定义清楚“一份合格的 trace 分析报告”应该包含哪些内容，全组保持一致。建议至少包含以下模块：
- 基本信息：机型、系统版本、问题版本号、现象描述。
- 采集方法：录制时长、buffer、启用数据源。
- 基线指标：启动时间、掉帧率、主线程阻塞占比。
- 关键事件时间轴：用 mark 写上关键信息，截图。
- 根因假设与证据：至少两条以上证据支撑某个结论。
- 建议优化方案。
有了固定结构，大家交流效率会高很多。不用每个人从头描述一遍背景。
6.2 建立可复用的 Perfetto 模板库
除了 SQL 脚本，配置文件也是可以复用的。比如启动分析配置、卡顿分析配置、内存分析配置，分别用一个.pb文本保存。用命令行采集时，直接指向对应配置文件，避免每次手调参数。
我自己在项目里维护了一个perfetto_configs/目录：
perfetto_configs/ startup_full.pb jank_simple.pb memory_leak.pb battery_usage.pb每个文件都有明确的注释去说明使用场景和注意事项。这里想特别强调一点：配置文件里面打开long_script这个选项，可以支持比较复杂的 trace 处理逻辑，但会增大 CPU 开销，一般本地调试才打开，线上采集保持关闭。
6.3 新人上手路径设置
最后聊聊团队引入 Perfetto 时，新人怎么少走弯路。直接扔文档链接的体验很差，建议先让他做三次实战任务：
第一次任务：给一个预先录好的卡顿 trace，要求找出主线程最耗时的三个 slice，并截图。
第二次任务：自己录制一个冷启动 trace，用标准 SQL 脚本计算出启动关键阶段耗时，并和同一版本优化后的 trace 做对比。
第三次任务：模拟真实项目问题，给定一次线上反馈，让他独立录制、分析、报告，至少定位到一个可执行的根因。
这样带下来的新人，基本在一周内就能具备独立排查中级问题的能力，团队整体分析能力也会明显提升一个台阶。
6.4 持续更新的“常见问题速查表”
把工作中遇到的各种问题整理成速查表，能让团队成员少踩重复的坑。下面是我目前整理的一部分：
| 现象 | 可能原因 | 快速排查方法 |
|---|---|---|
| 主线程大面积 Sleeping | 等待锁、等待 IO、被调度延迟 | 查看 wakeup 源和锁等待 slice |
| 无故的唤醒大量发生 | 定时器、Handler 消息、网络轮询 | 查询 sched_wakeup 的 waker 来源 |
| Binder 调用慢 | 对端进程主线程繁忙 | 跟踪 Binder 事务，定位对端卡点 |
| 合成掉帧 | SurfaceFlinger 拥堵或 GPU 处理延迟 | 观察 sf 进程 slice 和 GPU 频率 |
| 启动时出现长磁盘 IO | 冷启动加载大文件、数据库查询 | 用 kernel 内部 IO 相关的 slice 查看块设备耗时 |
| 低频 CPU 导致任务耗时增加 | 温控降频或者策略限制 | 关联 cpu_frequency 表和对应进程 slice |
这张表一直在持续更新，遇到新问题就往里加。
7. 最后的实践心得：把分析做成一个解题系统
我不太建议大家把 Perfetto 当作“抓一次 trace 然后分析一次”的孤立工具，而是把它当成一串连续的工作流来经营。关键环节就是三个闭环：录制前明确问题假设，录制中精准采集数据，分析后量化验证假设。
从实际使用体会来说，一旦你用 SQL 替代视觉滑屏，分析的深度会明显提升。以前可能需要加班两小时才能定位到某一次跨进程唤醒导致的掉帧，现在用脚本十分钟内就能圈定怀疑范围，剩下的时间可以用来验证解决方案。团队推行这套 HQ 流程之后，最难解决的问题反而不在工具本身，而在于“问题定义”。如果线上反馈只是“有点卡”，说明目标不够清晰，我们要先用多帧 profile 确立具体帧号、具体时间点、具体堆栈，这样才能把 trace 录制精确配置到对应的场景上，从源头提升分析质量。
