Unity3D优化之Optimizing Script Performance

Optimizing Script Performance  优化脚本性能

 

This page gives some general hints for improving script performance on iOS.

这一页给出了一些在iOS系统上增强脚本性能的一般方法。

 

Reduce Fixed Delta Time             减少固定增量时间

Use a fixed delta time value between 0.04 and 0.067 seconds (ie, 15-25 frames per second). You can change this in Edit->Project Settings->Time. This reduces the frequency with whichFixedUpdate is called and how often the physics engine has to perform collision detection and rigidbody updates. If you are using a rigidbody for the main character, you can enable interpolation in the Rigidbody Component to smooth out low fixed delta time steps.

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

 

Reduce GetComponent Calls             减少GetComponent的调用

Using GetComponent or built-in component accessors can have a noticeable overhead. You can avoid this by getting a reference to the component once and assigning it to a variable (sometimes referred to as "caching" the reference). For example, if you are using something like:

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

function Update () {

transform.Translate(0, 1, 0);

}

 

...you would get better performance by changing it to:-

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

 

var myTransform : Transform;
function Awake () {
   myTransform = transform;
}
function Update () {
    myTransform.Translate(0, 1, 0);
}

 

Avoid Allocating Memory      避免分配内存

You should avoid allocating new objects unless you really need to, since they increase the garbage collection overhead when they are no longer in use. You can often reuse arrays and other objects rather than allocate new ones and doing so will help to minimise garbage collection. Also, you should use structs instead of classes where possible. Struct variables are allocated from the stack like simple types rather than from the heap like object types. Since stack allocation is faster and involves no garbage collection, structs will often improve performance if they are fairly small in size. While large structs will still avoid allocation/collection overhead, they will incur a separate overhead due to "pass-by-value" copying and may actually be less efficient than the equivalent object classes.

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

 

Minimise the GUI             最小化GUI

The GUILayout functions are very convenient for automatic spacing of GUI elements. However, this automation naturally comes with a processing overhead. You can avoid some of this overhead by handling the layout manually using theGUI functions. Additionally, you can set a script'suseGUILayout variable to false in order to disable the layout phase completely:

使用GUILayout 函数可以很方便地将GUI元素进行自动布局。然而，这种自动化自然也附带着一定的处理开销。您可以通过手动的GUI功能布局来避免这种开销。此外，您也可以设置一个脚本的useGUILayout变量为 false来完全禁用GUI布局：

function Awake () {
    useGUILayout = false;
} 

 

Use iOS Script Call Optimization        使用iOS脚本调用优化功能

Most of the functions in theUnityEngine namespace are implemented in C/C++. Calling a C/C++ function from a Mono script involves a performance overhead. You can use iOS Script Call optimization (menu:Edit->Project Settings->Player) to save about 1 to 4 milliseconds per frame. The options for this setting are:-

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

      Slow and Safe - the default Mono internal call handling with exception support.

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

       

      Fast and Exceptions Unsupported - a faster implementation of Mono internal call handling. However, this doesn't support exceptions and so should be used with caution. An app that doesn't explicitly handle exceptions (and doesn't need to deal with them gracefully) is an ideal candidate for this option.

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

       

Optimizing Garbage Collection           优化垃圾回收

As mentioned above, it is best to avoid allocations as far as possible. However, given that they can't be completely eliminated, there are two main strategies you can use to minimise their intrusion into gameplay:-

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

 

Small heap with fast and frequent garbage collection

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

This strategy is often best for games that have long periods of gameplay where a smooth framerate is the main concern. A game like this will typically allocate small blocks frequently but these blocks will be in use only briefly. The typical heap size when using this strategy on iOS is about 200KB and garbage collection will take about 5ms on an iPhone 3G. If the heap increases to 1MB, the collection will take about 7ms. It can therefore be advantageous sometimes to request a garbage collection at a regular frame interval. This will generally make collections happen more often than strictly necessary but they will be processed quickly and with minimal effect on gameplay:

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

if (Time.frameCount % 30 == 0)
{
   System.GC.Collect();
} 

 

However, you should use this technique with caution and check the profiler statistics to make sure that it is really reducing collection time for your game.

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

 

Large heap with slow but infrequent garbage collection

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

This strategy works best for games where allocations (and therefore collections) are relatively infrequent and can be handled during pauses in gameplay. It is useful for the heap to be as large as possible without being so large as to get your app killed by the OS due to low system memory. However, the Mono runtime avoids expanding the heap automatically if at all possible. You can expand the heap manually by preallocating some placeholder space during startup (ie, you instantiate a "useless" object that is allocated purely for its effect on the memory manager):-

这一策略适合于那些内存分配 (和回收）相对不频繁，并且可以在游戏停顿期间进行处理的游戏。如果堆足够大，但还没有大到被系统关掉的话，这种方法是比较适用的。但是，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;
}

 

A sufficiently large heap should not get completely filled up between those pauses in gameplay that would accommodate a collection. When such a pause occurs, you can request a collection explicitly:-

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

System.GC.Collect();
Again, you should take care when using this strategy and pay attention to the profiler statistics rather than just assuming it is having the desired effect. 

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

 

备注：最近一直在研究Unity3D的性能优化问题，这段时间可能会多翻译这方面的文章，如有翻译不当之处还请多多指出。

原文地址：http://unity3d.com/support/documentation/Manual/iphone-Optimizing-Scripts.html