前段时间本人转战unity手游，因为做者（Chwen）以前参与端游开发，有些端游的经验能够直接移植到手游，好比项目框架架构、代码设计、部分性能分析，而对于移动终端而言，CPU、内存、显卡甚至电池等硬件因素，以及网络等条件限制，对移动游戏开发的优化带来更大的挑战。 html
这里就以unity4.5x版本为例，对Unity的优化方案作一个总结，有些是项目遇到的，也有些是看到别人写的不错拿来分享，算做一个整理，后期也会持续更新。本优化从CPU、GPU和内存三个方面着手总结，这一篇先从CPU提及，整理一些针对CPU相关的优化建议。缓存
对CPU的优化主要是从drawcall、物理组件、GC（垃圾回收）、脚本等几个方面开展。性能优化
Drawcall是CPU向GPU发送绘制命令的接口调用。理论上每个不一样材质的物件须要渲染在屏幕上时，CPU都会调用图形API ( openGL or Diract3D ) 的Draw接口触发显卡进行绘制。网络
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函数 异步调用原理解析架构
在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会对不一样材质的对象进行排序，此时若是不一样材质的对象进入到两个相同材质的对象之间的话，会使相同材质的对象批次被打破。
批次先写到这，其实不少网上都有，不过有些没深刻讲解，也有些没给出解决办法，我就使用每一个方案时遇到的困难给出了本身的解决方案。其实批次还有很多研究的地方，以后想到了会继续更新。
延伸阅读：
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官方给出的一些优化建议：
引用请注明出处，http://www.cnblogs.com/chwen/p/4396515.html 很是感谢，随时交流。
后续更新，下一篇将是Unity优化——内存篇。