Unity性能優化技巧

最近看了B站Uinty官方有關性能優化技巧的視頻，自己做一些整理，

視頻鏈接：

Unite Now - （中文字幕）性能優化技巧（上）

Unite Now - （中文字幕）性能優化技巧（下）

堆疊（Stack）和堆積（Heap）

我們先來看下Unity記憶體中重要的兩部分，堆疊和堆積，因為只有了解了它們，我們才能知道應該如何優化記憶體，提高性能，

堆疊：

堆疊是記憶體中存盤函式和值型別的地方，

例如我們呼叫一個函式A，會將這個函式體與函式收到的引數放入到堆疊中，若在函式A中呼叫函式B，同樣會把函式B存放到堆疊中，當函式B運行結束，會將其從堆疊中移除，然后當A運行結束，把A從堆疊中移除，

因此我們在看Debug資訊的時候，就會發現Log里面能夠做到一層層的方法回溯，方便我們查看整體的呼叫程序，這也就是堆疊回溯，

由于是堆疊的結構，因此不會遇到碎片化或是垃圾收集（GC）的問題，但是可能會碰見堆疊溢位的問題，比如呼叫了太多的函式導致一直push東西進堆疊，占據越來越多的記憶體空間，導致堆疊溢位，

堆積：

堆積是記憶體中另一個區域，要比堆疊大，我們將所有的參考型別存放在這，通常我們每創建一個新的物件，會在堆積中找到下一個足夠存放的空位置，將其存盤，但是當我們銷毀物件后，記憶體空間不會馬上釋放出來，而是標記成未使用，之后垃圾收集器會釋放這部分空間，

物件實體化和摧毀的程序其實很慢，所以我們要盡可能地避免在堆積中配置記憶體的行為，如果我們需要的記憶體比之前已經配置好的還多，在放不下的情況下，堆積會膨脹，并且每次都增長兩倍，且不會再碩訓去，過大的堆積就會影響到我們游戲的性能，當我們在堆積中釋放了一些占用空間小的物件，而后添加一些占用空間大的物件時，由于前面釋放的空間不足以存放下，就會導致這些空間空出來，使得記憶體的使用情況就變得斷斷續續起來，這也就是記憶體的碎片化，同樣降低我們的游戲性能，

垃圾收集（GC）的原理：每一次GC，都會遍歷堆積上所有的物件，找到需要釋放的東西，然后將其釋放，

假如游戲玩到一半，GC必須要釋放數十或數百個游戲物件的記憶體，那么這會對你的游戲程序造成一個負載峰值，我們要避免這樣的負載峰值，

編程程序中的一些優化建議

1.選擇合適的資料結構

資料結構，也就是Array，List和Dictionary等，例如在Array或List中使用索引的成本很低，那么就適合要經常通過索引讀取的情況，而要頻繁增加和移除物件時，使用Dictionary是最合適的，

2.物件池

在游戲程式中，創建和銷毀物件事很常見的操作，通常會通過 Instantiate 和 Destroy 方法來實作，如果頻繁的進行這些操作，GC的時候會導致負載很重，因為會有大量的已摧毀物件的存在，不僅會造成CPU的負載峰值，還可能導致堆積碎片化，因此我們可以使用物件池來處理這類問題，

使用物件池時需要注意，要決定物件池的大小，以及一開始要產生多少數量的物件在池中，因為如果你需要的物件數量多過池中現有的，就必須將物件池變大，擴的太大可能造成浪費，擴的小可能又造成頻繁的添加，

3.Scriptable Objects

假設我們有一個控制敵人的組件，名叫Enemy，代碼如下：

public class Enemy : MonoBehaviour
{
    public float maxSpeed;
    public float attackRadius;
}

這個組件掛載在每個敵人身上，但是其中這兩個浮點數（maxSpeed 和 attachRadius）的數值都是不變的，那么當場景中存在很多的敵人時，每次生成敵人的時候，這些資料就會重復一份，

所以即使所有資料都一樣，這兩個浮點數還是重復的出現在有此腳本的物件上，所以建議改用Scriptable Objects，這樣就只會耗費一組這樣資料的記憶體，代碼如下：

public class EnemyConfiguration : ScriptableObject
{
    public float maxSpeed;
    public float attackRadius;
}
public class Enemy : MonoBehaviour
{
    public EnemyConfiguration enemyConfiguration;
}

4.變數or屬性

通常我們為了封裝安全性，開發時會選擇使用屬性（getter/setter），而屬性本質上是函式的呼叫，前面提到呼叫函式時，會在堆疊上分配記憶體，因此呼叫屬性也是如此，當呼叫多次時，花費在堆疊中的時間就會增加，當然了，一般來說問題不大，但是如果在使用頻繁的回圈體中使用屬性，可能就需要針對性的優化，

我們可以通過宏命令進行處理，例如在開發時使用屬性，發布版本時使用變數，如下：

#if DELELOPMENT_BUILD
    int m_health;
    public int health { get => m_health; }
#else
    public int health;
#endif

5.Resources目錄

當專案被構建時，所有名為Resources的檔案夾中的所有Asset和Object都會合并到同一個序列化檔案中，這個序列化檔案中還含有元資料（Metadata）和索引（Indexing）資訊，同時加載Resources檔案這一操作無法跳過，它會在應用程式啟動顯示不可互動的啟影片面（Splash Screen）時執行，即使里面很多資源我們此時都沒有用到，這就會直接影響游戲的啟動時間，同時也會占用很大的記憶體，

所以建議直接棄用Resources，使用AssetBundle，以更有效的方式管理資源的載入和卸載，（也可以試試Addressable資源系統）

6.洗掉空的Unity事件

Monobehaviour中的Start，Update這些方法即使是空的，也會帶來些微的性能消耗，因此若為空，就洗掉它們，

7.避免在Awake和Start中添加大量的邏輯

這對游戲啟動很重要，Unity會在Awake和Start方法執行后渲染第一個畫面，某些情況可能會導致啟影片面或是載入畫面需要花更長的時間渲染，因為你必須等每個游戲物件都完成Awake和Start的執行，（游戲啟動時，黑屏太久，可能會被退審）

8.快取一些Hash值

在我們想要在運行時修改影片或者材質的時候，可以使用下面方法來實作

animator.SetTrigger("Idle");
material.SetColor("Color", Color.white);

這類方法往往也可以通過索引來作為引數，使用字串只是能顯示的更加直觀，但是當我們傳遞字串時，程式內部會進行一些處理，頻繁呼叫的話可能就會造成性能的消耗，因此我們可以先找到對應的索引，并將其快取起來，供后續使用，如下：

int idleHash = Animator.StringToHash("Idle");
animator.SetTrigger(idleHash);
int colorId = Shader.PropertyToID("Color");
material.SetColor(colorId, Color.white);

9.層次結構

某些情況下，場景中的物體可能有很深的嵌套結構，當我們對父節點的GameObject進行坐標轉換時，就會產生OnTransformChanged事件，這訊息會傳遞給該GameObject下所有子物件，即使這些物件沒有任何渲染組件（也就是我們看不見任何變化），造成一些不必要的轉換運算，包括平移，旋轉和縮放，

此外，較深的結構也會導致在GC時，花費更多的時間在層級結構間遍歷，

10.Accelerometer Frequency

這個設定在Project Settings->Player->IOS->Other Settings中，這個功能定義Unity從設備讀取加速度儀資訊的頻率，在不需要加速儀的游戲中，將它啟動或設定了高于需求的頻率，會影響性能表現，因為讀取硬體設備資訊，會增加CPU的處理時間，

11.移動物體

Unity中有許多移動游戲物件的方法，例如 transform.Translate，如果物件需要碰撞判定，我們則會添加剛體和碰撞體，如果還是使用 transform.Translate 方法，會造成PhysX物理引擎整體重新計算，對于復雜的場景，成本可能很高，因此若要移動帶有剛體的物件，使用rigidBody.MovePosition，并且要在FixedUpdate方法中執行，

建議使用transform.Translate就在Update中執行，使用rigidBody.MovePosition或AddForce方法在FixedUpdate中執行，

12.添加組件

在運行時呼叫AddComponent其實很沒效率，尤其在一幀中多次啟用這類呼叫，

當我們添加一個組件的時候，Unity會做下列操作：

• 先看組件有沒有DisallowMultipleComponent的設定，如果有，就要去檢查是否有同型別的組件已加入
• 然后檢查RequireComponent設定是否存在，如果設定了，就代表這個組件需要別的組件同步加入（重復做添加組件的操作）
• 最后呼叫所有被加入的MonoBehaviour的Awake方法

上述這些步驟都發生在堆積上，所以可能會影響性能和增加GC的處理時間，

13.快取參考物件（與第8條類似）

例如我們常常會在游戲運行的時候去查找一些物件，GameObject.Find與其他所有關聯的方法，需要遍歷所有記憶體中的游戲物件以及組件，因此在復雜場景中，效率會很低，GameObject.GetComponent，會查詢所有附加到GameObject上的組件，組件越多，GetComponent的成本就越高，若使用的是GetComponentInChildren，隨著查詢變復雜，成本會更高，

因此不要多次查詢相同的物件或組件，而且查詢一次后將其快取起來，方便后續的使用，

資源匯入的一些優化建議

例如下圖中左右兩邊使用的都是相同的模型與貼圖，但是最終所占的磁盤大小卻差了很多，就是因為一些設定導致的，

有關紋理匯入設定的建議：

1.根據平臺不同，紋理的 Max Size 設成該平臺最小值

2.紋理的大小為2的冪次方（POT），因為有些壓縮格式可能不支持非2的冪次方的，

3.盡量將多張紋理合并成為大圖

4.對于不透明紋理，關閉其 alpha 通道

5.除非你必須從代碼來訪問紋理的底層資料，否則關閉 Read/Write Enabled 選項，減少記憶體使用

6.選擇合適的Format，可減少占用的空間

7.例如UI元素這類相對于相機Z軸的值不會有任何變化的紋理，關閉Generate Mip Map選項

Mesh的匯入設定建議：

1.試著用高比率的Mesh壓縮，來減少磁盤容量，注意：運行時的記憶體不受這項設定影響

2.盡量關閉 Read/Write Enabled 選項，若開啟，Unity會存盤兩份Mesh，導致運行時的記憶體用量變成兩倍，

3.如果沒有使用影片，請關閉Rig，例如房子，石頭這些

4.如果沒有用到 Blendshapes，也關閉

5.如果Material沒有用到法向量和切線資訊，關閉可以減少額外資訊，

影像（Graphics）的一些優化建議

基本上當Unity渲染游戲影像時，會呼叫 draw call 來對GPU下指令，讓場景能成功渲染，物件，材質和紋理越多，處理起來需要的時間也越多，所以過多的drawcall就會影響游戲的優化，這對于瓶頸在GPU上的游戲影響特別大，也就是我們的游戲已經給GPU太大的壓力了，

使用批處理：

我們可以使用批處理來盡量減少drawcall，使用批處理需要滿足一些情況，例如，要批處理的物件必須參考一樣的材質，并使用相同的紋理（紋理合并在這就很重要），但是使用的模型可以不一樣，

動態批處理：可以減少對于移動物件的drawcall，只能用于少于900個頂點資訊的情況，包含坐標、法線、uv0、uv1、切線，動態批處理每幀評估一次，由CPU負責，

靜態批處理：即對開啟 static 標記的物件做批處理，在構建期完成，適用于絕大部分的靜態Mesh，因此任何不會動的物件都應標記為靜態的，如果我們在運行時要添加靜態物件，可以看一下 StaticBatchUtility.Combine() 的API

有關SRP Batcher可以看下：https://blog.csdn.net/wangjiangrong/article/details/105518220

Cast Shadows

默認情況下，MeshRenderder組件的Cast Shadows是開啟的，

陰影的渲染可以讓游戲的光線增加真實度和深度感，但是某些情況下可能并不需要，在復雜場景中，可能會造成多余的陰影計算，陰影效果最后也看不見，

因此若場景有的物件是否有陰影對整體效果沒有影響的話，就關閉這個選項，不計算陰影可以省下CPU時間，（具體渲染步驟可以在 Frame Debugger的Shadows.Draw中查看）

Light Culling Mask

在復雜場景中，許多光線緊靠彼此，你可能覺得光線不能影響特定物件，根據渲染流程的設定，場景中越多的光照，性能可能就會越差，因此我們要確保光照只影響特定的物件層（例如專門給角色打光的光源，設定成只影響角色），尤其是多光源和多物件彼此緊靠的時候，

避免使用手機原生解析度

現在的手機解析度非常的高，在手機呈現高解析度可能會影響性能和手機過熱的問題，因為會有大量的計算需求，如后期處理，如果游戲本身很耗GPU，高解析度會惡化這些問題，建議使用 Screen.SetResolution 來降低游戲預設的決議設定（根據不同的設備來找到一些合適的值），來提高性能，

UI的一些優化建議

顯示與隱藏

UI的隱藏我們可以使用將其移到Canvas外的方法，而不是利用SetActive(false)的方法來隱藏，

視頻中建議的似乎是SetActive(false)

UI的批處理

如果UI元素會改變數值或是位置，會影響批處理，導致向GPU發送更多的drawcall，因此建議：

1.將更新頻率不同的UI放在不同的Canvas上，

2.相同Canvas中的UI元素的Z值要相同，這樣才不會打斷批處理，

3.相同Canvas中的UI元素要使用相同的材質和紋理，材質或著色器可以有動態變換（例如一些特效），這不會影響批處理，

4.相同Canvas中的UI元素要使用相同裁剪矩陣，

Graphic Raycaster

該組件是用來處理輸入事件，默認掛載在每個Canvas上，有時不能互動的物件仍是canvas中的一部分，并附帶了該組件，所以當每次滑鼠或觸控點擊時，系統就要遍歷所有可能接受輸入事件的UI元素，就會造成多次的 “點落在矩形中” 的檢查，來判斷物件是否該作出反應，在UI很復雜的情況下，這個運算成本就會很高，因此建議確保只有可互動的Canvas才有該組件，節省CPU運行時間，

全屏UI的處理

游戲中可能會有些全屏UI（例如一些設定界面），會遮擋住場景物體或其他UI元素，然而它們即使被遮擋看不見，CPU和GPU還是會有消耗，因此建議：

1.3D場景完全被遮擋的話，關閉渲染3D場景的攝像機，

2.被遮蔽的UI，Disable這些Canvas，注意不是SetActive(false），

3.盡可能的降低幀率，因為這些UI一般不需要重繪那么頻繁，

音頻（Audio）一些優化建議

音頻檔案常以不正確的方式匯入的Unity中，原因可能是對硬體或格式不熟悉，或是匯入程序中出現了問題，這將造成運行時記憶體使用過高，打包中占用大量的空間，以及沒有善用底層硬體提供的解壓縮方式，因此建議：

1.可以的話，將音頻檔案設定為Force To Mono，這樣做可以省下一半的記憶體和磁盤空間，

2.如果需要額外的壓縮，可以降低檔案的位元率（bitrate），前提音頻品質不會被破壞太嚴重，

3.IOS適合使用ADPCM和MP3格式，Android適合使用Vorbis格式，

載入方式

注：檔案必須小于200kb，因為內部記憶體管理的問題，大于200kb的檔案也還是只會被分配到這么多，

靜音處理

一般游戲中都會有靜音的設定，我們往往我們只是把AudioSource或Mixer的音量設定為0，這樣還是會造成不必要的記憶體和CPU占用，關音量并不會釋放音頻的記憶體，

因此建議在記憶體中卸載音頻相關的來源或是記憶體中的音頻檔案，將AudioSource組件Disable，同時有個上層管理系統負責過濾和音頻相關的API呼叫，當然卸載和重新載入音頻的成本也很高，要是玩家頻繁的開啟和關閉靜音的話，就不適用了（一般情況下不會）