C#程序员整理的Unity 3D笔记（四）：脚本优化 15 mins read

1. 尽量避免每帧处理

比如：

function Update() { DoSomeThing(); }

可改为每5帧处理一次：

function Update() { if(Time.frameCount % 5 == 0) { DoSomeThing(); } }

2. 定时重复处理用 InvokeRepeating 函数实现

比如，启动0.5秒后每隔1秒执行一次 DoSomeThing 函数：

function Start() { InvokeRepeating("DoSomeThing", 0.5, 1.0); }

3. 优化 Update, FixedUpdate, LateUpdate 等每帧处理的函数

Update() 和 FixedUpdate()在游戏中都会在更新的时候自动循环调用。

但是Update是在每次渲染新的一帧的时候才会调用，也就是说，这个函数的更新频率和设备的性能有关以及被渲染的物体（可以认为是三角形的数量）。在性能好的机器上可能fps 30，差的可能小些。这会导致同一个游戏在不同的机器上效果不一致，有的快有的慢。因为Update的执行间隔不一样了。

而FixedUpdate，是在固定的时间间隔执行，不受游戏帧率的影响。有点想Tick。所以处理Rigidbody的时候最好用FixedUpdate。

Unity中Update和Lateupdate的区别。Lateupdate和Update每一祯都被执行，但是执行顺序不一样，先执行Updatee然后执行lateUpdate。

如果你有两个脚本JS1、JS2，两个脚本中都有Update()函数, 在JS1中有 lateUpdate ,JS2中没有。那么 lateUpdate 函数会等待JS1、JS2两个脚本的Update()函数 都执行完后才执行。也就是说, 如果现在有100个脚本，分别有100个 Update()函数，其中只有一个LateUpdate，那么在同一祯中，等待100个Update()执行完后，才执行这一个lateUpdate()。

函数里面的变量尽量在头部声明。

比如：

function Update() { var pos: Vector3 = transform.position; }

可改为

private var pos: Vector3; function Update(){ pos = transform.position; }

4. 主动回收垃圾

给某个 GameObject 绑上以下的代码：

function Update() { if(Time.frameCount % 50 == 0) { System.GC.Collect(); } }

5. 运行时尽量减少 Tris 和 Draw Calls

预览的时候，可点开 Stats，查看图形渲染的开销情况。特别注意 Tris 和 Draw Calls 这两个参数。

一般来说，要做到：

Tris 保持在 7.5k 以下

Draw Calls 保持在 20 以下

Tris：Game 视窗右上角 Stat 里面的Tris 记录场景内的所有三角面数

Draw Calls：

一个简单的openGL的绘图次序是：设置颜色→绘图方式→顶点座标→绘制→结束。

每帧都会重复以上的步骤。这就是一次draw call

如果有两个model，那么需要

设置颜色→绘图方式→顶点座标A→绘制→结束。

设置颜色→绘图方式→顶点座标B→绘制→结束。

两次draw calls;

也就是说在openGl绘制前，如果色彩通道(color filter)，绘图方式(shader)，顶点座标（model）不同的情况下draw calls就会增加。

对openGl来说绘制参数（状态值）的变更要比绘制大量的顶点更耗费cpu。

所谓高速绘图就是，在尽量不改变openGl状态值的情况下，用一次draw call完成所有绘制。

比如上面的例子：

设置颜色→绘图方式→顶点座标A＋顶点座标B→绘制→结束。

就要更加有效率。

6. 压缩 Mesh

导入 3D 模型之后，在不影响显示效果的前提下，最好打开 Mesh Compression。

Off, Low, Medium, High 这几个选项，可酌情选取。

7. 避免大量使用 Unity 自带的 Sphere 等内建 Mesh

Unity 内建的 Mesh，多边形的数量比较大，如果物体不要求特别圆滑，可导入其他的简单3D模型代替。

8. 优化数学计算

比如，如果可以避免使用浮点型(float)，尽量使用整形(int)，尽量少用复杂的数学函数比如 Sin 和 Cos 等等

9. 减少固定增量时间

将固定增量时间值设定在0.04-0.067区间（即，每秒15-25帧）。您可以通过Edit->Project Settings->Time来改变这个值。这样做降低了FixedUpdate函数被调用的频率以及物理引擎执行碰撞检测与刚体更新的频率。如果您使用了较低的固定增量时间，并且在主角身上使用了刚体部件，那么您可以启用插值办法来平滑刚体组件。

10. 减少GetComponent的调用

使用 GetComponent或内置组件访问器会产生明显的开销。您可以通过一次获取组件的引用来避免开销，并将该引用分配给一个变量（有时称为"缓存"的引用）。例如，如果您使用如下的代码：

function Update () {

transform.Translate(0, 1, 0);

}

通过下面的更改您将获得更好的性能：

var myTransform : Transform;

function Awake () {

myTransform = transform;

}

function Update () {

myTransform.Translate(0, 1, 0);

}

11. 避免分配内存

您应该避免分配新对象，除非你真的需要，因为他们不再在使用时，会增加垃圾回收系统的开销。您可以经常重复使用数组和其他对象，而不是分配新的数组或对象。这样做好处则是尽量减少垃圾的回收工作。同时，在某些可能的情况下，您也可以使用结构（struct）来代替类（class）。这是因为，结构变量主要存放在栈区而非堆区。因为栈的分配较快，并且不调用垃圾回收操作，所以当结构变量比较小时可以提升程序的运行性能。但是当结构体较大时，虽然它仍可避免分配/回收的开销，而它由于"传值"操作也会导致单独的开销，实际上它可能比等效对象类的效率还要低。

12. 使用iOS脚本调用优化功能

UnityEngine 命名空间中的函数的大多数是在 C/c + +中实现的。从Mono的脚本调用 C/C++函数也存在着一定的性能开销。您可以使用iOS脚本调用优化功能（菜单：Edit->Project Settings->Player）让每帧节省1-4毫秒。此设置的选项有：

Slow and Safe – Mono内部默认的处理异常的调用

Fast and Exceptions Unsupported –一个快速执行的Mono内部调用。不过，它并不支持异常，因此应谨慎使用。它对于不需要显式地处理异常（也不需要对异常进行处理）的应用程序来说，是一个理想的候选项。

13. 优化垃圾回收

如上文所述，您应该尽量避免分配操作。但是，考虑到它们是不能完全杜绝的，所以我们提供两种方法来让您尽量减少它们在游戏运行时的使用：

如果堆比较小，则进行快速而频繁的垃圾回收

这一策略比较适合运行时间较长的游戏，其中帧率是否平滑过渡是主要的考虑因素。像这样的游戏通常会频繁地分配小块内存，但这些小块内存只是暂时地被使用。如果在iOS系统上使用该策略，那么一个典型的堆大小是大约 200 KB，这样在iPhone 3G设备上，垃圾回收操作将耗时大约 5毫秒。如果堆大小增加到1 MB时，该回收操作将耗时大约 7ms。因此，在普通帧的间隔期进行垃圾回收有时候是一个不错的选择。通常，这种做法会让回收操作执行的更加频繁（有些回收操作并不是严格必须进行的），但它们可以快速处理并且对游戏的影响很小：

if (Time.frameCount % 30 == 0)

{

System.GC.Collect();

}

但是，您应该小心地使用这种技术，并且通过检查Profiler来确保这种操作确实可以降低您游戏的垃圾回收时间

如果堆比较大，则进行缓慢且不频繁的垃圾回收

这一策略适合于那些内存分配 (和回收）相对不频繁，并且可以在游戏停顿期间进行处理的游戏。如果堆足够大，但还没有大到被系统关掉的话，这种方法是比较适用的。但是，Mono运行时会尽可能地避免堆的自动扩大。因此，您需要通过在启动过程中预分配一些空间来手动扩展堆（ie，你实例化一个纯粹影响内存管理器分配的"无用"对象）：

function Start() {

var tmp = new System.Object[1024];

// make allocations in smaller blocks to avoid them to be treated in a special way, which is designed for large blocks

for (var i : int = 0; i < 1024; i++)

tmp[i] = new byte[1024];

// release reference

tmp = null;

}

游戏中的暂停是用来对堆内存进行回收，而一个足够大的堆应该不会在游戏的暂停与暂停之间被完全占满。所以，当这种游戏暂停发生时，您可以显式请求一次垃圾回收：

System.GC.Collect();

另外，您应该谨慎地使用这一策略并时刻关注Profiler的统计结果，而不是假定它已经达到了您想要的效果。