是什么#

动态合批会在 CPU 侧把多个小网格临时整理到同一批提交数据里，再以更少的批次提交给 GPU，从而减少批次数和状态切换。

【重点】它优化的是“提交成本”，不是让 GPU 少画东西。顶点还是那些顶点，只是 Unity 尝试把本来分散的小对象合并提交。

适用条件#

动态合批只有在对象足够“小且像”的时候才值得做，常见条件包括：

• 共享同一个材质实例和相同的 Shader Pass
• 顶点属性总量不超过 900，顶点数通常不超过 300
• 顶点属性越多，可参与合批的顶点上限越低
• 带镜像的缩放、额外材质差异等因素都可能打断合批

【例子】如果 Shader 只使用 Position、Normal、UV0，通常还能容纳约 300 顶点；如果再加 UV1 和 Tangent，可合批的顶点数会进一步下降。

CPU 开销来自哪里#

动态合批不是“白送”的，主要成本在：

• 每帧把对象顶点转换到合适的提交空间
• 重新组织批次数据
• 在 CPU 侧维护可合批对象的排序与提交

所以当项目已经是 CPU 瓶颈时，动态合批不一定带来净收益，甚至可能更慢。

什么时候更适合开启#

• 小型重复物体很多，例如简单场景摆件、低面数道具
• GPU 不是主要瓶颈，反而是渲染提交成本偏高
• 目标设备偏旧，单次 draw 提交成本仍然明显

什么时候要谨慎#

• 网格顶点并不小，CPU 为了合批付出的整理成本过高
• Shader 顶点属性复杂，能合进去的对象本来就很少
• 已经有更合适的手段，例如静态场景用 静态合批，大量相同网格用 GPU Instancing
• 现代低开销图形 API 或高端设备上，动态合批的收益往往不稳定，更需要真机验证

与其他方案的区别#

实际判断方法#

1. 在 Profiler 的 Rendering 模块里看 Batches 是否下降。
2. 同时观察主线程和渲染线程时间有没有真正变好。
3. 如果批次数下降了但 CPU 时间没降，说明合批带来的 CPU 整理成本把收益吃掉了。

【注意】不要因为“批次数更低”就默认更优。性能优化看的是帧时间，不是某一个指标单独变漂亮。