unity3d引擎缓存优化技术_移动平台Unity3D 应用性能优化

Draw Call 的优化

前面说过了，DrawCall是CPU调用底层图形接口的操作。比如有上千个物体，每一个的渲染都需要去调用一次底层接口，而每一次的调用CPU都需要做很多工作，那么CPU必然不堪重负。但是对于GPU来说，图形处理的工作量是一样的。

我们先来看看Draw Call对CPU的消耗大概是一个什么级别的量：

NVIDIA 在 GDC 曾提出，25K batchs/sec 会吃满 1GHz 的 CPU，100%的使用率。有一个公式可以和清楚得计算出在给定的CPU资源 与 帧率的情况下，最多能有多少个DrawCall。

DrawCall_Num = 25K * CPU_Frame * CPU_Percentage / Framerate。

DrawCall_Num ： DrawCall数量

CPU_Frame : CPU 工作频率(GHz单位)

CPU_Percentage：CPU 分配在DrawCall这件事情上的时间率(百分比)

Framerate：希望的游戏帧率

比如说我们使用一个高通820，工作频率在2GHz上，分配10%的CPU时间给DrawCall上，并且我们VR要求60帧，那么一帧最多能有83个DrawCall(由于双camera的存在，单眼DrawCall只能保证在41个以内)。其实，google官方的建议是单眼DrawCall不多于50个。

所以对DrawCall的优化，主要就是为了尽量解放CPU在调用图形接口上的开销。所以针对drawcall我们主要的思路就是每个物体尽量减少渲染次数，多个物体最好一起渲染。那么DrawCall次数的优化有哪些方案呢？

DC Batching(DC批处理)

batch即批处理，DrawCall batching即DC的批处理，即把多次DrawCall合并成一次DrawCall的方案。

Dynamic Batching 动态批处理

Unity引擎对于使用相同材质的物体会自动进行批处理，相同材质意味着shader完全一样，这一部分主要是要注意那些破坏这一特性的人为因素，比如说：

1、批处理动态物体需要在每个顶点上进行一定的开销，所以动态批处理仅支持小于900顶点的网格物体，如果你的着色器使用顶点位置，法线和UV值三种属性，那么你只能批处理300顶点以下的物体(如果在这基础上还使用了UV2，则只能批处理180顶点以下的物体)；请注意：属性数量的限制可能会在将来进行改变。

2、使用不同的缩放比例的物体，unity将无法对这些物体进行批处理。比如(1,1,1)和(1,2,2)就不会动态批处理，但是(1,1,1)和(2,2,2)会动态批处理。

3、拥有lightmap的物体含有额外(隐藏)的材质属性，比如：lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理(除非他们指向lightmap的同一部分)。接受实时阴影的物体也不会批处理。

4、多通道的shader会中断批处理操作(为了达到特殊的渲染目的，可能某个物体要多遍渲染.这是就要多个通道)。

5、在脚本中动态地指定了物体的材质，也不会进行批处理。

Static Batching 静态批处理

动态批处理虽然是自动的，但是限制非常多，不小心就会打破批处理，所以unity在专业版中还提供了静态批处理，静态批处理要求是想批处理的物体一定是static的，静态的，不会改变位置和旋转角度以及缩放的，且必须材质一致。其原理是把物体的网格进行合并，变成一个静态的更大的网格物体，再使用一个统一的材质进行渲染。

知道了它的原理，它的某些坑就比较清晰了：

1、在一个平行光、环境光下，没有问题，但是如果你使用了多个平行光，点光源，聚光灯这种复杂的光源去照射物体，那么静态批处理就会被打断。(项目中就遇到过，因为两边有两排英雄模型，所以场景中使用了两个不同平行光，场景中勾选的static物体并没有被合并drawcall，经过一番折磨才找到原因)。

2、如果静态批处理前有一些物体共享了相同的网格，那么每一个物体都会有一个该网格的复制品(本来unity只会保留一份，但是静态批处理会生成新的一个大网格，所以会保留所有物体的网格，最后合并)，即一个网格会变成多个网格被发送给GPU。这样会造成内存的使用变大，需要注意这个问题，但是一般场景中使用相同网格的物体会比较少。

3、对于那些shader相同，纹理不同导致的不同材质无法进行批处理的物体(比如项目中的场景环境，基座，地面，其实都使用了unity自带的standard shader)可以通过纹理合并的方法来使得它们可以被静态批处理。这就引发了下面的事情：

BUS总线带宽

CPU完成一次DrawCall，除了需要发一个DrawCall的命令之外，还需要把内存中顶点数据、纹理贴图、shader参数通过bus总线拷贝到内存分配给GPU的显存之中，注意这是拷贝，不是指针传递，速度不快。如果一次drawcall传递的数据过大，带宽成为了瓶颈，那就会大大影响效率(其它的DrawCall无法出发，GPU又处于闲置)。这种情况最有可能出现在为了减少DrawCall，疯狂的合并纹理上。在项目中，UI的DrawCall调用占了很大一部分，也会最难优化的，为了减少drawcall ,我们把UI模块的静态部分(一些UI的底板，背景等不会发生变化的)全部合并成了一个纹理，最后导致了DrawCall下降了，但是帧率却也下降了，内存使用也增加了，原因就是这个。在项目中，不会同时出现的元素不要打包到一起，保证单张合并纹理不大于1024*1024一般就不会有问题了(王者荣耀最大纹理限制在了256*256)。

DrawCall的优化大概就是这些，优化的目标其实是往一个目标上靠，cpu的DrawCall命令刚刚好能被GPU消化，不要让CPU等待(带宽限制)，也不要让GPU闲置。如果即使做到了这个，应用帧率还是上不去，那么就只能去削减场景，做有损优化了。