优化Unity游戏项目的脚本（上）
本文将由捷克独立游戏工作室Lonely Vertex的开发工程师Ondřej Kofroň，分享C#脚本的一系列优化方法，并提供改进Unity游戏性能的最佳实践。
在开发游戏时，我们遇到了游戏过程中偶尔出现延迟的问题。在使用Unity性能分析器进行分析后，我们问题主要来源于：未优化的着色器和未优化的C#脚本。
本文将主要介绍如何优化Unity游戏项目的C#脚本的方法。
寻找问题
Unity性能分析器是寻找造成卡顿脚本的最佳方法。我强烈建议直接在设备上对游戏进行性能分析，而不是在编辑器中进行性能分析。
本文中分享的游戏项目面向iOS，所以我们需要连接设备。如下图所示，设置Build Settings，然后性能分析器就会自动连接。
如果我们在网上搜索“Unity中的偶发卡顿”或类似关键词，你可能会发现大多数人建议重点处理垃圾回收。
每当停止使用某些对象即类的实例后，便会产生垃圾，然后会不定时运行Unity垃圾回收器来清理垃圾，取消分配相关的内存，这样的工作会占据大量时间，造成帧率降低现象。
如何在性能分析器中找到导致垃圾分配的脚本？
我们选中CPU Usage部分，如下选择Hierarchy视图，单击GC Alloc，从而根据GC Alloc的情况进行排序。
下图为垃圾回收的Profiler设置。
我们的目标是在游戏场景中，使GC Alloc栏的所有数值都为0。一个不错的做法是根据Time ms（即执行时间）排序记录，然后优化脚本，使其尽可能使用较少时间。
这对我们而言极为重要，因为游戏中有一个组件包含一个大型for循环，该循环要使用很多时间来执行，而且我们目前无法处理好这个循环，所以优化所有脚本的执行时间非常必要，我们需要为耗时较长的for循环节省一些执行时间，同时保持60fps。
根据性能分析的结果，我们将优化过程分为两个部分：
处理垃圾回收
减少执行时间
第一部分：处理垃圾回收
我们将关注处理垃圾回收的过程。这些内容是每位开发者都应该掌握的基础知识，也是我们平时对同步和合并请求，进行代码评审的重要部分。
规则1：不在Update方法中创建新对象
理想情况下，开发者在Update、FixedUpdate或LateUpdate方法中不应该使用New关键字，而是应该使用已有对象。
有时新对象创建过程会隐藏在一些Unity内部方法中，所以过程并不明显。
规则2：一次创建，多次重用
这条规则的意思是：要在Start方法和Awake方法中分配所有内容。这条规则和第一条类似，其实只是从Update方法移除new关键字的另一种方式。
开发者应该从Update方法移除有以下行为的代码：
创建新实例
寻找任意游戏对象
然后，将这些代码移动到Start方法或Awake方法中。
下面是我们进行的改动示例。
我们可以在Start方法分配List列表，在需要时使用Clear函数清空列表，并在任何位置重用这些内容。
//未优化的代码
private List<GameObject> objectsList;void Update()
{
objectsList = new List<GameObject>();
objectsList.Add(......)
}
//优化后的代码
private List<GameObject> objectsList;void Start()
{
objectsList = new List<GameObject>();
}
void Update()
{
objectsList.Clear();
objectsList.Add(......)
}进行存储和重用引用的过程如下面代码所示。
//未优化的代码
void Update()
{
var levelObstacles = FindObjectsOfType<Obstacle>();
foreach(var obstacle in levelObstacles) { ....... }}
//优化后的代码
private Object[] levelObstacles;
void Start()
{
levelObstacles = FindObjectsOfType<Obstacle>();}
void Update()
{
foreach(var obstacle in levelObstacles) { ....... }}
相同的规则也适用于FindGameObjectsWithTag等返回新数组的其它方法。
规则3：小心处理字符串，避免字符串连接
在涉及到垃圾分配的时候，字符串要特别注意。即使是基本的字符串操作，也可能产生大量垃圾。这是为什么呢？
因为字符串是无法改变的数组。这意味着，如果要把两个字符串连接起来，我们会创建新数组，而旧数组会成为垃圾。所以我们可以使用StringBuilder避免或最小化这类垃圾分配。
下面是改进该过程的示例。
//未优化的代码
void Start()
{
text = GetComponent<Text>();}
void Update()
{
text.text = "Player " + name + " has score " + score.toString();}
//优化后的代码
void Start()
{
text = GetComponent<Text>();
builder = new StringBuilder(50);}
void Update()
{
//StringBuilder为所有类型重载了Append方法
builder.Length = 0;
builder.Append("Player ");
builder.Append(name);
builder.Append(" has score ");
builder.Append(score);
text.text = builder.ToString();
｝
示例中的原代码没什么问题，但仍有很大的改进空间。我们发现，几乎整个字符串都可以视为静态，所以我们把字符串分为两个部分，放到两个UI.Text对象中。
第一个对象只包含静态文字“Player “ + name + “ has score “ ，可以在Start方法中指定。第二个对象包含每帧更新的Score数值，我们要使静态字符串完全是静态的，在Start方法或Awake方法中生成这类字符串。
经过改进，代码已经很好了，但是调用Int.ToString()、Float.ToString()等函数仍会有垃圾产生。
我们通过生成和预分配所有可能的字符串来解决该问题。这样可能听起来不是好方法，而且会消耗很多内存，但它完美满足了我们的需求，并彻底解决了这个问题。
我们最后得到可以使用索引直接访问的静态数组，从而获取表示数字的请求字符串。
public static readonly string[] NUMBERS_THREE_DECIMAL = {
"000", "001", "002", "003", "004", "005", "006",..........
规则4：缓存访问器返回的数值
这种方法可能很难使用，因为即使是简单的访问器也会产生垃圾。
//未优化的代码
void Update()
{
gameObject.tag;
//or
//或
gameObject.name;}
尝试避免在Update方法中使用访问器，只在Start方法中调用一次访问器，并缓存返回的数值。
通常，建议不在Update方法中调用任何字符串访问器或数组访问器。在多数情况下，我们只需要在Start方法中获取一次引用。
下面是未优化访问器代码的两个常见示例。
//未优化的代码
void Update()
{
//分配包含所有touches的新数组
Input.touches[0];}
//优化后的代码
void Update()
{
Input.GetTouch(0);}
//未优化的代码
void Update()
{
//返回新的字符串（垃圾），然后对比2个字符串
gameObject.Tag == "MyTag";}
//优化后的代码
void Update()
{
gameObject.CompareTag("MyTag");}
规则5：使用NonAlloc函数
对于特定Unity函数，我们可以找到不分配任何内存的替代函数。在我们的项目中，这些函数都和物理功能有关。我们在碰撞检测使用的函数如下。
Physics2D. CircleCast();
对于该函数，我们可以找到不分配任何内存的版本。
Physics2D. CircleCastNonAlloc();
许多其它函数都有类似的替代函数，因此请记得查看文档，了解函数是否有相应的NonAlloc版本。
规则6：不要使用LINQ
尽可能不要使用LINQ。也就是说，不要在任何经常执行的代码中使用LINQ。
虽然使用LINQ可以使代码更容易阅读，但在很多情况下，这类代码的性能和内存分配都非常糟糕。
规则7：一次创建，多次重用（续）
这次我们要讲的是对象池，如果你不了解对象池，请阅读教程：
https://learn.unity.com/tutorial/object-pooling
在我们的游戏中，有一种情况使用了对象池。我们有一个生成的关卡，里面充满了只在限定时间存在的障碍物，障碍物在玩家通过相应关卡部分后会消失。
在满足特定条件时，障碍物会从预制件进行实例化。相应的代码位于Update方法中，对于性能和执行时间而言，代码是非常低效的。
我们的解决方法是：生成40个障碍物组成的对象池，在需要时从对象池取用这些障碍物对象，在障碍物不再需要时，把障碍物对象返回到对象池。
规则8：注意装箱过程
装箱过程会生成垃圾。什么是装箱过程呢？
最常见的装箱过程是将数值类型，例如int，float，bool等传递到需要Object类型参数的函数时，所发生的过程。
下面是我们要在项目中处理的装箱过程。
我们在项目实现了自定义通信系统。每个信息可以包含数量不限的数据。该数据存储在字典中，字典的定义如下。
Dictionary data;
我们有设置函数（Setter），用来将数值设置到该字典中。
public Action SetAttribute(string attribute, object value)
{
data[attribute] = value;}
这里的装箱过程很明显，我们可以这样调用该函数。
SetAttribute("my_int_value", 12);
因此，这里的数值12进行装箱时，会产生垃圾。
我们的解决方法是：为每个基本类型使用单独的数据容器，之前的Object容器仅用于引用类型。
Dictionary data;
Dictionary dataBool;
Dictionary dataInt;
.......
为每个数据类型使用单独的设置函数。
SetBoolAttribute(string attribute, bool value)
SetIntAttribute(string attribute, int value)
然后实现所有设置函数，使它们调用相同的通用函数：
SetAttribute(ref Dictionary dict, string attribute, T value)
这样装箱过程就被我们移除了。如果你想了解更多细节，请阅读下面的文档：
https://docs.microsoft.com/zh-cn/dotnet/csharp/programming-guide/types/boxing-and-unboxing
规则9：小心循环代码
这条规则类似第1，2条规则。尽可能把所有不必要代码从循环中去掉，从而取得更好的性能和内存分配。
我们要尝试避免在Update方法中使用循环，但如果有这个需要，我们至少要在这种循环中避免出现内存分配。因此，不仅是针对Update方法，我们也要在循环代码中遵循前8条规则。
规则10：确保外部代码库不产生垃圾
如果发现部分垃圾由Asset Store资源商店下载的代码产生，我们有多个解决方法。但在我们进行逆向工程并调试前，请再次查看Asset Store资源商店的相应页面，代码库是否有进行更新。
在我们的项目中，我们使用的所有资源一直由资源的开发者进行维护，他们一直在进行性能更新，从而解决了我们的所有问题。
所以，一定要让项目使用的依赖保持更新。如果遇到没有维护的代码库，建议放弃这类代码库。
小结
由于篇幅限制，本文介绍了优化Unity游戏项目的C#脚本的第一部分处理垃圾回收，下篇我们将分享如何将执行时间减少，敬请期待!
