30、View的绘制与性能监控：使用Systrace分析绘制性能、使用Profile GPU Rendering、使用Layout Inspector调试布局、常见绘制性能问题排查
说到View绘制，很多同学觉得把measure、layout、draw搞明白就完事了。但说实话，这只是基本功。真正让你在项目中脱颖而出的，是你能不能快速定位并解决绘制性能问题。
我见过太多人，代码写得挺漂亮，一上真机就卡成PPT。为什么？因为你不懂怎么监控、怎么分析、怎么排查。今天我就把这套方法论完整地讲给你听。
核心观点：绘制性能优化不是靠猜，而是靠工具说话。Systrace、Profile GPU Rendering、Layout Inspector，这三板斧用好了，90%的绘制问题都能快速定位。
30.1 使用Systrace分析绘制性能
Systrace是Google官方提供的系统级跟踪工具。它能抓取Android系统各个进程的运行状态，包括CPU调度、磁盘IO、渲染管线等。我个人习惯把它当作性能分析的「第一站」。
为什么？因为它能看到全局。你想想看，一个卡顿问题，可能是UI线程阻塞，也可能是GPU负载过高，还可能是后台线程抢CPU。Systrace能帮你一眼看出瓶颈在哪。
30.1.1 基本用法
使用Systrace有两种方式：命令行和Android Studio的Profiler。我建议初学者先用Profiler，上手快。
// 命令行方式（更灵活）
python systrace.py -t 10 -o trace.html sched gfx view webview
// 常用标签说明：
// sched: CPU调度信息
// gfx: 图形渲染信息
// view: View绘制信息
// webview: WebView渲染信息抓取完成后，你会得到一个HTML文件。用Chrome打开它，就能看到时间轴。这里有个关键点：你要关注的是Frame这个颜色条。如果它显示红色或黄色，说明这一帧超时了（超过16ms）。
我的小技巧：抓取时尽量模拟真实用户操作。比如快速滑动列表、频繁点击按钮。别只抓静止状态，那样看不出问题。
30.1.2 如何解读Systrace
拿到Systrace后，别急着看细节。先看整体：有没有大片的红色Frame？如果有，说明你的应用存在持续卡顿。
然后放大看某个红色Frame。你会看到三个关键阶段：
- Choreographer#doFrame：UI线程处理输入事件和动画
- DrawFrame：渲染线程执行绘制命令
- swapBuffers：将渲染结果提交到屏幕
我曾经遇到一个项目，列表滑动总是掉帧。用Systrace一看，发现DrawFrame阶段有个大缺口——渲染线程在等GPU完成上一帧。说白了就是GPU过载了。后来把一些复杂背景图换成纯色，问题就解决了。
30.2 使用Profile GPU Rendering
Profile GPU Rendering是Android开发者选项里的一个功能。它能以柱状图的形式，直观展示每一帧的渲染耗时。我建议你把它当作日常开发中的「体检仪」。
30.2.1 开启方式
在真机上：设置 → 开发者选项 → 监控 → Profile GPU Rendering → 选择「在屏幕上显示为条形图」。
开启后，屏幕上方会出现一排彩色竖条。每个竖条代表一帧，颜色代表不同阶段：
| 颜色 | 代表阶段 | 说明 |
|---|---|---|
| 蓝色 | 测量与布局 | View的measure和layout过程 |
| 紫色 | 绘制 | View的draw过程 |
| 红色 | 渲染线程 | RenderThread处理绘制命令 |
| 橙色 | GPU处理 | GPU执行渲染指令 |
每个竖条的高度代表耗时。如果超过绿色基准线（16ms），说明这一帧超时了。
注意：Profile GPU Rendering只能看到整体耗时，不能精确定位到具体代码。它适合做「快速筛查」——看到哪一帧有问题，再用Systrace深入分析。
30.2.2 实战案例
我记得有一次，一个同事说他的页面滑动卡顿。我打开Profile GPU Rendering一看，蓝色条特别高。这说明测量和布局阶段耗时严重。
进一步排查发现，他用了嵌套的LinearLayout，而且每个子View都做了复杂的weight计算。我建议他改成ConstraintLayout，蓝色条立刻降下来了。
30.3 使用Layout Inspector调试布局
Layout Inspector是Android Studio自带的布局调试工具。它能实时查看当前界面的View层级、属性值和布局参数。说白了，就是给布局做「CT扫描」。
30.3.1 基本操作
在Android Studio中：Tools → Layout Inspector → 选择你的设备和进程。
打开后，你会看到三个面板：
- 左侧：View层级树，可以展开/折叠
- 中间：屏幕截图，可以点击选中某个View
- 右侧：选中View的详细属性
我最常用的是「查看布局嵌套深度」。如果层级超过10层，基本可以断定有性能隐患。为什么？因为每多一层嵌套，measure和draw就要多递归一次。
30.3.2 常见问题排查
用Layout Inspector能发现很多「肉眼看不见」的问题：
- 过度绘制：多个View重叠，导致同一像素被多次绘制
- 无效布局：有些View完全被遮挡，但仍然参与测量和绘制
- 属性冗余：比如同时设置了background和foreground，但foreground根本看不见
我曾经排查过一个案例：一个页面打开很慢，用Layout Inspector一看，发现有个ImageView被另一个View完全覆盖了。但代码里还是加载了它的图片。去掉这个ImageView后，页面打开速度提升了30%。
30.4 常见绘制性能问题排查
掌握了工具，还得知道「查什么」。下面是我总结的几个高频问题，每个都是我踩过的坑。
30.4.1 过度绘制
过度绘制是指同一像素被多次绘制。Android提供了「调试GPU过度绘制」功能，开启后界面会显示不同颜色：
| 颜色 | 过度绘制次数 | 建议 |
|---|---|---|
| 蓝色 | 1次 | 理想状态 |
| 绿色 | 2次 | 可接受 |
| 粉色 | 3次 | 需要优化 |
| 红色 | 4次及以上 | 必须优化 |
优化方法很简单：去掉不必要的背景、使用merge标签减少层级、用clipRect限制绘制区域。
30.4.2 布局嵌套过深
这个问题在老旧项目中特别常见。有些人喜欢用LinearLayout一层套一层，结果嵌套了七八层。measure的时候，每个子View都要递归计算，能不卡吗？
我的建议是：用ConstraintLayout替代多层嵌套。它一次遍历就能完成所有子View的测量和布局。
30.4.3 动画性能问题
动画卡顿通常有两个原因：一是动画过程中触发了measure/layout，二是动画帧率不够。
对于第一个问题，可以用View.setLayerType()开启硬件加速。对于第二个问题，可以用Choreographer监听帧率，如果低于30fps，就要考虑简化动画逻辑。
避坑指南：我曾经在动画里频繁调用requestLayout()，结果动画卡成PPT。后来改成用属性动画（ObjectAnimator），只改变translationX/Y，不触发布局，问题就解决了。
30.4.4 图片加载过慢
图片加载是绘制性能的「隐形杀手」。一张大图加载到内存，不仅占用大量内存，还会拖慢绘制速度。
我的做法是：用Glide或Coil加载图片，并设置合适的采样率。比如一个100x100的ImageView，没必要加载2000x2000的原图。
30.5 知识体系总览
下面这张图，是我对本章内容的总结。你可以把它当作「绘制性能监控的作战地图」。
这张图的核心逻辑是：先用Profile GPU Rendering做快速筛查，发现卡顿帧；然后用Systrace深入分析，定位到具体阶段；最后用Layout Inspector检查布局细节。三个工具配合使用，基本能覆盖90%的绘制性能问题。
好了，关于绘制性能监控的内容就讲到这里。记住，工具只是手段，关键是你得有「性能意识」。写每一行代码时，都想想它会不会影响绘制速度。久而久之，你就能写出既快又稳的界面。