[Unity优化] Unity CPU性能优化

　　前段时间本人转战unity手游，由于作者（Chwen）之前参与端游开发，有些端游的经验可以直接移植到手游，比如项目框架架构、代码设计、部分性能分析，而对于移动终端而言，CPU、内存、显卡甚至电池等硬件因素，以及网络等条件限制，对移动游戏开发的优化带来更大的挑战。

　　这里就以unity4.5x版本为例，对Unity的优化方案做一个总结，有些是项目遇到的，也有些是看到别人写的不错拿来分享，算作一个整理，后期也会持续更新。本优化从CPU、GPU和内存三个方面着手总结，这一篇先从CPU说起，整理一些针对CPU相关的优化建议。

　　对CPU的优化主要是从drawcall、物理组件、GC（垃圾回收）、脚本等几个方面开展。

1. Drawcall 的优化

• 什么是Drawcall?

　　Drawcall是CPU向GPU发送绘制命令的接口调用。理论上每一个不同材质的物件需要渲染在屏幕上时，CPU都会调用图形API ( openGL or Diract3D ) 的Draw接口触发显卡进行绘制。

• 为什么优化Drawcall?

　　Drawcall对硬件和驱动而言，要求大量设置状态（使用哪些顶点、哪些shader等）和状态转换。而Drawcall最大的消耗在于：如果每次drawcall只提交少量的数据将导致CPU瓶颈，CPU无法将GPU填满。Drawcall对GPU的耗费在于硬件一直等待CPU提交数据，而无法得到有效利用。GPU大量的时间耗费在不断切换状态和正确性检测上。 GPU在Draw Call之间，为了防止前后Draw的依赖关系造成绘制错误或者资源竞用，一般会在Draw Call后Flush整个流水线，小粒度的Draw Call对GPU流水线来说是个很大的浪费。（这个问题在D3D老版本存在，在新版D3D11中得到改善。）实际上unity官方指出，Drawcall数量的降低并非重点，重点是减少批次的数量，Drawcall优化实际上是对批次数量的优化。 
　　延伸阅读：
　　· why are draw calls expensive? — Stack Overflow
　　· Direct3D Draw函数 异步调用原理解析

• 如何优化Drawcall？

　　在Unity中对Drawcall的优化有以下几个策略：Drawcall batching，合并打包图集，减少光照和阴影以及遮挡剔除和视锥剔除等。以下分别谈一下各个策略的优缺点。

　　1.1. Drawcall Batching

　　Unity中对Drawcall的批次有两种：静态批次(static batching)和动态批次(dynamic batching)。但不论静态批次还是动态批次都要求对象的材质是共享的，即不同材质的对象是无法进行批次的。而且要注意的一点：如果在脚本中调用材质时，使用Renderer.material会造成材质的拷贝，而使用Renderer.sharedMaterial来调用则不会拷贝材质。

　　1.1.1. 静态批次 Drawcall static batching

　　场景中的多个物件如果是不移动的（包括位置、缩放、旋转等），并且共享同一材质，比如地形、建筑、花盆等，那么可以选择采用静态批次。静态批次只需要在Inspector勾选static选项即可。静态批次需要注意的是，unity会将进行批次的多个对象合并成一个大的对象，也会导致内存损耗，有时候要避免太多对象静态批次造成的内存过高。这也表明，优化并非绝对做好某一方面，而是平衡各个硬件的瓶颈和效率，选择相对适中的方案。

　　1.1.2. 动态批次 Drawcall dynamic batching

　　动态批次是运动的物件在unity中也可以进行批次渲染，动态批次不需要手动设置，是unity自动进行的，但是这里有诸多陷阱和约束，开发者需要遵守一定的限制条件才能享受动态批次的好处。

　　根据unity官方文档描述：

　　1) . 动态批次是逐顶点处理的，因此仅对少于900个顶点的mesh有效。如果shader使用了顶点位置，法线和UV那么仅支持低于300顶点的mesh，而如果shader使用了顶点位置，法线、UV0、UV1和切向量，则之多仅支持180顶点。

　　2) . 缩放问题

　　缩放对于批次是有影响的，这里涉及到一个统一缩放和非统一缩放的概念。统一缩放即为三轴同比例缩放，比如（1,1,1），（2,2,2）（5,5,5）... 非统一缩放即为三轴不同比例缩放，如（1,2,1）（2,1,1）（1,2,3）等等。

　　Unity对统一缩放的对象是不进行动态批次的，而对非同一缩放的对象是可以进行动态批次的。这里有点诡异，查阅了一些资料，解释如下：

　　对于非同一缩放的物件，unity将其mesh进行了复制，因此即便是从相同物件进行的非同一缩放的两个对象是两份mesh；对统一缩放的对象来说，unity不对mesh进行复制，而是使用同一mesh进行缩放，此时复制mesh来进行批次渲染是不值得的，但是对于非统一缩放的对象，既然已经复制了mesh（不是为了批次，而是其他原因决定复制mesh）,那么进行批次是顺带实现的。

（参考 Dynamic Batching and Scale ——unity3d answers  ）

　　3) . 使用了不同的材质，即便实质上是相同的（比如两个一模一样的材质），也不会进行批次。

　　4) . 拥有lightmap的物件含有额外的材质属性，比如lightmap偏移和缩放系数等，所以拥有lightmap的物件不能批次。

　　5) . 多通道的shader会妨碍批处理操作，接受实时阴影的物件无法批次。

　　

　　注意： unity渲染是有顺序的，渲染排序有可能打断动态批次。

　　例如：

　　场景中有物件ABC，假设AB使用同一材质1，C使用材质2.那么drawcall有可能是2个，也有可能是3个。

　　如果顺序为：

　　　　1.渲染A，使用材质1

　　　　2.渲染B，使用材质1

　　　　3.渲染C，使用材质2

　　那么drawcall是2个，AB进行了动态批次。

　　如果顺序为：

　　　　1.渲染A，使用材质1

　　　　2.渲染C，使用材质2

　　　　3.渲染B，使用材质1

　　那么drawcall就是3个，AB的批次被C打断了。

渲染顺序跟什么有关呢？

首先根据物件到摄像机的距离，进行远处物件先渲染近处物件后渲染。相同材质的物件尽量在一层，不要让不同材质的物件进入这一层。如果无法保证这一点，那么还有一种方法：修改shader中渲染队列值。即打开shader 将subshader中的tag｛｝中queue 修改为小于2500的值。

渲染队列小于等于2500时，unity认为其是不透明的，对于不同材质但z值相同对象，unity不对其进行排序，这样能保证相同材质的多个对象能是一个批次，不同材质的对象如果进入两个相同材质的对象之间，不会打破批次；

渲染队列大于2500时，unity会对不同材质的对象进行排序，此时如果不同材质的对象进入到两个相同材质的对象之间的话，会使相同材质的对象批次被打破。

　　批次先写到这，其实很多网上都有，不过有些没深入讲解，也有些没给出解决办法，我就使用每个方案时遇到的困难给出了自己的解决方案。其实批次还有不少研究的地方，之后想到了会继续更新。

　　延伸阅读： 　　

　　· Unity -Draw Call Batching

　　· Unity Drawcall 优化手记

1.2. 合并图集

　　其实合并图集也是利用了Unity的Drawcall batching。将多个纹理进行打包成图集是为了减少材质，这样多个对象共享一个材质，并进而使用同一个纹理和shader，触发unity的动态批次。图集打包工具有很多，Asset store中也可以搜到不少，比如Texture Packer Free 、 DrawCall Optimizer(收费) Mesh Baker Free 等等都可以将贴图打包合并。

　　但是合并图集也有缺点，合并贴图时应该注意选择同时出现在屏幕的对象贴图进行合并。如果不能做到这一点，那么合并图集可能起到反作用，即渲染一个对象需要加载过多无用贴图，造成内存占用率升高。我的项目这个方案也是采用之后又弃用的，因为归类同时出现在屏幕的贴图并非易事！

　　1.3. 光照和阴影

　　实时光照和阴影可能增加Drawcall，带有光源计算的shader材质会因为光照产生多个Drawcall。使用灯光会打断Drawcall batching，尽量使用烘焙灯光贴图等技巧来实现灯光效果。

　　延伸阅读：

　　　　· Forward Rendering Path Details

　　　　· Light Troubleshooting and Performance

　　1.4. 遮挡剔除、视锥剔除

　　这两个Unity提供的剔除方案，出视野之后应剔除对象渲染。

　　2. 物理组件

　　3. GC　

　　GC是unity自动回收内存垃圾的回收器，这虽没有内存泄漏的风险，但是过多的垃圾回收会让CPU高负荷。这里就要避免不必要的内存申请和释放。可以在某个脚本定时清理垃圾，如void update（）｛if（Time.framecount %5 ==0）System.GC.collect();｝

　　有以下几点需要注意：

　　3.1.  字符串的拼接会产生临时字符串内存，移除代码中的字符串拼接，改用string.format，或stringbuilder，这没测。

　　3.2. 用for代替foreach，foreach每次迭代产生24字节垃圾内存。100次循环就是2.4kB.

　　3.3. 对象标签tag比较采用comparetag，不要用tag=="mytag"这样。

　　3.4. 使用对象池。对象克隆也是调用new，因此对于可以循环利用的对象要采用对象池，比如子弹、特效、宝石等等。

　　对象池使用时要注意一点：如果对象上挂了脚本，那么数据需要每次进行初始化或对象回收的时候进行重置，否则下次再利用的对象脚本可能存留上次的数据，那极有可能出bug。

　　3.5. 尽量使用struct而非class，因为struct是栈区，class是堆区。

　　GC涉及到内存，详细内容会在内存篇展开。

4. 脚本

　　脚本中如果在update 函数中调用了Getcomponent等接口，最好将组件缓存。

　　在update中的处理如果允许，尽量隔多帧处理一次。

　　如:将update() {DoSth();} 修改为：update() { if(Time.framecount %5 == 0) DoSth();}

　　其实脚本的优化主要就是针对update中复杂和耗费的逻辑进行优化，其次对于游戏进行中的卡顿，可以修改逻辑，使用预加载方式，将游戏进行中的对象在开始前一次性加载到内存。

　Unity官方给出的一些优化建议：

　　1.PC平台的话保持场景中显示的顶点数少于200K~3M，移动设备的话少于10W，一切取决于你的目标GPU与CPU。

　　2.如果你用U3D自带的SHADER，在表现不差的情况下选择Mobile或Unlit目录下的。它们更高效。

　　3.尽可能共用材质。

　　4.将不需要移动的物体设为Static，让引擎可以进行其批处理。

　　5.尽可能不用灯光。

　　6.动态灯光更加不要了。

　　7.尝试用压缩贴图格式，或用16位代替32位。

　　8.如果不需要别用雾效(fog)

　　9.尝试用OcclusionCulling,在房间过道多遮挡物体多的场景非常有用。若不当反而会增加负担。

　　10.用天空盒去“褪去”远处的物体。

　　11.shader中用贴图混合的方式去代替多重通道计算。

　　12.shader中注意float/half/fixed的使用。

　　13.shader中不要用复杂的计算pow,sin,cos,tan,log等。

　　14.shader中越少Fragment越好。

　　15.注意是否有多余的动画脚本，模型自动导入到U3D会有动画脚本，大量的话会严重影响消耗CPU计算。

　　16.注意碰撞体的碰撞层，不必要的碰撞检测请舍去。

　　

　　延伸阅读:

　　　　· Optimizing Graphics Performance  

　　　　· [Unity3D]图形渲染优化、渲染管线优化、图形性能优化

　　　　· 深入浅出聊优化：从Draw Calls到GC

引用请注明出处，http://www.cnblogs.com/chwen/p/4396515.html 非常感谢，随时交流。

后续更新，下一篇将是Unity优化——内存篇。