Unity效能優化技巧
最近看了B站Uinty官方有關效能優化技巧的視訊，自己做一些整理。
視訊連結：
堆疊（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） | Decompress On Load |
| 中型音訊檔（>= 200kb） | Compressed In Memory |
| 大型音訊檔，例如背景音 | Streaming |
注：檔案必須小於200kb，因為內部記憶體管理的問題，大於200kb的檔案也還是隻會被分配到這麼多。
靜音處理
一般遊戲中都會有靜音的設定，我們往往我們只是把AudioSource或Mixer的音量設定為0，這樣還是會造成不必要的記憶體和CPU佔用，關音量並不會釋放音訊的記憶體。
因此建議在記憶體中解除安裝音訊相關的來源或是記憶體中的音訊檔，將AudioSource元件Disable，同時有個上層管理系統負責過濾和音訊相關的API呼叫。當然解除安裝和重新載入音訊的成本也很高，要是玩家頻繁的開啟和關閉靜音的話，就不適用了（一般情況下不會）