Unity性能优化：代码优化(CPU)

DrawCalls

{
就是cpu对图形绘制接口调用，CPU通过调用图形库接口，命令GPU进行渲染操作。一次调用就是一次DrawCall。所以如果调用次数多的话就会大量占据GPU的性能消耗。
优化方案：
{
1 使用Draw Call Batching，也就是描绘调用批处理。Unity在运行时可以将一些物体进行合并，从而用一个描绘调用来渲染他们。
2 通过把纹理打包成图集来尽量减少材质的使用。
3 尽量少的使用反光，阴影之类的，因为那会使物体多次渲染。
}
}

物理组件（Physics）

{
设置一个合适的Fixed Timestep
{
对于稳定的物理模拟来说，固定时间步长 (fixed time stepping) 非常重要。计算机不尽相同，不同的硬件配置在运行 unity 游戏时表现出来的性能也不同。因此，物理计算必须独立于游戏的帧速率进行。诸如碰撞检测和刚体 (rigidbody) 移动这样的物理计算是在独立于帧速率的离散固定时间步长中进行。这使不同电脑间或帧速率发生变化时模拟的一致性更强。例如，帧速率可能会由于屏幕上多个游戏同时进行或用户在后台执行另一应用程序而降低。
以下是固定时间步长的计算方法。在屏幕上绘制帧之前，unity 将固定时间提前一段固定增量时间，并在到达当前时间之前执行物理计算。这直接与固定时间步长 (fixed timestep)属性相关联。固定时间步长 (fixed timestep）的值越小，进行物理计算的频率越高。每秒的固定帧数的计算方法是，用 1 除以固定时间步长 (fixed timestep)。因此，1/0.02 = 50（帧每秒） 以及 1/0.05 = 20（帧每秒）。

简而言之，固定更新值越小，物理模拟越精确，但是 cpu 的负担也会更大。
}
不要使用网格碰撞器（mesh collider）
{
网格碰撞器利用一个网格资源并在其上构建碰撞器。对于复杂网状模型上的碰撞检测，它要比应用原型碰撞器精确的多。标记为凸起的（Convex ）的网格碰撞器才能够和其他网格碰撞器发生碰撞。但是这会导致大量的计算量，建议无需。
}

}

GC

{
GC是用来处理内存的，但的确增加的是CPU的开销。因此它的确能达到释放内存的效果，但代价更加沉重，会加重CPU的负担，因此对于GC的优化目标就是尽量少的触发GC。

GC是Mono运行时的机制，而非Unity3D游戏引擎的机制，所以GC也主要是针对Mono的对象来说的，而它管理的也是Mono的托管堆。托管堆就是 引用类型。比如类的实例，字符串，数组等等。而作为int，float，包括结构体struct其实都是值类型，它们会被分配在堆栈上而非堆上。所以类实例，字符串，数组是我们需要关注的。

GC触发时机：
1 堆的内存不足时，会自动调用GC
2 手动的调用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平台上也许会报错。
6 由于unity3D是c++写的但是代码又是用C#来作为脚本，所以脚本和底层的开销也是有的
{
尽量不要频繁用GetComponent。
善用OnBecameVisible()和OnBecameVisible(),来控制物体的update()函数的执行以减少开销。
用内建的数组，比如用Vector3.zero而不是new Vector(0, 0, 0);
善于使用ref关键字。值类型的参数，是通过将实参的值复制
}

}

}

传送门
优化相关前提
资源优化
渲染优化GPU
代码优化CPU