Perfetto SQL分析实战：用数据查询取代肉眼滑图，提升性能优化效率

一直在用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、graphicsHWC 合成相关以及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”的显著标志是写 SQLPerfetto 的 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 录制精确配置到对应的场景上从源头提升分析质量。