Unity优化

我们在做游戏的时候，应该了解哪些性能因素影响游戏，才能对症下药。对于一个游戏来说，主要有两种计算资源：cpu和GPU。这两者会互相合作，来让游戏可以在预期的帧率和分辨率下工作。cpu负责帧率，GPU主要负责与分辨率相关的一些东西。

总结起来，主要有以下性能瓶颈：

cpu:过多的Draw Calls;复杂的脚本或者物理模拟。

顶点处理：过多的顶点；过多的逐顶点计算。

像素（Fragment）处理（GPU）:过多的fragment,overdraws;过多的逐像素计算。

宽带：尺寸很大且未压缩的纹理；分辨率过高的framebuffer。

对于cpu来说，限制它的主要是游戏中的Draw Calls。那么什么是Draw Call呢？在OpenGL中，在每次绘图前，我们都需要先准备好顶点数据（位置、法线、颜色、纹理坐标等），然后调用一系列API把它们放到GPU可以访问到的指定位置，最后，我们需要调用_glDraw命令，来告诉GPU进行渲染，而调用_glDraw命令的时候，就是一次Draw Call。为什么Draw Call会成为性能瓶颈呢（而且是cpu的瓶颈）？我们想要绘制图像时，就一定需要调用Draw Call。例如，一个场景里有水有树，我们渲染水的时候使用的是一个material以及一个shader，但渲染树的时候就需要一个完全不同的material和shader，那么就需要cpu重新准备顶点数据、重新设置shader，而这种工作实际是非常耗时的。如果场景中，每一个物体都使用不同的material、不同的纹理，那么就会产生太多Draw Call，影响帧率，游戏性能就会下降。

  如何减少DrawCalls?

主要介绍批处理（Batching）

最常见的就是通过批处理（Batching）了。从名字上来理解，就是一块处理多个物体的意思。那么什么样的物体可以一起处理呢？答案就是使用同一个材质的物体。这是因此，对于使用同一个材质的物体，它们之间的不同仅仅在于顶点数据的差别，即使用的网格不同而已。我们可以把这些顶点数据合并在一起，再一起发送给GPU，就可以完成一次批处理。

Unity中有两种批处理方式：一种是动态批处理，一种是静态批处理。对于动态批处理来说，好消息是一切处理都是自动的，不需要我们自己做任何操作，而且物体是可以移动的，但坏消息是，限制很多，可能一不小心我们就会破坏了这种机制，导致Unity无法批处理一些使用了相同材质的物体。对于静态批处理来说，好消息是自由度很高，限制很少，坏消息是可能会占用更多的内存，而且经过静态批处理后的所有物体都不可以再移动了。

首先来说动态批处理。Unity进行动态批处理的条件是，物体使用同一个材质并且满足一些特定条件。Unity总是在不知不觉中就为我们做了动态批处理。例如下面的场景：这个场景共包含了4个物体，其中两个箱子使用了同一个材质。可以看到，它的Draw Calls现在是3，并且显示Save by batching是1，也就是说，Unity靠Batching为我们节省了1个Draw Call。下面，我们来把其中一个箱子的大小随便改动一下，看看会发生什么：可以发现，Draw Calls变成了4，Save by batching的数目也变成了0。这是为什么呢？它们明明还是只使用了一个材质啊。原因就是前面提到的那些需要满足的其他条件。动态批处理虽然自动得令人感动，但它对模型的要求很多：顶点属性的最大限制为900，而且未来有可能会变。不要依赖这个数据。

一般来说，那么所有对象都必须需要使用同一个缩放尺度（可以是(1, 1, 1)、(1, 2, 3)、(1.5, 1.4, 1.3)等等，但必须都一样）。但如果是非统一缩放（即每个维度的缩放尺度不一样，例如(1, 2, 1)），那么如果所有的物体都使用不同的非统一缩放也是可以批处理的。这个要求很怪异，为什么批处理会和缩放有关呢？这和Unity背后的技术有关系。

使用lightmap的物体不会批处理。多passes的shader会中断批处理。接受实时阴影的物体也不会批处理。

上述除了最常见的由于缩放导致破坏批处理的情况，还有就是顶点属性的限制。例如，在上面的场景中我们添加之前未优化后的箱子模型：可以看到Draw Calls一下子变成了5。这是因为新添加的箱子模型中，包含了474个顶点，而它使用的顶点属性有位置、UV坐标、法线等信息，使用的总和超过了900。

动态批处理的条件这么多，一不小心它就不干了，因此Unity提供了另一个方法，静态批处理。接着上面的例子，我们保持修改后的缩放，但把四个物体的“Static Flag”勾选上：

点击Static后面的三角下拉框，我们会看到其实这一步设置了很多东西，这里我们想要的只是“Batching static”一项。这时我们再看Draw Calls，恩，还是没有变化。但是不要急，我们点击运行，变化出现了：

Draw Calls又回到了3，并且显示Save by batching是1。这就是得利于静态批处理。而且，如果我们在运行时刻查看模型的网格，会发现它们都变成了一个名为Combined Mesh (roo: scene)的东西。这个网格是Unity合并了所有标识为“Static”的物体的结果，在我们的例子里，就是四个物体：

你可以要问了，这四个对象明明不是都使用了一个材质，为什么可以合并成一个呢？如果你仔细观察上图的话，会发现里面标明了“4 submeshes”，也就是说，这个合并后的网格其实包含了4个子网格，也就是我们的四个对象。对于合并后后的网格，Unity会判断其中使用同一个材质的子网格，然后对它们进行批处理。

但是，我们再细心点可以发现，我们的箱子使用的其实是同一个网格，但合并后却变成了两个。而且，我们观察运行前后Stats窗口中的“VBO total”，它的大小由241.6KB变成了286.2KB，变大了！

这里就体现了静态批处理的缺点，如果在静态批处理前有一些物体共享了相同的网格（例如这里的两个箱子），那么每一个物体都会有一个该网格的复制品，即一个网格会变成多个网格被发送给GPU。在上面的例子看来，就是VBO的大小明显增大了。如果这类使用同一网格的对象很多，那么这就是一个问题了，这种时候我们可能需要避免使用静态批处理，这意味着牺牲一定的渲染性能。例如，如果在一个使用了1000个重复树模型的森林中使用静态批处理，那么结果就会产生1000倍的内存，这会造成严重的内存影响。这种时候，解决方法要么我们可以忍受这种牺牲内存换取性能的方法，要么不要使用静态批处理，而使用动态批处理（前提是大家使用相同的缩放大小，或者大家都使用不同的非统一缩放大小），或者自己编写批处理的方法。当然，我认为最好的还是使用动态批处理来解决。

 

有一些小提示可以使用：
尽可能选择静态批处理，但得时刻小心对内存的消耗。

如果无法进行静态批处理，而要使用动态批处理的话，那么请小心上面提到的各种注意事项。例如：

尽可能让这样的物体少并且尽可能让这些物体包含少量的顶点属性。

不要使用统一缩放，或者都使用不同的非统一缩放。

对于游戏中的小道具，例如可以捡拾的金币等，可以使用动态批处理。

对于包含动画的这类物体，我们无法全部使用静态批处理，但其中如果有不动的部分，可以把这部分标识成“Static”。