一、硬件加速的本质：从CPU到GPU的跨越
聊到View绘制，很多人第一反应就是onDraw里画点东西。但真正决定流畅度的，其实是底层渲染走的是哪条路——软件绘制还是硬件加速。
我个人习惯把硬件加速理解为：把绘图指令从CPU手里，交给GPU去执行。听起来简单，但背后涉及的东西可不少。
先看一个最直观的对比：
| 对比维度 | 软件绘制 | 硬件加速 |
|---|---|---|
| 执行单元 | CPU | GPU |
| 绘制方式 | 逐像素绘制到Bitmap | 生成DisplayList，GPU批量渲染 |
| 重绘区域 | 脏区域重绘 | 脏区域重绘 + 缓存复用 |
| 动画性能 | 容易掉帧 | 60fps轻松维持 |
| 内存占用 | 较低 | 较高（显存占用） |
你想想看，CPU擅长的是逻辑控制，让它去逐像素画图，其实挺委屈的。GPU天生就是干这个的——并行处理大量像素数据，效率高得多。
核心结论：硬件加速的本质不是「画得更快」，而是「用更合适的工具去画画」。
二、DisplayList：CPU与GPU之间的桥梁
这里有个关键概念——DisplayList。我在项目中遇到过不少同事，搞不清楚它和Canvas的关系。
简单说：
- Canvas 是画板，你往上面画东西
- DisplayList 是画板的「操作记录本」
硬件加速开启后，View的onDraw方法里调用的Canvas操作，并不会立即执行绘制。而是被记录成一条条指令，存到DisplayList里。比如：
// 这段代码在硬件加速下，不会立即画圆
canvas.drawCircle(100, 100, 50, paint);
// 而是生成一条指令：drawCircle(100, 100, 50, paint)
// 存到当前View的DisplayList中等到需要渲染帧的时候，GPU再拿着这个DisplayList，批量执行所有指令。这样做的好处很明显：
- 避免重复计算：View树不变，DisplayList就不变，直接复用
- 减少CPU负载：CPU只负责生成指令，不参与像素填充
- 支持属性动画：平移、旋转、缩放等操作，只需修改DisplayList里的参数，无需重绘
避坑指南：我曾经遇到过一个性能问题——某个自定义View每次onDraw都new一个Path对象。在软件绘制下还好，但硬件加速下，每次new Path都会导致DisplayList失效，触发重新记录。后来改成复用Path对象，帧率直接从30fps飙到60fps。
三、GPU渲染管线：一张图看懂流程
为了让你更直观地理解，我画了一张流程图：
整个流程其实就五步：
- 遍历View树：从DecorView开始，递归遍历所有子View
- 生成DisplayList：每个View把自己的绘制操作记录下来
- 提交GPU指令：把DisplayList转换成OpenGL ES指令
- GPU渲染：GPU并行处理像素数据
- 显示到屏幕：帧缓冲交换，呈现画面
注意：第2步和第3步之间，有一个关键的「缓存复用」机制。如果View的属性没变，DisplayList直接复用，跳过第2步。这就是为什么硬件加速下，属性动画那么流畅的原因。
四、软件绘制 vs 硬件绘制：切换的时机与方式
Android里，硬件加速的开关其实很灵活。你可以控制到Activity级别、Window级别，甚至单个View级别。
4.1 如何开启/关闭
// 1. Application级别（AndroidManifest.xml）
<application android:hardwareAccelerated="true" ...>
// 2. Activity级别
<activity android:hardwareAccelerated="false" ...>
// 3. Window级别（代码中设置）
window.setFlags(
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED
)
// 4. View级别（关闭单个View的硬件加速）
view.setLayerType(View.LAYER_TYPE_SOFTWARE, null)嗯，这里要注意：View级别的关闭，优先级最高。如果你在Application里开了全局加速，但某个View调了setLayerType(SOFTWARE)，那这个View还是会走软件绘制。
4.2 什么时候需要切回软件绘制？
我在项目中遇到过几次，不得不关闭硬件加速的场景：
- Canvas.clipPath()：硬件加速下不支持路径裁剪，会直接忽略
- Canvas.drawPicture()：这个方法在硬件加速下表现不稳定
- 大量Bitmap操作：频繁创建和销毁Bitmap，GPU显存容易爆
- 自定义View使用了复杂的PathEffect：某些效果GPU不支持
警告：不要因为某个小问题就全局关闭硬件加速。我见过有人因为一个View的clipPath不生效，直接把整个App的硬件加速关了，结果其他页面卡成PPT。正确的做法是：只对那个View调用setLayerType(SOFTWARE)。
五、硬件加速的限制：不是万能的
说实话，硬件加速也不是银弹。它有几个明显的短板：
5.1 不支持的操作
| Canvas API | 硬件加速支持情况 | 替代方案 |
|---|---|---|
| clipPath() | 不支持 | 使用clipRect()或Bitmap遮罩 |
| drawPicture() | 不支持 | 使用drawBitmap() |
| drawMesh() | 不支持 | 使用OpenGL直接绘制 |
| setShadowLayer() | 部分支持 | 使用elevation属性 |
| Paint.setMaskFilter() | 不支持 | 使用BitmapShader |
5.2 内存开销更大
硬件加速需要为每个DisplayList分配显存。如果你的View层级特别深（比如超过20层），或者每个View的DisplayList特别大，显存占用会飙升。我记得有个项目，一个复杂列表页的显存占用达到了200MB+，最后不得不做DisplayList的缓存清理策略。
5.3 首次创建开销
第一次创建DisplayList时，需要遍历整个View树，生成所有指令。这个过程比软件绘制慢。所以如果你在Activity的onCreate里做大量绘制操作，可能会感觉到一瞬间的卡顿。
我的建议：对于启动页或者闪屏，可以考虑先用软件绘制，等页面稳定后再切到硬件加速。或者使用ViewStub延迟加载复杂View，避免首帧过重。
六、总结：什么时候该用什么
最后，我整理了一个简单的决策思路：
- 普通页面：默认开启硬件加速，不用纠结
- 动画密集页面：必须硬件加速，否则掉帧严重
- 复杂自定义View：先测试硬件加速是否支持，不支持则局部关闭
- 低端设备：考虑关闭硬件加速，因为GPU性能弱反而更卡
- 启动页/闪屏：软件绘制更稳妥，避免首帧延迟
说白了，硬件加速是个好工具，但得用对地方。你想想看，拿GPU去画一个简单的矩形，其实还不如CPU直接画来得快。但如果是几百个矩形同时动起来，GPU的优势就体现出来了。
嗯，这一章的内容就到这里。记住一句话：硬件加速不是银弹，但它是现代Android渲染的基石。理解它的原理，你才能在遇到性能问题时，知道该从哪里下手。
公众号:蓝海资料掘金营，微信deep3321