Notifications
Article
优化Unity游戏项目的脚本
Updated 12 days ago
1.2 K
12
本文将由捷克独立游戏工作室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; //或 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<string, object> data;
我们有设置函数(Setter),用来将数值设置到该字典中。
public Action SetAttribute(string attribute, object value) { data[attribute] = value; }
这里的装箱过程很明显,我们可以这样调用该函数。
SetAttribute("my_int_value", 12);
因此,这里的数值12进行装箱时,会产生垃圾。
我们的解决方法是:为每个基本类型使用单独的数据容器,之前的Object容器仅用于引用类型。
Dictionary<string, object> data; Dictionary<string, bool> dataBool; Dictionary<string, int> dataInt; .......
为每个数据类型使用单独的设置函数。
SetBoolAttribute(string attribute, bool value) SetIntAttribute(string attribute, int value)
然后实现所有设置函数,使它们调用相同的通用函数:
SetAttribute<T>(ref Dictionary<string, T> 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资源商店的相应页面,代码库是否有进行更新。
在我们的项目中,我们使用的所有资源一直由资源的开发者进行维护,他们一直在进行性能更新,从而解决了我们的所有问题。
所以,一定要让项目使用的依赖保持更新。如果遇到没有维护的代码库,建议放弃这类代码库。

第二部分:减少脚本的执行时间

如果代码不经常调用,这部分提到的一些规则可能不会产生明显的作用。在我们的项目中,我们有一个每帧执行的大型循环,因此在该代码中,即使做很小的改动,也会产生很明显的作用。
如果使用方法不当或在不合适的情形下使用,部分改动可能会产生更差的执行时间。每次对代码进行优化方面的改动后,要记得查看性能分析器,确保改动有理想的效果。
这部分的一些规则可能会导致代码变得难以理解,甚至可能会破坏最佳编程实践。这部分的许多规则和第一部分的规则有所重复。和不分配垃圾的代码相比,垃圾分配代码通常有更差的执行效果,建议在阅读这部分内容之前,先仔细阅读本文的第一部分。
规则1:使用合适的执行顺序
将代码从FixedUpdate,Update和LateUpdate方法转移到Start和Awake方法中。虽然这听起来不现实,但如果深入分析代码,你会发现有数百行代码可以移动到仅执行一次的方法中。
在我们的项目中,这类代码通常和下面操作有关:
  • GetComponent<> Calls
  • 每帧返回相同结果的计算过程
  • 重复实例化相同的对象,通常这类对象为List列表
  • 寻找某些游戏对象
  • 获取对Transform的引用,使用其它访问器
下面是我们从Update方法移动到Start方法的代码。
//将GetComponent留在Update方法必须有很好的理由 gameObject.GetComponent<LineRenderer>(); gameObject.GetComponent<CircleCollider2D>(); //每帧返回相同结果的计算过程示例 Mathf.FloorToInt(Screen.width / 2); var width = 2f * mainCamera.orthographicSize * mainCamera.aspect; var castRadius = circleCollider.radius * transform.lossyScale.x; var halfSize = GetComponent<SpriteRenderer>().bounds.size.x / 2f; //寻找对象 var levelObstacles = FindObjectsOfType<Obstacle>(); var levelCollectibles = FindGameObjectsWithTag("COLLECTIBLE"); //引用 objectTransform = gameObject.transform; mainCamera = Camera.main;
规则2:仅在需要时运行代码
在我们的项目中,这种情况大多和更新UI的脚本有关。下面是我们修改的代码实现,它们作用是显示关卡中“可收集物品”的当前状态。
//未优化的代码 Text text; GameState gameState;void Start() { gameState = StoreProvider.Get<GameState>(); text = GetComponent<Text>(); }void Update() { text.text = gameState.CollectedCollectibles.ToString(); }
因为我们在每关中只有少量可收集物品,每帧都修改UI文本不会产生很大作用,因此我们仅在实际数字变化时改变文本。
//优化后的代码 Text text; GameState gameState; int collectiblesCount; void Start() { gameState = StoreProvider.Get<GameState>(); text = GetComponent<Text>(); collectiblesCount = gameState.CollectedCollectibles; } void Update() { if(collectiblesCount != gameState.CollectedCollectibles) { //该代码每关只运行5次 collectiblesCount = gameState.CollectedCollectibles; text.text = collectiblesCount.ToString(); } }
这样的的代码性能会更好,特别在代码作用不只是简单的UI变化时,会有更好的效果。如果想要更复杂的解决方法,建议通过使用C#事件实现观察者设计模式。
但对于对我们而言还不够好,我们希望实现完全通用的解决方案,因此我们创建了在Unity实现Flux架构的代码库。
这样可以实现非常简单的解决方案,我们把所有游戏状态都存储到“Store”对象,在任何状态发生改变时,所有UI元素和其它组件都会得到通知,然后它们会对改变做出反应,整个过程不需要在Update方法使用任何代码。
规则3:小心循环代码
这条规则和第一部分的第9条规则相同。如果代码中有循环会迭代大量元素,请使用本文第二个部分提到的所有规则,来改进循环代码的性能。
规则4:使用For循环代替Foreach循环
Foreach循环很容易编写,但是执行起来却很复杂。Foreach循环在内部会使用枚举器来迭代特定数据集,并返回数值。
这比在For循环迭代索引复杂很多。因此在我们的项目中,只要可以的话,我们都会把Foreach循环改为For循环,如下所示。
//未优化的代码 foreach (GameObject obstacle in obstacles) //优化后的代码 var count = obstacles.Count; for (int i = 0; i < count; i++) { obstacles[i]; }
在我们的大型For循环中,这项改动的效果非常明显。通过使用简单的For循环,我们实现了速度比原来快2倍的代码。
规则5:使用Array数组代替List列表
在代码中,我们发现大多数列表有固定的长度,或是可以计算出最大成员数量。因此我们使用数组重新实现了这些列表,在特定情况下,可以在迭代数据的时候得到原先2倍的速度。
在某些情况下,我们无法避免使用列表或其它复杂的数据结构。常见的情况是:需要经常添加或移除元素的时候,使用列表的效果更好的时候。通常来说,我们会对固定大小的列表使用数组。
规则6:使用Float运算替代Vector运算
Float运算和Vector运算的区别不是很明显,除非像我们一样进行上千次运算,因此对我们来说,这项改动的性能提升效果非常明显。
改动如下所示。
Vector3 pos1 = new Vector3(1,2,3); Vector3 pos2 = new Vector3(4,5,6); //未优化的代码 var pos3 = pos1 + pos2; //优化后的代码 var pos3 = new Vector3(pos1.x + pos2.x, pos1.y + pos2.y, ......); Vector3 pos1 = new Vector3(1,2,3); //未优化的代码 var pos2 = pos1 * 2f; //优化后的代码 var pos2 = new Vector3(pos1.x * 2f, pos1.y * 2f, ......);
规则7:寻找对象属性
一定要考虑是否必须使用GameObject.Find()方法。该方法会产生很大开销,占据大量时间。最好不在Update方法中使用GameObject.Find()方法。
我们发现大多数GameObject.Find()调用可以替换为编辑器中直接引用的关联,这是更好的方法。
//未优化的代码 GameObject player; void Start() { player = GameObject.Find("PLAYER"); } //优化后的代码 //在编辑器中把该引用指定给玩家对象 [SerializeField] GameObject player; void Start() { }
如果无法这样处理,开发者至少应该考虑使用Tag标签,通过使用GameObject.FindWithTag,根据标签来找到对象。
总体上说,三种方法的优先级为:直接引用 > GameObject.FindWithTag() > GameObject.Find()。
规则8:只处理相关对象
在我们的项目中,该规则对使用RayCasts和CircleCasts等函数的碰撞检查功能有明显的效果。我们不必在代码中检测所有碰撞并决定哪些对象是相关的,只需把游戏对象都移动到合适的图层即可,这样我们可以只对相关对象计算碰撞。
下面是示例代码。
//未优化的代码 void DetectCollision() { var count = Physics2D.CircleCastNonAlloc( position, radius, direction, results, distance); for (int i = 0; i < count; i++) { var obj = results[i].collider.transform.gameObject; if(obj.CompareTag("FOO")) { ProcessCollision(results[i]); } } } //优化后的代码 //我们把所有带有标签FOO的对象都放入了相同的图层 void DetectCollision() { //8是相应图层的编号 var mask = 1 << 8; var count = Physics2D.CircleCastNonAlloc( position, radius, direction, results, distance, mask); for (int i = 0; i < count; i++) { ProcessCollision(results[i]); } }
规则9:使用标签属性
标签非常实用,可以提升代码的性能,但请记住:只有一种正确方法适合比较对象标签。
//未优化的代码 gameObject.Tag == "MyTag"; //优化后的代码 gameObject.CompareTag("MyTag");
规则10:小心棘手的摄像机
使用Camera.main很简单,但是这种操作的性能非常糟糕。这是因为在每个Camera.main调用背后,Unity其实会执行FindGameObjectsWithTag()来获取结果,因此频繁调用Camera.main并不好。
最好的解决方法是在Start或Awake方法中缓存Camera.main的引用。
//未优化的代码 void Update() { Camera.main.orthographicSize //对摄像机的一些操作 } //优化后的代码 private Camera cam; void Start() { cam = Camera.main; } void Update() { cam.orthographicSize //对摄像机的一些操作 }
规则11:使用LocalPosition替代Position
在代码允许的位置,为获取函数(Getter)和设置函数(Setter)使用Transform.LocalPosition替代Transform.Position。
这样的原因是:每次Transform.Position调用的背后,都会有更多操作要执行,包括在调用获取函数时计算全局位置,或是在调用设置函数时从全局位置计算出本地位置。
在项目中,我们发现在出现Transform.Position的几乎所有情况中都可以用LocalPosition替代Transform.Position,无需在代码中做其它改动。
规则12:不要使用LINQ
这条规则已经第一部分讲解,别使用LINQ就好。
规则13:不要害怕破坏最佳实践
有时候,即使是一个简单的函数调用,都可能造成过多的开销。在这种情况下,我们应该考虑使用代码内联。
代码内联是什么?代码内联意味着,我们可以把代码从函数中取出,把这些代码直接复制到打算使用函数的位置,从而避免额外的方法调用。
因为代码内联会在编译时自动完成,所以在大多数情况下,这样不会产生太明显的效果。在编译器决定代码是否内联时,会使用特定的规则。例如:Virtual方法从不会内联,更多详细信息,请访问:https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity8.html
我们需要打开性能分析器,在实际设备上运行游戏,从而了解是否仍有改进的空间。
在项目中,我们发现一些函数可以通过代码内联实现更好的性能,特别是游戏的大型For循环中的函数。

小结

通过使用本文介绍的规则,我们在iOS游戏中轻松实现了稳定的60fps,即使在iPhone 5S也有这样的运行效果。
本文的部分规则针对我们的用例而使用,但我认为在进行编程或代码评审时,开发者应该考虑这些规则,从而避免在后期阶段出现问题。在考虑性能因素的同时编写代码会比之后重构大量代码更简单。
开发过程中遇到问题?在这里提问:connect.unity.com/g/discussion
Tags:
Unity China
671
Comments
nongzhang
2 days ago
规则4:使用For循环代替Foreach循环。unity5.6以后不是优化了么,foreach和for没有区别
0
AHIOSUZ
4 days ago
黑铁
Mark
0
Fatoo
5 days ago
很棒!
0
c
changwujuexi
5 days ago
真.全干货文章
0
xunshu li
Staff
7 days ago
Mengqing Chen建议加个收藏文章功能
收到,收藏功能已经在做了,计划下一版更新
0