27、线下工具链:Systrace深度分析、Perfetto自定义Track、GPU Inspector使用

做音视频性能优化,说白了就是跟各种卡顿、掉帧、延迟作斗争。我干了这么多年,最深的体会是——没有好工具,优化就是瞎猜

今天聊的三个工具,是我线下排查问题的"三驾马车"。Systrace看全局,Perfetto挖细节,GPU Inspector查渲染。配合起来用,大部分性能问题都能揪出来。

Systrace深度分析:别只看FPS

很多人用Systrace,就盯着FPS曲线看。其实这远远不够。我见过一个项目,FPS显示60帧稳稳的,但用户就是觉得卡。为什么?因为帧率平滑度比平均值更重要

核心思路: Systrace的核心价值在于"时间线对齐"。把CPU、GPU、线程、系统服务的时间线叠在一起看,才能找到真正的瓶颈。

我常用的几个分析技巧

  • 看SurfaceFlinger的vsync信号:如果vsync间隔不均匀,说明系统负载有问题。我曾经遇到一个案子,就是第三方推送服务频繁唤醒CPU,导致vsync抖动。
  • 关注BufferQueue的dequeueBuffer耗时:这个时间如果超过2ms,说明GPU在排队。这时候别急着优化CPU,先看看渲染管线是不是堵了。
  • 检查主线程的Choreographer.doFrame:这里能看到每一帧的输入、动画、布局、绘制四个阶段。哪个阶段超了,问题就在哪。
小技巧: 在Systrace里按"W"键可以放大时间轴,按"Q"缩小。我习惯先看整体轮廓,再放大到有问题的区域。别一上来就钻细节。

一个真实案例

去年优化一个视频播放器,播放4K视频时偶尔掉帧。Systrace一看,发现MediaCodec的dequeueOutputBuffer耗时忽高忽低。再往下追,原来是解码器在等待I帧时,CPU被其他线程抢占了。解决方案很简单——给解码线程提优先级。就这一行代码,掉帧率从5%降到了0.3%。

Perfetto自定义Track:打造你的专属监控

Perfetto是Systrace的升级版,功能更强。但很多人不知道,它支持自定义Track。这意味着你可以把业务逻辑的关键节点也画到时间线上。

举个例子。你在做视频渲染,想知道"从网络收到数据包"到"画面显示"到底花了多久。系统工具只能看到系统调用,看不到你的业务逻辑。这时候自定义Track就派上用场了。

怎么加自定义Track?

其实很简单,Perfetto提供了C++和Java的API。Android上推荐用Trace.beginSection()Trace.endSection(),但Perfetto还支持更细粒度的TRACE_EVENT宏。

// 在关键业务节点加标记
Trace.beginSection("VideoPipeline:NetworkReceive");
// ... 网络接收逻辑 ...
Trace.endSection();

Trace.beginSection("VideoPipeline:DecodeFrame");
// ... 解码逻辑 ...
Trace.endSection();

Trace.beginSection("VideoPipeline:RenderFrame");
// ... 渲染逻辑 ...
Trace.endSection();

跑完trace后,在Perfetto UI里就能看到自定义的"VideoPipeline" Track。每个阶段的耗时一目了然。

注意: 自定义Track不要加太多,否则trace文件会变得巨大。我一般只标记关键路径上的5-8个节点。加多了反而干扰分析。

我踩过的坑

曾经有一次,我在一个循环里加了Trace.beginSection,结果trace文件暴涨到几百MB。分析时Perfetto直接卡死。后来改成只在关键帧上加标记,问题解决。嗯,这里要注意——不要在频繁调用的地方加trace

GPU Inspector:查渲染问题的利器

GPU Inspector是Android 12引入的工具,专门用来分析GPU渲染。以前查渲染问题,只能靠猜。现在有了它,每个Draw Call的耗时、Shader的执行情况、纹理的带宽占用,全都看得清清楚楚。

我个人习惯,在遇到以下情况时必开GPU Inspector:

  • 画面掉帧,但CPU负载不高
  • GPU温度异常升高
  • 渲染复杂场景时卡顿

怎么看GPU Inspector的数据?

打开GPU Inspector后,主要关注三个面板:

面板 看什么 常见问题
Frame Timeline 每帧的GPU耗时 某帧耗时突增,说明有重绘或复杂Shader
Shader Stats Shader编译次数、执行时间 Shader频繁编译,说明缓存没命中
Memory Bandwidth 纹理读写带宽 带宽打满,说明纹理太大或格式不对
一个经验: 如果Memory Bandwidth接近上限,先检查纹理格式。很多团队习惯用ARGB_8888,其实对于不透明的纹理,用RGB_565能省一半带宽。我优化过一个AR应用,就靠改纹理格式,帧率从30提到了55。

三个工具怎么配合?

光会用单个工具不够,关键是怎么组合。我一般按这个流程来:

  1. 先用Systrace扫全局:看有没有明显的掉帧、线程阻塞、vsync抖动。这一步能定位到大概方向。
  2. 再用Perfetto挖细节:在Systrace发现的问题区域,用Perfetto的自定义Track把业务逻辑的时间线画出来。看看是哪个环节耗时最多。
  3. 最后用GPU Inspector查渲染:如果问题出在渲染阶段,就用GPU Inspector看Draw Call、Shader、纹理。找到具体的性能瓶颈。

你想想看,这三个工具就像医生的"望闻问切"。Systrace是"望",看整体气色;Perfetto是"问",问具体症状;GPU Inspector是"切",直接查病灶。缺一个都不完整。

避坑指南: 我曾经在Perfetto里花了两小时分析一个卡顿问题,最后发现是GPU Inspector里显示的一个纹理格式不兼容导致的。所以我的建议是——别在单个工具上死磕。如果某个工具查了半天没结果,换个工具试试,往往有意外发现。

知识体系总览

下面这张图,是我自己总结的线下工具链使用逻辑。你可以把它当成一个检查清单:

线下工具链使用逻辑 发现卡顿/掉帧 Systrace:全局扫描,定位问题区域 CPU/线程问题 业务逻辑问题 渲染/GPU问题 Systrace深入分析 Perfetto自定义Track GPU Inspector 从现象出发,逐层深入,找到根因

这张图的核心逻辑就是——别跳步。很多人一上来就用GPU Inspector,结果发现CPU那边早就堵死了。先全局后局部,先系统后业务,这是铁律。


好了,今天的内容就到这里。这三个工具,你只要用熟一个,就能解决80%的性能问题。三个都掌握,你就是团队里的性能优化专家了。

公众号:蓝海资料掘金营,微信deep3321