Perfetto系统追踪分析：10秒录一段，定位一次卡顿-平芜编程栈

Perfetto系统追踪分析：10秒录一段，定位一次卡顿

【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto

Perfetto 是 Android 与 Chrome 默认的系统级追踪工具。这篇讲一条完整的追踪分析链路：设备端录 10 秒、时间线上找到卡顿区间、用 SQL 验证 CPU 归属，以及新手最容易卡住的坑。适合动手排过性能问题、但一直卡在"拿不到数据"这一步的 Android 工程师。

📍 logcat 答不上来"为什么卡"的时候

logcat 答不上来的，才是你真正需要追踪的。下面三种情形你可能都遇到过：

用户反馈滚动卡顿，你本机抓 logcat 一切正常、也复现不出来——卡顿只持续几十毫秒，文字日志里根本看不见。
应用被系统 LMK 杀掉，只能看到 kill 事件，不知道之前的内存去哪了。
启动慢，分不清时间花在自己的代码、某个系统服务，还是等内核资源上。

共同点：这三个问题靠单看某条日志都答不上来。你需要的是内核、CPU、各进程排在同一把时间尺上的时间线——这正是 Perfetto 的核心能力，上面三个问题都从同一张图开始排查。

⏱ 设备端录 10 秒：三步跑通

第一次录制的目标不是"录全"，是把出问题的时间段录进去。

先把卡顿本身录下来

在开启 USB 调试的 Android R+ 设备上，用 UI 的录制页选择 ADB+WebSocket 连上设备，成功状态长这样：

命令行更省事，直接用仓库自带的辅助脚本 tools/record_android_trace，一条命令完成连接、录制并自动打开 UI：

python3 record_android_trace -o trace.perfetto-trace \ -t 10s -b 32mb -a '*' sched freq view ss input

录制的 10 秒里，在手机上真实做一遍出问题的操作。省掉这步，trace 只是一堆背景噪声。

别急着开全部数据源

第一次只开 sched、freq、atrace 注解，缓冲区 32MB 够用。
logcat、内存计数器后面按需再加；全开容易让缓冲区很快写满，时间线也一片混乱。
录制模式选"满则停"，不丢数据，比环形缓冲好理解。

🔎 时间线阅读顺序：先找卡顿区间，再往外扩

时间线怎么读，决定你多久能定位到根因。UI 里线程、CPU、系统事件各占一轨，对齐在同一时间轴上：

从卡顿区间出发，而不是从某个线程出发：先把用户感知到卡的那段放大，再向外扩。
确认线程状态再下结论：目标线程 Runnable 却没跑在任何 CPU 上，是调度问题；Sleeping，说明在等锁、binder 或 I/O。
对照 CPU 轨道：卡顿区间内 CPU 空闲，瓶颈在用户态而不是内核。

用 SQL 验证"谁在吃 CPU"

肉眼看之后，用数字复核。trace 可以当数据库查：

include perfetto module linux.cpu.utilization.process; SELECT name AS process_name, sum(megacycles) FROM cpu_cycles_per_process GROUP BY 1 ORDER BY 2 DESC;

先确认卡顿进程是否真在消耗 CPU 周期。不是的话，方向是"等"而不是"算"，别急着翻调用栈。
查询结果与时间线互相对照：cycles 最高的进程如果不是卡顿线程，回到时间线重看线程状态。

⚠ 三个新手常踩的坑

这三个坑踩中一个，前面的录制就白做了。

把"应用慢"当成"应用算得慢"。Android 卡顿多数不是计算瓶颈，而是线程在等待，先查时间线排除等待再谈优化。
录 10 分钟全量数据源不等于更可靠。文件 30 秒打不开就等于不可分析，首次 10 秒、32MB、三类数据源足够。
用 cat 拼两个 trace 文件当"合并"。跨设备对齐要用trace_processor util merge，否则时间轴会错位。

边界也要清楚：Perfetto 是"录短窗口、回 PC 深挖"的工具，不是常驻监控服务。线上长期指标与告警要靠其他手段，它负责深挖这一段。

✅ 今天就能做的三件事

以下三件事，每件一小时内都能做完：

在自己设备上用上面的命令录一段 10 秒的"打开应用"trace，在 UI 里找到一个能说清"这段时间发生了什么"的区间。
跑一次那条 SQL，核对 CPU 占用最高的进程是否符合直觉；不符合，就是你的第一个真实发现。
下次排查问题前，先写一句话："我要搞清楚哪个区间发生了什么"——录那个区间，而不是录"全部"。

当"先录再判断"成为习惯，性能排查就完成了一半。剩下的一半是多读几类 trace，仓库 docs/ 里按场景组织的教程可以直接当长期参照。

【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考