再議Unity優化

01-23

0x00 前言

在很長一段時間裡，Unity項目的開發者的優化指南上基本都會有一條關於使用GetComponent方法獲取組件的條目（例如14年我的這篇博客《深入淺出聊Unity3D項目優化：從Draw Calls到GC》）。有時候還會發展為連一些Unity內部對象的屬性訪問器都要小心使用的注意事項，記得曾經有一段時間我們的項目組也會嚴格要求把例如transform、gameobject之類的屬性訪問器進行緩存使用。這其中的確有一些措施是有道理的，但很多朋友卻也是知其然而不知其所以然，朦朧之間似乎有一個印象，進而成為習慣。那麼本文就來聊聊Unity優化這個題目中偶爾會被誤解的內容吧。

0x01 來自官方的建議

本文主要是關於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到底會導致哪些性能上的問題，我們可以做幾個小測試。

0x02 和GC無關的性能優化

眾所周知，GetComponent有三個重載版本，分別是：

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

所以，測試的第一步就是先確定一個效率最高的重載版本，之後再去檢查它們各自引起的堆內存分配。

「效率之王」

為此，我們在5.X版本的Unity中準備一個空白的場景並實現一個簡單的計時器，之後就可以開始測試了。

using System;using System.Diagnostics;/// <summary>/// 簡易的計時類/// </summary>public class YiWatch : IDisposable{ #region 欄位 private string testName; private int testCount; private Stopwatch watch; #endregion #region 構造函數 public YiWatch(string name, int count) { this.testName = name; this.testCount = count > 0 ? count : 1; this.watch = Stopwatch.StartNew(); } #endregion #region 方法 public void Dispose() { this.watch.Stop(); float totalTime = this.watch.ElapsedMilliseconds; UnityEngine.Debug.Log(string.Format("測試名稱：{0} 總耗時：{1} 單次耗時：{2} 測試數量：{3}", this.testName, totalTime, totalTime / this.testCount, this.testCount)); } #endregion}

自定義的組件TestComp，以及我們的測試代碼，每一個方法會被調用1000000次以便於觀察測試結果：

int testCount = 1000000;//定義測試的次數 using (new YiWatch("GetComponent<>", testCount)) { for(int i = 0; i < testCount; i++) { GetComponent<TestComp>(); } } using (new YiWatch("GetComponent(typeof(T))", testCount)) { for(int i = 0; i < testCount; i++) { GetComponent(typeof(TestComp)); } } using (new YiWatch("GetComponent(string)", testCount)) { for(int i = 0; i < testCount; i++) { GetComponent("TestComp"); } }

運行的結果如圖（單位ms）：

我們可以發現在Unity 5.x版本中，泛型版本的GetComponent<>的性能最好，而GetComponent(string)的性能最差。

做成柱狀圖可能更加直觀：

接下來，我們來測試一下我們感興趣的堆內存分配吧。為了更好的觀察，我們把測試代碼放在Update中執行。

void Update(){ for(int i = 0; i < testCount; i++) { GetComponent<TestComp>(); }}

同樣每幀執行1000000次的GetComponent方法。打開profiler來觀察一下堆內存分配吧：

我們可以發現，雖然頻繁調用GetComponent時會造成CPU的開銷很大，但是堆內存分配卻是0B。

但是，我和朋友聊天偶爾聊到這個話題時，朋友說有時候會發現每次調用GetComponent時，在profiler中都會增加0.5kb的堆內存分配。不知道各位讀者是否有遇到過這個問題，那麼是不是說GetComponent方法有時的確會造成GC呢？

答案是否定的。

這是因為朋友是在Editor中運行，並且GetComponent返回Null的情況下，才會出現堆內存分配的問題。

我們還可以繼續我們的測試，這次把TestComp組件從場景中去除，同時把測試次數改為100000。我們在Editor運行測試，可以看到結果如下：

10000次調用GetComponent方法，並且返回為Null時，觀察Editor的Profiler，可以發現每一幀都分配了5.6MB的堆內存。

那麼如果在移動平台上調用GetComponent方法，並且返回為Null時，是否會造成堆內存分配呢？

這次我們讓這個測試跑在一個小米4的手機上，連接profiler觀察堆內存分配，結果如圖：

可以發現，在手機上並不會產生堆內存的分配。

Null Check造成的困惑

那麼這是為什麼呢？其實這種情況只會發生在運行在Editor的情況下，因為Editor會做更多的檢測來保證正常運行。而這些堆內存的分配也是這種檢測的結果，它會在找不到對應組件時在內部生成警告的字元串，從而造成了堆內存的分配。

We do this in the editor only. This is why when you call GetComponent() to query for a component that doesn』t exist, that you see a C# memory allocation happening, because we are generating this custom warning string inside the newly allocated fake null object.

所以各位不必擔心使用GetComponent會造成額外的堆內存分配了。同時也可以發現只要不頻繁的調用GetComponent方法，CPU的開銷還是可以接受的。但是頻繁的調用GetComponent會造成顯著的CPU的開銷的情況下，各位還是對組件進行緩存的好。

屬性訪問器的性能

既然聊了GetComponent方法的性能，接下來我們可以繼續來聊聊和GetComponent功能有些類似的，Unity腳本系統中的一些屬性訪問器的性能。

我們最常見的屬性訪問器大概算是transform和gameObject了吧，當然，如果使用過4.x版本的朋友應該還會知道rigidbody、camera、renderer等等。但是到了5.x時代，除了gameObject和transform之外的屬性訪問器都已經被棄用了，相反，5.x中會使用 GetComponent<>來獲取它們：

所以從4.x升級到5.x之後，這些訪問器就無法使用了，所以升級引擎時各位可以關注一下自己的代碼中是否有類似的問題。

好了，我們接著在測試中加入使用訪問器獲取Transform組件的效率：

using (new YiWatch("transform", testCount)) { for(int i = 0; i < testCount; i++) { transformTest = this.transform; } }

運行1000000次，結果如下（單位ms）

單次的耗時是0.000026ms，性能要遠好於調用GetComponent<>方法，所以是否緩存類似gameObject或者transform這樣的屬性訪問器似乎對性能的優化幫助不大。當然寫代碼和個人的習慣關係很大，如果各位早已習慣緩存這些屬性訪問器自然也是不錯的選擇。

0x03 總結

通過以上測試，我們可以發現：

頻繁的調用GetComponent方法會造成CPU的開銷，但是對GC幾乎沒有影響。
Profiler不要用來分析Editor中運行的項目，由於一些引擎內部的檢查會導致結果出現較大偏差。
5.X版本中GetComponent<>的性能最好。
使用屬性訪問器來訪問一些內建的屬性例如transform的性能已經可以讓人接受了，並不一定非要緩存這些屬性。
5.X版本刪掉了很多屬性訪問器，基本上只保留了gameObject和transform。

最後需要說明的是，上述的測試發生在5.X版本的Unity中。如果使用4.x版本可能會有些許不同，例如在4.X版本中，GetComponent(typeof)的性能可能要好於GetComponent<>，而且能夠直接使用的屬性訪問器也更多，各位可以自己進行測試。

-華麗的分割線-

歡迎大家關注我的公眾號慕容的遊戲編程：chenjd01

最後打個廣告，歡迎支持我的書《Unity 3D腳本編程》~