批处理

静态批处理

标记为Batching Static的物体，在使用相同材质球的条件下，在项目打包时Unity会自动将这些物体合并到一个大的Mesh，并且提取这些共享材质的静态模型的顶点和索引数据放到一个共享Vertex buffer和Index buffer。
优点：提高渲染效率，并不会减少DrawCall，只是减少了渲染状态设置，但是编辑器中会显示Batch减少。
缺点：

打包体积增大，运行时内存也增大。
多个不同的GameObject引用同一Mesh的情况下：
不开启Static batching：GameObject共享Mesh会在应用程序包及内存中只存在一份，绘制的时候提交模型顶点信息，然后设置每一个GameObject的材质信息，分别调用渲染API绘制。

开启Static batching：在Unity执行Build的时候，场景中所有引用相同模型的GameObject都必须将模型顶点信息复制，并经过计算变化到最终在世界空间中，存储在最终生成的Vertex buffer中。这就导致了打包的体积及运行时内存的占用增大（如，茂密的森林场景将数标记为静态就会严重影响内存）。

动态批处理

Unity在运行时对符合条件的动态对象在一个DrawCall内绘制，降低DrawCall的数量。
基本条件：

不超过300个顶点（不超过总计900个属性）
不包含镜像的Scale缩放
材质一样
物体的lightmap指向的位置一样

原理：在运行时，场景绘制之前，CPU将所有的共享同一材质的模型的顶点信息变换到世界空间中，然后通过一次DrawCall绘制多个模型，达到合批的目的。
缺点：

在降低DrawCall的同时会导致额外的CPU性能消耗，所以仅仅在合批操作的性能消耗小于不合批时，动批才会有意义。
新一代图形API（Metal、Vulkan）在批次间的消耗降低了许多，所以在这种情况下使用动批很可能不能获得性能提升。
动批相对于静批不需要预先复制模型顶点，所以在内存占用和发布的程序体积方面要优于静批。但是动批会带来一些运行时CPU性能消耗，静批在这一点上要比动批更高效。

合批中断的情况：

物体如果都符合条件会优先参与静态批处理，再是GPU Instancing，然后才到动态批处理。
使用多pass shader的物体会禁用动批。
多个GameObject须共享同一材质，但是对于shadow casters渲染是个例外。尽管Shadow casters使用不同的材质，但是只要他们的材质中给Shadow casters Pass使用的参数是相同的，他们也能够进行动批。
Unity的Forward Rendering Path中如果一个GameObject接受多个光照会为每一个per-pixel light产生提交和绘制，从而附加了多个Pass导致无法合批。

GPU Instancing

使用少量的DrawCall就能绘制多个相同的Mesh，如场景中的建筑、路灯、树木、草、石头等。
针对单个材质开发的。
原理：同材质、同Mesh的物体；仅绘制一个；其他物体“复制”出来。
限制：

同Mesh同材质能合并到一个DrawCall中
支持MeshRenderer和Graphics.DrawMesh调用
不支持SkinnedMeshRenderer

无法加速的情况：

缩放为负值；
代码动态改变材质变量后不算同一个材质，但可以通过将颜色变换等变量加入常量缓冲区中实现；
受限于常量缓冲区在不同设备上的大小的上限，同批的个数可能不同；
只支持一盏实时光，要在多个光源的情况下使用实例化，只能切换到延迟渲染路径。

SRP Batcher

SRP Batcher是一个渲染循环，可加速相同着色器变体的多种材质在场景中的CPU渲染速度。
限制：仅支持SRP
原理：

和GPU Instancing类似
Shader中的变体一致
降低SetPass Call的消耗，并没有降低DrawCall

无法合批的情况：

对象不可以是粒子或蒙皮网格
Shader中变体不一致，如Surface Options不一致，导致变体不一样而无法合并
位置不相邻且中间夹杂着不同Shader或不同变体的其他物体，不会进行同批处理（所有合批都是这样）

小结

优先级顺序
SRP Batcher > Static Batching > GPU Instancing > Dynamic Batching

	静态	动态	GPU Instancing	SRP Batcher
优点	限制少	自动无须处理	性能极好	多材质加速
缺点	会增加包体大小，增加运行时内存大小	增加运行时CPU消耗，限制多	限制多	只能用于SRP中
适用场景	静态场景，不适合大量重复物体	小物体、特效等	大量重复物体	较为广泛