Unity-CPU优化

CPU优化

一.DrawCalls(优先考虑)
drawcall是啥？其实就是对底层图形程序（比如：OpenGL ES)接口的调用，以在屏幕上画出东西。所以，是谁去调用这些接口呢？CPU。

1. 使用Draw Call Batching
   自由度很高，限制很少，坏消息是可能会占用更多的内存
   而且经过静态批处理后的所有物体都不可以再移动了。
   batching的物体必须使用相同材质；
   静态bathing:只要这些物体不移动，并且拥有相同的材质，静态批处理就允许引擎对任意大小的几何物体进行批处理操作来降低描绘调用。
2. 通过把纹理打包成图集来尽量减少材质的使用。
3. 尽量少的使用反光啦，阴影之类的，这些会使物体多次渲染。

二.减少GC触发
GC触发:首先当然是我们的堆的内存不足时，会自动调用GC。其次呢，作为编程人员，我们自己也可以手动的调用GC。

1. 字符串连接的处理。因为将两个字符串连接的过程，其实是生成一个新的字符串的过程。而之前的旧的字符串自然而然就成为了垃圾。而作为引用类型的字符串，其空间是在堆上分配的，被弃置的旧的字符串的空间会被GC当做垃圾回收。
2. 尽量不要使用foreach，而是使用for。foreach其实会涉及到迭代器的使用，而据传说每一次循环所产生的迭代器会带来24 Bytes的垃圾。那么循环10次就是240Bytes。
3. 不要直接访问gameobject的tag属性。比如if (go.tag == “human”)最好换成if (go.CompareTag (“human”))。因为访问物体的tag属性会在堆上额外的分配空间。如果在循环中这么处理，留下的垃圾就可想而知了。
4. 使用“池”，以实现空间的重复利用。
5. (不知道是啥看不懂)最好不用LINQ的命令，因为它们会分配临时的空间，同样也是GC收集的目标。而且我很讨厌LINQ的一点就是它有可能在某些情况下无法很好的进行AOT编译。比如“OrderBy”会生成内部的泛型类“OrderedEnumerable”。这在AOT编译时是无法进行的，因为它只是在OrderBy的方法中才使用。所以如果你使用了OrderBy，那么在IOS平台上也许会报错。

三.代码质量

1. 不要调用GetComponent，保存成成员引用；耗时高
2. 2.使用OnBecameVisible()和OnBecameVisible(),来控制物体的update()函数的执行以减少开销。
3. 3.使用内建的数组，比如用Vector3.zero而不是new Vector3(0, 0, 0);
4. 4.对于方法的参数的优化：善于使用ref关键字。(减少复制数值)
5. 5.优化数学计算。比如，如果可以避免使用浮点型(float)，尽量使用整形(int)，尽量少用复杂的数学函数比如 Sin 和 Cos 等等。

下面是方法需要的耗时时间

OnBecameVisible() : 这个的意思是当物体在/进入摄像机会调用一次，类似触发器OnTriggerEnter();
OnBecameInvisible() : 这个的意思是当物体离开摄像机会调用一次，类似触发器OnTriggerExit();

四.物理组件

1. 设置一个合适的Fixed Timestep。
2. 不要使用网格碰撞器（mesh collider）；
3. 从性能优化的角度考虑，物理组件能少用还是少用为好。

网格碰撞因为实在是太复杂了。网格碰撞器利用一个网格资源并在其上构建碰撞器。对于复杂网状模型上的碰撞检测，它要比应用原型碰撞器精确的多。手机游戏自然无需这种性价比不高的东西。