系列文章目录：
- Android性能优化典范综述
- Android性能优化典范之Render Performance
- Android性能优化典范之Understanding Overdraw
- Android性能优化典范之Understanding VSYNC
- Android性能优化典范之Profile GPU Rendering
技术复核（2026-10-13）：本文保留 2015 年视频的三色柱形图。旧图的 Update / Execute / Process 可对照 Android 4.4.4 源码；Android 6.0 与 Android 16 已有更细的分段和不同参考线实现，不能把旧图例套到所有设备。
当时的视频简介：
“If you can measure it, you can optimize it” is a common term in the computing world, and for Android’s rendering system, the same thing holds true. In order to optimize your pipeline to be more efficient for rendering, you need a tool to give you feedback on where the current perf problems lie.
And in this video, +Colt McAnlis walks you through an on-device tool that’s built for this exact reason. “Profile GPU Rendering” will help you understand the stages of the rendering pipeline, and also get a chance to see what portions of it might be taking too long, and what you can do about it for your application.
GPU Profile工具
Profile GPU Rendering 是开发者选项里的快速观察工具，可以帮助找到哪些操作伴随较高的绘制耗时。它的名字虽然有 GPU，柱形图却不是 GPU 硬件执行时间的直接测量，也不能单独告诉你卡顿的全部原因。官方说明
先用柱形图找可疑操作，再用系统 trace 看相关线程、调度、GPU 与合成证据。应用的 HWUI 柱子不能代替 SurfaceFlinger 的完整时间线，也不能覆盖所有自建 OpenGL/Vulkan 渲染路径。
在 Android 4.1 / API 16+ 的开发者选项中查找 Profile GPU Rendering 或 Profile HWUI Rendering，选择 On screen as bars。名称和入口随系统版本、厂商而变：
旧版示例会出现蓝、红、橙黄三段柱形和绿色参考线：
这张旧图同时显示了应用与 System UI 窗口的图形：顶部靠近状态栏，底部靠近导航栏，应用区域另有自己的图。不是“最上面永远测通知、最下面永远测导航”的固定规则；要看柱形图属于哪个窗口。
使用GPU Profile工具
每根柱子表示该窗口一次记录到的帧，其分段高度对应被统计阶段的耗时。屏上只保留有限的历史记录；柱子不是 FPS 数字，也不是完整的输入到显示延迟。没有新柱子不一定代表卡住，静止页面可能没有新的绘制工作。
绿线
下图标的是 16ms。这与 Android 4.4.4 HardwareRenderer 的 getThreshold() 返回 16 一致，Android 6.0 FrameInfoVisualizer 也使用固定 16ms 参考值；而 60Hz 的周期准确说约为 16.67ms。
超过参考线值得检查，但不能据此断言“用户一定看见卡顿”，低于参考线也不证明一定按时呈现。90Hz、120Hz 的周期分别约 11.11ms、8.33ms；高刷新率和后续版本需要按设备上的实际参考线、帧期限分析。
柱状图
下面先解释旧图的三段。历史截图没有保留精确系统构建号，这里以 Android 4.4.4 的 Java HardwareRenderer 计时范围为例：
蓝色：Update / Draw
旧实现计时的是 buildDisplayList() 中构建或更新 display list 的工作。它记录绘制命令，包括需要更新的 View 的绘制逻辑；不是每帧重新执行所有 View 的 onDraw，也不等于整段 measure/layout 耗时。未失效的 display list 可以复用。
蓝色升高时，可以检查是否频繁失效、绘制逻辑是否昂贵、是否有本可移出绘制路径的工作，但仍要结合 trace 定位。
红色：Execute / Issue commands
旧实现计时的是 canvas.drawDisplayList() 调用，包含 CPU 侧重放并提交绘制命令的工作。图中 OpenGL ES 是那个版本的渲染路径；命令已提交不等于 GPU 已完成，更不等于画面已经上屏。
较多绘制操作、复杂路径或提交过程中的等待，都可能让这一段变高。复杂的自定义 View 是候选原因，不能仅凭红色就认定它是“罪魁祸首”。
变换或动画可能复用已有 display list 再次提交，而不重新记录命令。因此红色增加时，蓝色不一定一起增加；也不能推断下面所有 View 的 onDraw() 都重跑了。阶段分析说明
橙黄：Process / Swap buffers
Android 4.4.4 在 eglSwapBuffers() 前后计时。旧图写成了 glSwapBuffers，这里应是 EGL 的 eglSwapBuffers。它不能解释成“CPU 等 GPU 回复收到了命令”：GPU 与 CPU 可以异步工作，驱动或缓冲队列的背压、等待可复用 buffer 等，都可能让调用变慢。橙黄较高是等待/提交路径的线索，不能单独证明 GPU 算力不足，也不是纯 GPU 执行时间。
Android 6.0 / Android 16 怎么读
Android 6.0 / API 23 的 FrameInfoVisualizer 和 Android 16 / API 36 的对应实现 使用七个分段。下面概括这两个源码标签的图例；厂商系统的配色可能不同：
| 颜色 | 阶段 | 主要观察内容 |
|---|---|---|
| 蓝绿色 | Misc / VSync delay | IntendedVsync 到 HandleInputStart 的间隔，可能含迟到或其他主线程工作 |
| 深绿色 | Input / Animation | 输入处理与动画相关阶段 |
| 浅绿色 | Measure / Layout | 遍历开始到 DrawStart，帮助观察测量与布局 |
| 蓝色 | Draw | DrawStart 到 SyncStart，绘制记录等工作 |
| 浅蓝色 | Sync / Upload | 渲染同步和资源准备相关阶段 |
| 红色 | Issue commands | IssueDrawCommandsStart 到 SwapBuffers |
| 橙色 | Swap buffers | SwapBuffers 到 FrameCompleted |
Android 16 这份源码还按传入的 frameInterval 绘制 0.8、1.0、1.5 倍周期 的绿、黄绿、红三条参考线，并缩放纵轴。不能再把“绿色水平线”等同于固定 16ms。不同分段是计时区间，不保证每个区间只有一种工作；View、Compose 混合页面也不能简单把某种颜色当作某个组件的全部开销。
实际排查时，记录设备系统版本、刷新率、操作与最明显的阶段。Android 12 / API 31+ 再用 Perfetto FrameTimeline 核对预期和实际帧；旧系统按可用的系统 trace 分析。修复后关闭屏上调试覆盖层，在相同设备和场景下做 Macrobenchmark 回归：FrameTimingMetric 从 AndroidX Benchmark 1.1.0 提供，frameOverrunMs 要求 API 31+，与 frameDurationCpuMs 含义不同。目标应用按配置要求使用 non-debuggable、profileable 构建。
总结
GPU Profile工具能够很好地帮助你找到渲染相关的问题,但是要修复这些问题就不是那么简单了. 你需要结合代码来具体分析,找到性能的瓶颈,并进行优化.
有时候你可以以这个为工具,让负责设计这个产品的人修改他的设计,以获得良好的用户体验.
Perf Matters
keep calm, profile your code, and always remember, Perf Matters
关于我 && 博客
下面是个人的介绍和相关的链接，期望与同行的各位多多交流，三人行，则必有我师!
- 博主个人介绍 ：里面有个人的微信和微信群链接。
- 本博客内容导航 ：个人博客内容的一个导航。
- 个人整理和搜集的优秀博客文章 - Android 性能优化必知必会 ：欢迎大家自荐和推荐 （微信私聊即可）
- Android性能优化知识星球：付费社群已于 2026 年停止运营，不再招收新成员；此处保留历史介绍。
一个人可以走的更快 , 一群人可以走的更远
