unity--优化CPU之DrawCall
前言
CPU准备数据并通知GPU渲染的过程就是一次DrawCall,如果这个过程出现的次数太多，就会影响CPU的执行效率，就会出现卡顿。
当然，影响CPU的不仅仅只有DrawCall,还有物理组件、GC（垃圾对象太多，造成GC负担，影响CPU的执行效率）、代码质量。
Draw Call Batching
在屏幕上绘制一个物体，U3D引擎必须向绘图API（openGL或者D3D）发起一次DrawCall。
这些DrawCall往往是昂贵的，当绘图API为每个DrawCall做一些重要的事情，引起GPU的性能消耗较高。
这些消耗大部分是因为DrawCall结束的状态切换引起的（比如，从一个材质切换到另一个材质），因为这会引发昂贵显卡驱动的验证和变换步骤。
Unity使用多种技术来解决这个问题：
静态Batching：把静态的物体合并成一个大meshes，然后用更快的方法渲染他们。
动态Batching：对于足够小的meshes，在CPU上变换他们的顶点，将一些相似的组合到一起，在一次中绘制。
内建的Baching相对于手动合并物体到一起有几个好处（值得注意的是，这些对象仍可以被单独销毁）。
但是他也有它的缺点（静态Batching会导致内存和存储的开销，动态Batching会导致CPU开销）。
Material Setup For Batching（合并材质）
只有共享同一个材质的物体才能被Batched在一起。如果，你想达到一个好的batching，你需要竟可能多的在不同物体中共享材质。
如果你有两个同样的材质但是他们的textures不同，你可以合并这些textures到一个大texture - 这个过程经常被叫做texture atlasing。
一旦textures在同一个图集中，你就可以使用一个材质来代替了。
如果你需要在脚本中访问共享了的材质，有一个很重的点需要注意：修改Renderer.material属性会创建一个当前材质的副本。
所以，作为替换方案，你应该使用Rednerer.sharedMaterial以保证材质被共享。
当渲染阴影投射的时候，即使他们的材质是不同的，也经常被batched到一起。
只要材质中的数值在shadow pass是相同的，即使阴影投射有不同的材质，他们也可以使用动态batching。
举个例子，许多箱可以使用具有不同的texture的材质，但对于阴影投射渲染 texture是不相关 - 在这种情况下，他们可以被batched到在一起。
Dynamic Batching(动态批处理)
Unity可以自动batch移动物体到相同的draw call，如果它们具有相同的材质和满足其它标准。动态Batching是自动完成的，不需要你做额外的事情。
Batching 动态的物体每个顶点会有某些开销，所以batching只适用于顶点数小于900的meshes。如果你得shader使用了顶点位置，法线和单独的UV，那么你可以batch 300 个顶点;如果你得shader使用了顶点位置，法线，UV0，UV1，和正切，只能batch 180个顶点。
这个限制的数量将来有可能会变化。
其它限制
- 如果物体包含镜像变换，他们将不会被batched，例如，object A 的scale 为 +1 object B 的scale 为-1，就不能batched到一起。
- 使用不同材质的实例，即使他们实质上是相同的，也会导致两个物体不能被batched到一起。阴影投射除外。
- 具有光照贴图的对象有额外的渲染参数：光照索引和 偏移/放缩 的光照。所以一般动态lightmapped对象应指向完全相同的光照贴图位置然后再进行batch。
- 多通道的shader将不会被batching几乎所有的Unity shader都支持前置渲染几个灯光，有效的为他们做更多的通道。“额外的逐像素的灯光”的draw call 将不会被batched。
- 传统的延迟渲（逐通道光照）染通道禁用了动态batching，因为它必须绘制两次。
由于它的工作原理是变换所有的物体的顶点到CPU的世界坐标中，所以它仅仅在它的工作（变换到cpu的世界坐标）比做一次“draw call”小的时候才能起到好的作用。
究竟一个DrawCall有多昂贵取决于诸多因素，主要是所用的绘图API。例如，在控制台或当前流 行的APIs例如Apple Metal DrawCall的开销一般比较低，所以一般动态batching不会达到好的效果。
Static Batching（静态批处理）
静态batching允许引擎减少draw call适用于任何大小的几何对象（假设没有移动和共享材质）。大部分情况下他比动态batching更高效 ，但是它会占用更多的内存。
为了使静态batching更好的获益，你需要明确的指定游戏中某些物体是静态的而且不会移动，旋转或者缩放。这样做，你可以在Inspector界面中的“Static”选项（chekbox）标记物体为static：
使用静态batching将需要额外的内存来存储合并后的几何信息。如果几个物体在静态batching之前共享同一个几何图元，那么这个几何图元将会为每个物体复制一份，无论在Editor中还是runtime中都是如此。这不是一个好方法 - 有时候为了保持更小的内存占用量，你必须牺牲渲染性能为了避免一些物体的静态batching。例如，在一个稠密的森林中，标记树木为static会产生严重的内存影响。
在内部，静态batching的原理是变换这些静态物体到世界控件然后为他们建立一个很大顶点+索引 缓冲区。然后所有显示的物体都放到一个batch，一系列“便宜的”draw call就完成了，这期间几乎没有状态切换（state change）。所以 从技术上来讲 这并没有节省“3D API draw call”，但是他节省了他们之间的状态切换（状态切换才是罪魁祸首）。
Other Batching Related Tips
目前，只有网格渲染才被batched。像 skinned meshes，cloth，拖尾渲染器（Trail Renderer）和其他类型的渲染组件是不被batched的。
半透明shader为了做透明度的工作，经常需要物体以从后到前的顺序进行渲染。
Unity首先会对物体进行排序，然后试着batch他们 - 因为这个顺序是严格限制的，这就意味着 相对于不透明物体来说，会有很少的batching产生。
相对调用draw call来说，手动合并比较近的物体可能是一个非常不错的选择。
例如，许多抽屉的静态柜子合并成一个mesh经常是有道理的，无论是在3D建模软件中还是使用Mesh.CombineMeshaes.
