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

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

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

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

其中：
泛型的最快，應該優(yōu)先用這個
字符串的最慢士骤，如非必要情況忆蚀，絕對不要使用這個

另外：
需要經(jīng)常訪問的組件盡可能地來緩存
每次都會節(jié)省一些CPU開銷，代價是少量內(nèi)存消耗

2.函數(shù)回調(diào)
Unity最常用的回調(diào)是：Awake()嘁扼、Start()信粮、Update()、FixedUpdate()

Unity是如何調(diào)用這些函數(shù)的呢趁啸？
在場景中第一次實例化時强缘，Unity會將任何定義好的回調(diào)函數(shù)添加到一個函數(shù)指針列表中，會在對應關(guān)鍵時刻調(diào)用這個列表
即使函數(shù)體是空的不傅，也會掛接到這些回調(diào)中
如果有一堆空的函數(shù)分散的定義在整個代碼庫中旅掂，引擎會有少量的開銷，浪費銷量的CPU

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

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

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

有時候會在 Update() 里面調(diào)用以超出需要的頻率重復調(diào)用某段代碼

void Update()
{
    TaskA();
}

如果任務完成的頻率低于沒有明顯缺陷的每一幀劫哼，那么可以通過減少調(diào)用頻率來進行性能優(yōu)化

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

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

同樣也可以使用 協(xié)程 來解決

3.協(xié)程

使用協(xié)程代替 Update計時器的
優(yōu)點：
1.只調(diào)用指定的次數(shù)叮趴，在此之前一直處于空閑狀態(tài)，從而減少對大多數(shù)幀的性能影響
缺點：
1.啟動攜程會帶來額外開銷（大概函數(shù)調(diào)用的三倍）
2.額外分配一些內(nèi)存权烧，將當前狀態(tài)存儲在內(nèi)存中眯亦，直到下一次調(diào)用它
3.每次yield調(diào)用都會造成相同的開銷成本

注意：
1.協(xié)程的運行獨立于Mono組件中的Update回調(diào)，無論組件是否禁用般码，都將繼續(xù)調(diào)用協(xié)程
2.協(xié)程在它 GameObject active=false 時候自動停止（無論使它還是它父節(jié)點）妻率，再次被設(shè)置為 true 時也不重新啟動
3.協(xié)程很難調(diào)試，在棧上也不會有調(diào)用者

額外：
同樣 InvokeRepeating() 也可以實現(xiàn)定時功能
其建立更簡單侈询，開銷成本更猩嗾恰（小一丟丟吧）

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

其完全獨立于 Mono 和 GameObject 的狀態(tài)的
停止的方法只有兩個:
第一個是調(diào)用 CalcelInvoke()
第二個是直接銷毀關(guān)聯(lián)的 MonoBehaviour 或者 Gameobject

4.GameObject 和 Transform 的使用

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

if(go == null) {}

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

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

b.避免從GameObject中取出字符串屬性
從對象中檢索字符串屬性與檢索C#中任何其他的引用類型屬性是相同的，不增加額外內(nèi)存成本。
但是從GameObject中取出字符串屬性是另一種意外跨越 本機-托管橋接 的微妙方式

受到影響的屬性為 ：name 和 tag
eg：下面的代碼會在每次迭代中導致額外分配內(nèi)存：

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

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

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

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

c.避免修改Transform的父節(jié)點
在Unity早期版本中扭粱，Transform組件的引用通常是在內(nèi)存中隨機排列的
也就是在多個Transform迭代是相當慢的舵鳞，會存在緩存丟失的可能

為啥這樣做？
修改GameObject的父節(jié)點為另一個對象不會造成顯著的性能下降琢蛤，因為Transform操作起來像堆數(shù)據(jù)結(jié)構(gòu)蜓堕，插入和刪除的速度相對較快

但是在Unity5.4以后，Transform組件的內(nèi)存布局發(fā)生了很大的變化
Transform組件的父子關(guān)系操作起來更像動態(tài)數(shù)組博其，Unity嘗試將所有共享相同的父元素 Transform 按順序存儲在預先分配的內(nèi)存緩沖區(qū)中的內(nèi)存中套才，并在 Hierarchy 窗口下的深度進行排序
這樣做的好處就是可以進行更快的迭代，尤其是物理和動畫系統(tǒng)慕淡。

也有很大的缺點：
1.如果將一個 GameObject 的父對象重新指定為另一個對象背伴，父對象必須將新的子對象放入預先分配的內(nèi)存緩沖區(qū)中，并根據(jù)新的深度對所有這些 Transform 排序
2.如果沒有預先分配足夠的空間來容納新的子對象峰髓，就必須擴展緩沖區(qū)傻寂，以便以深度優(yōu)先的順序容納新的子對象

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

d.緩存Transform的變化
Transform組件只存儲與其父組件相關(guān)的數(shù)據(jù)
訪問或者修改 Transform 組件的 position徐紧、rotation静檬、scale 都會導致大量未預料到的矩陣乘法計算，從而通過其父節(jié)點的Transform 為對象生成正確的Transform
對象在 Hireachy 窗口越深浪汪，確定最終結(jié)果需要計算的就越多
（修改的同時也會向某些組件發(fā)信息[Collider巴柿、Rigidbody、Light死遭、Camera等]，因為這些組件也需要知道Transform的新值凯旋，并相應地更新）

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

e.不要在同一幀中多次替換Transform的屬性
每次賦值都會觸發(fā)內(nèi)部消息钠署，其實這是完全沒有必要的
只要存儲一個內(nèi)存成員變量，在這一幀的最后調(diào)用一次即可

5.對象間通信

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

可以通過自定義的事件系統(tǒng)來實現(xiàn)（這里就不說了）

6.數(shù)學計算
共享計算輸出谐鼎，讓多個對象共享某些計算的結(jié)構(gòu)
（比如：從文件讀取數(shù)據(jù)，解析數(shù)據(jù)趣惠，AI尋路等等）
只計算一次結(jié)果狸棍，然后將結(jié)果分發(fā)給需要它的每個對象身害，以最小化重新計算的量

7.場景和預制體加載等反序列化
Untiy的序列化主要用于場景、預制件草戈、ScriptObjects和各種資產(chǎn)類型（派生自ScriptObject）塌鸯。
當其中一種對象類型保存到磁盤時，就是用 YAML （Yet Another markup Language唐片，另一種標記語言）格式將其轉(zhuǎn)換為文本文件丙猬，稍后可以將其反序列化成原始對象類型

當構(gòu)建好了應用程序時，這些序列化的數(shù)據(jù)會捆綁在大型二進制數(shù)文件中费韭，這些文件在Unity中被稱為序列化文件
運行時從磁盤讀取和反序列化數(shù)據(jù)是一個非常慢的過程茧球，因此所有反序列化活動都有一定的性能成本

一般發(fā)生在資源加載時候（Resources.Load())，一旦數(shù)據(jù)從磁盤加載到內(nèi)存中星持，以后重新加載相同的引用會快很多抢埋，但是在第一次訪問的時候總是需要磁盤活動。

注意：
如果需要反序列化的數(shù)據(jù)集越大钉汗，此過程所需的時間就越長
預制件的每個組件都是序列化的羹令，因此層次結(jié)構(gòu)越深，需要反序列化的數(shù)據(jù)就越多（空的也算）

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

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

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

b.異步加載序列化對象
可以把從磁盤讀取的任務轉(zhuǎn)移到工作線程上，從而減輕主線程的負擔

c.在內(nèi)存中保存之前加載的序列化對象
一旦加載到內(nèi)存中辽社，復制下來伟墙，下一次加載就會很快
缺點就是需要大量的內(nèi)存，是一種風險策略

d.將公共數(shù)據(jù)轉(zhuǎn)移出去
如果很多預制件都有一些共享數(shù)據(jù)滴铅，可以提取到一個配置文件中戳葵，然后再加載使用它。

對于場景的資源的優(yōu)化：
疊加汉匙、異步加載場景
1.同步加載場景拱烁，主線程將阻塞，直到指定的場景加載完成噩翠，用戶體驗非常糟糕
2.使用異步加載可以有效緩解戏自，同時讓玩家繼續(xù)操作
3.也可以疊加逐漸加載(LoadSceneMode.Additive)，讓場景逐漸加載出來伤锚，并且不會對用戶體驗造成明顯影響

8.使用合適的數(shù)據(jù)結(jié)構(gòu)
常見的性能問題就是：
為了簡單擅笔，但是用了不適當?shù)臄?shù)據(jù)結(jié)構(gòu)來解決問題

a.如果希望遍歷一組對象，最好使用列表（List）
其是動態(tài)數(shù)組，對象在內(nèi)存中彼此相鄰猛们，迭代導致的緩存丟失最小
b.如果希望快速獲取念脯、插入或者刪除，最好使用字典
其能通過hash快速映射阅懦？

如果有希望快速找出對象和二，同時還能遍歷組應該咋辦呢？
a.如果使用字典耳胎，然后再對它進行遍歷
遍歷的過程將會非常慢惯吕，因為必須檢查字典中每個可能的散列，才能對其進行完全遍歷
b.最好使用額外內(nèi)存開銷 維護一個字典和一個列表
雖然在插入刪除有些麻煩怕午，但在迭代的時候會產(chǎn)生明顯的優(yōu)勢

9.禁用未使用的腳本和對象
如果場景特別大的話废登，Update() 回調(diào)越多 游戲性能也就越不差
（除了一些特別仿真的游戲）

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

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

b.通過距離禁用對象
一般離玩家足夠遠的話兆蕉， 玩家并不關(guān)注他們羽戒，此時可能希望禁用他們
只需自己判斷距離即可

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