Unity 脚本优化的那些坑

前言

在很长一段时间里，Unity项目的开发者的优化指南上基本都会有一条关于使用GetComponent方法获取组件的条目（例如14年我的这篇博客《深入浅出聊Unity3D项目优化：从Draw Calls到GC》）。有时候还会发展为连一些Unity内部对象的属性访问器都要小心使用的注意事项，记得曾经有一段时间我们的项目组也会严格要求把例如transform、gameobject之类的属性访问器进行缓存使用。这其中的确有一些措施是有道理的，但很多朋友却也是知其然而不知其所以然，朦胧之间似乎有一个印象，进而成为习惯。那么本文就来聊聊Unity优化这个题目中偶尔会被误解的内容吧。

来自官方的建议

本文主要是关于Unity脚本优化的，而脚本和引擎打交道的一个常见情景便是使用GetComponent之类的方法， 接触过Unity的朋友大都知道要将GetComponent的结果进行缓存使用。不过很多人的理由是：

使用GetComponent会造成GC，从而影响效率。

所以从Unity官方的手册来寻找关于GetCompnent的线索是最好的途径。的确，2011年的3.5.3版本的官方手册就已经建议减少使用GetCompnent方法来获取组件了，同时建议我们使用变量缓存获取的组件。

Reduce GetComponent Calls
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).

但是，我们可以发现手册上只说了频繁的调用GetComponent会导致CPU的开销增加，但是并没有提到GC的问题。所以，为了验证GetComponent到底会导致哪些性能上的问题，我们可以做几个小测试。

和GC无关的性能优化

众所周知，GetComponent有三个重载版本，分别是：

• GetComponent()
• GetComponent(typeof(T))
• GetComponent(string)

所以，测试的第一步就是先确定一个效率最高的重载版本，之后再去检查它们各自引起的堆内存分配。

“效率之王”

为此，我们在5.X版本的Unity中准备一个空白的场景并实现一个简单的计时器，之后就可以开始测试了。

using System;
using System.Diagnostics;

/// <summary>
/// 简易的计时类
/// </summary>