性能優化篇之腳本策略

這是我在《Unity游戲優化 (第2版)》看的，記錄一下~

寫Mono腳本的時候需要注意哪些問題呢？

大概從以下幾個方面介紹：
1.訪問組件
獲取組件有三種方式

GetComponent(string)
GetComponent<T>()
GetComponent(typeof(T))

其中：
泛型的最快，應該優先用這個
字串的最慢，如非必要情況，絕對不要使用這個

另外：
需要經常訪問的組件盡可能地來快取
每次都會節省一些CPU開銷，代價是少量記憶體消耗

2.函式回呼
Unity最常用的回呼是：Awake()、Start()、Update()、FixedUpdate()

Unity是如何呼叫這些函式的呢？
在場景中第一次實體化時，Unity會將任何定義好的回呼函式添加到一個函式指標串列中，會在對應關鍵時刻呼叫這個串列
即使函式體是空的，也會掛接到這些回呼中
如果有一堆空的函式分散的定義在整個代碼庫中，引擎會有少量的開銷，浪費銷量的CPU

導致的問題：
1.空的 Start() 定義會 導致物件的初始化變慢
當場景里有成千上萬個物件時，只要通過 Object.instantiate()創建時，就會浪費CPU時間
2.空的Update() 也會導致每幀浪費大量的CPU周期，會嚴重影響幀率

對于Update() 函式，盡量避免一些不必要的操作：
1.反復計算很少或從不改變的值
2.太多的組件計算一個可以共享的結果
3.執行作業的頻率遠超必要值

最好一般都自己實作更新類：
1.避免了Unity的本機-托管橋接的高成本
2.可以自己控制更新的頻率、更新的順序等
3.可以實作暫停、冷卻時間等等操作效果

有時候會在 Update() 里面呼叫以超出需要的頻率重復呼叫某段代碼

void Update()
{
    TaskA();
}

如果任務完成的頻率低于沒有明顯缺陷的每一幀，那么可以通過減少呼叫頻率來進行性能優化

float _delay = 0.2f;
float _timer = 0f;

void Update()
{
    _timer += Time.deltaTime;
    if( _timer > _delay )
    {
        TaskA();
        _timer = 0f;
    }
}

同樣也可以使用 協程 來解決

3.協程

使用協程代替 Update計時器的
優點：
1.只呼叫指定的次數，在此之前一直處于空閑狀態，從而減少對大多數幀的性能影響
缺點：
1.啟動攜程會帶來額外開銷（大概函式呼叫的三倍）
2.額外分配一些記憶體，將當前狀態存盤在記憶體中，直到下一次呼叫它
3.每次yield呼叫都會造成相同的開銷成本

注意：
1.協程的運行獨立于Mono組件中的Update回呼，無論組件是否禁用，都將繼續呼叫協程
2.協程在它 GameObject active=false 時候自動停止（無論使它還是它父節點），再次被設定為 true 時也不重新啟動
3.協程很難除錯，在堆疊上也不會有呼叫者

額外：
同樣 InvokeRepeating() 也可以實作定時功能
其建立更簡單，開銷成本更小（小一丟丟吧）

InvokeRepearting("ProcessAI", 0f, _delay);

其完全獨立于 Mono 和 GameObject 的狀態的
停止的方法只有兩個:
第一個是呼叫 CalcelInvoke()
第二個是直接銷毀關聯的 MonoBehaviour 或者 Gameobject

4.GameObject 和 Transform 的使用

a.檢查Gameobject是空的幾種方式

if(go == null) {}

if( !System.Object.ReferenceEquals( go, null) {}

后者的速度大約是前者的兩倍
這個方法不僅適用于GameObject還適用于其他物件

b.避免從GameObject中取出字串屬性
從物件中檢索字串屬性與檢索C#中任何其他的參考型別屬性是相同的，不增加額外記憶體成本，
但是從GameObject中取出字串屬性是另一種意外跨越 本機-托管橋接 的微妙方式

受到影響的屬性為 ：name 和 tag
eg：下面的代碼會在每次迭代中導致額外分配記憶體：

for(int i=0;i < count; i++)
    if(go.tag === "Player")
        //do something

Unity為其提供了一個 CompareTag() 方法，其完全避免了本機-托管的橋接

結果：
.tag會產生大量的GC，并且耗時也是其兩倍
CompareTag()是推薦用的方法

name沒有對應的比較方法，最好使用tag區分

c.避免修改Transform的父節點
在Unity早期版本中，Transform組件的參考通常是在記憶體中隨機排列的
也就是在多個Transform迭代是相當慢的，會存在快取丟失的可能

為啥這樣做？
修改GameObject的父節點為另一個物件不會造成顯著的性能下降，因為Transform操作起來像堆資料結構，插入和洗掉的速度相對較快

但是在Unity5.4以后，Transform組件的記憶體布局發生了很大的變化
Transform組件的父子關系操作起來更像動態陣列，Unity嘗試將所有共享相同的父元素 Transform 按順序存盤在預先分配的記憶體緩沖區中的記憶體中，并在 Hierarchy 視窗下的深度進行排序
這樣做的好處就是可以進行更快的迭代，尤其是物理和影片系統，

也有很大的缺點：
1.如果將一個 GameObject 的父物件重新指定為另一個物件，父物件必須將新的子物件放入預先分配的記憶體緩沖區中，并根據新的深度對所有這些 Transform 排序
2.如果沒有預先分配足夠的空間來容納新的子物件，就必須擴展緩沖區，以便以深度優先的順序容納新的子物件

通過 Object.Instantiate() 實體化新的 GameObject 時，其默認的父節點是 null，都放在 Hierarchy的根元素下
這里的所有元素同樣也需要分配一個緩沖區來存盤他當前的元素以及以后可能添加的元素
如果需要立即將Transform的元素重新修改為另一個元素，剛才的緩沖區就白分配了
盡可能使用引數，跳過緩沖區分配的步驟

d.快取Transform的變化
Transform組件只存盤與其父組件相關的資料
訪問或者修改 Transform 組件的 position、rotation、scale 都會導致大量未預料到的矩陣乘法計算，從而通過其父節點的Transform 為物件生成正確的Transform
物件在 Hireachy 視窗越深，確定最終結果需要計算的就越多
（修改的同時也會向某些組件發資訊[Collider、Rigidbody、Light、Camera等]，因為這些組件也需要知道Transform的新值，并相應地更新）

如果使用localPostion、localRotation、localScale的相對成本就比較小
因為其直接存盤在給定的 Transform 中，不需要任何的矩陣乘法

e.不要在同一幀中多次替換Transform的屬性
每次賦值都會觸發內部訊息，其實這是完全沒有必要的
只要存盤一個記憶體成員變數，在這一幀的最后呼叫一次即可

5.物件間通信

避免在運行時呼叫 Find() 和 SendMessage() 方法
其代價非常昂貴，應該不惜一切代價避免使用
Find() 偶爾在游戲初始化的時候呼叫一次

可以通過自定義的事件系統來實作（這里就不說了）

6.數學計算
共享計算輸出，讓多個物件共享某些計算的結構
（比如：從檔案讀取資料，決議資料，AI尋路等等）
只計算一次結果，然后將結果分發給需要它的每個物件，以最小化重新計算的量

7.場景和預制體加載等反序列化
Untiy的序列化主要用于場景、預制件、ScriptObjects和各種資產型別（派生自ScriptObject），
當其中一種物件型別保存到磁盤時，就是用 YAML （Yet Another markup Language，另一種標記語言）格式將其轉換為文本檔案，稍后可以將其反序列化成原始物件型別

當構建好了應用程式時，這些序列化的資料會捆綁在大型二進制數檔案中，這些檔案在Unity中被稱為序列化檔案
運行時從磁盤讀取和反序列化資料是一個非常慢的程序，因此所有反序列化活動都有一定的性能成本

一般發生在資源加載時候（Resources.Load())，一旦資料從磁盤加載到記憶體中，以后重新加載相同的參考會快很多，但是在第一次訪問的時候總是需要磁盤活動，

注意：
如果需要反序列化的資料集越大，此程序所需的時間就越長
預制件的每個組件都是序列化的，因此層次結構越深，需要反序列化的資料就越多（空的也算）

加載方式：
1.第一次加載很多，會造成CPU的顯著峰值，會增加加載時間
2需要時候再加載，可能會掉幀

如何減小反序列化的成本呢？

a.減小序列化物件
可以把一個大的預制件分割成更小的幾個預制件，然后一塊一塊的組合在一起

b.異步加載序列化物件
可以把從磁盤讀取的任務轉移到作業執行緒上，從而減輕主執行緒的負擔

c.在記憶體中保存之前加載的序列化物件
一旦加載到記憶體中，復制下來，下一次加載就會很快
缺點就是需要大量的記憶體，是一種風險策略

d.將公共資料轉移出去
如果很多預制件都有一些共享資料，可以提取到一個組態檔中，然后再加載使用它，

對于場景的資源的優化：
疊加、異步加載場景
1.同步加載場景，主執行緒將阻塞，直到指定的場景加載完成，用戶體驗非常糟糕
2.使用異步加載可以有效緩解，同時讓玩家繼續操作
3.也可以疊加逐漸加載(LoadSceneMode.Additive)，讓場景逐漸加載出來，并且不會對用戶體驗造成明顯影響

8.使用合適的資料結構
常見的性能問題就是：
為了簡單，但是用了不適當的資料結構來解決問題

a.如果希望遍歷一組物件，最好使用串列（List）
其是動態陣列，物件在記憶體中彼此相鄰，迭代導致的快取丟失最小
b.如果希望快速獲取、插入或者洗掉，最好使用字典
其能通過hash快速映射？

如果有希望快速找出物件，同時還能遍歷組應該咋辦呢？
a.如果使用字典，然后再對它進行遍歷
遍歷的程序將會非常慢，因為必須檢查字典中每個可能的散列，才能對其進行完全遍歷
b.最好使用額外記憶體開銷 維護一個字典和一個串列
雖然在插入洗掉有些麻煩，但在迭代的時候會產生明顯的優勢

9.禁用未使用的腳本和物件
如果場景特別大的話，Update() 回呼越多 游戲性能也就越不差
（除了一些特別仿真的游戲）

a.通過可見性禁用物件
也就是在相機視圖不可見的物件
Unity有一些選項可以做到（比如Animator的Culling Mode），但是僅僅只是渲染層的優化，不會影響CPU上執行人物的組件

那咋整呢？
可以通過 OnBecameVisible() 和 OnBecameInvisible() 回呼
觸發的前提就是必須與渲染管線通信，也就是在自身需要加一個可渲染的組件（MeshRenderer 或 SkinnedmeshRenderer
)

b.通過距離禁用物件
一般離玩家足夠遠的話， 玩家并不關注他們，此時可能希望禁用他們
只需自己判斷距離即可

注意：
判斷距離使用平方不是距離
CPU比較擅長將浮點數相乘，不擅長計算他們的平方根
如果使用 .magnitude 或者 Distance() 會造成大量的 CPU開銷
可以使用sqrMagnitude屬性代替，