Unity 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优化实际上是对批次数量的优化。 

如何优化Drawcall？

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

　　1. Drawcall Batching

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

　　1.1. 静态批次 Drawcall static batching