渲染管线优化：从 OpenGL ES 到 Vulkan 的实战之路

渲染管线优化，说白了就是让 GPU 干活更快、更省。我做了这么多年 Camera HAL，见过太多因为渲染卡顿导致预览掉帧、拍照延迟的案例。今天咱们就聊聊这块的核心技巧。

OpenGL ES 渲染优化：别让 GPU 闲着

OpenGL ES 在 Android 上用了十几年，虽然 Vulkan 后来居上，但很多中低端设备还是靠它。我个人习惯从三个维度下手：

• 减少状态切换：OpenGL ES 最怕频繁切换纹理、Shader、缓冲区。我在项目中遇到过，一次简单的纹理绑定切换，可能带来几十微秒的延迟。建议把同类型的绘制调用合并，按状态分组提交。
• 使用 VBO 和 EBO：别每次绘制都重新上传顶点数据。把顶点数据缓存到 GPU 显存里，能省掉大量 CPU-GPU 传输开销。
• 避免 glFinish：这个调用会强制 CPU 等待 GPU 完成所有任务。我曾经在调试时发现，一个 glFinish 能吃掉 5ms 的帧时间。用 glFenceSync 替代它，更优雅。

Vulkan 渲染优化：精细控制的力量

Vulkan 给了你更多控制权，但也更容易踩坑。我记得第一次迁移到 Vulkan 时，光是 Command Buffer 的管理就折腾了两周。

几个关键优化点：

• Command Buffer 预记录：把不变的绘制命令提前录制好，运行时直接提交。我习惯在初始化阶段就准备好主渲染通道的 Command Buffer。
• Descriptor Set 复用：别每帧都重新创建 Descriptor Set。用池化技术，提前分配好一组 Descriptor Set，按需切换。
• Pipeline 缓存：Vulkan 的 Pipeline 创建很重。把编译好的 Pipeline 缓存到磁盘，下次启动直接加载。嗯，这个在 Camera 预览场景特别有用。

Shader 优化技巧：写得更聪明

Shader 是 GPU 直接执行的代码，写得好不好，性能差好几倍。我总结了几条铁律：

• 减少分支：GPU 是 SIMD 架构，分支会让部分线程空转。能用数学运算替代的条件判断，尽量替代。
• 精度选择要谨慎：mediump 比 highp 快很多，但精度不够。Camera 场景里，颜色计算用 mediump 就够了，但坐标计算必须用 highp。
• 纹理采样次数控制：一次纹理采样大约 4-8 个周期。我见过一个 Shader 里采样了 12 次纹理，优化到 4 次后，性能翻倍。

// 不好的写法：大量分支
if (coord.x > 0.5) {
    color = texture2D(tex1, uv);
} else {
    color = texture2D(tex2, uv);
}

// 好的写法：用 mix 替代分支
float t = step(0.5, coord.x);
color = mix(texture2D(tex2, uv), texture2D(tex1, uv), t);

RenderPass 合并：减少带宽消耗

RenderPass 合并，说白了就是把多个渲染步骤合并到一个 Pass 里完成。为什么要这么做？因为每次 RenderPass 结束，都需要把结果写回内存，下一个 Pass 再读出来。这个读写操作非常耗带宽。

我建议的做法：

• 延迟渲染合并：把 G-Buffer 的写入和光照计算合并到一个 Pass 里，减少中间结果的读写。
• Subpass 利用：Vulkan 的 Subpass 机制允许你在同一个 RenderPass 内传递数据，不需要经过内存。我在 Camera 后处理管线里，把颜色校正、伽马矫正、色调映射合并到三个 Subpass 里，带宽节省了 30%。
• Tile-based 渲染器优化：移动 GPU 大多是 Tile-based 架构。合并 RenderPass 能让数据留在 Tile 内存里，避免写回主存。

知识体系总览

下面这张图是我自己整理的渲染管线优化知识结构，你可以对照着查漏补缺：

渲染管线优化没有银弹。每个项目、每个 GPU 都有自己的脾气。我的建议是：先 profiling，再优化。用 Android GPU Inspector 或者 Snapdragon Profiler 抓一下数据，看看瓶颈到底在哪。别凭感觉乱改，那只会让代码更乱。