背景和目的
小哈接觸Unity3D也有一段時間了，項目組在UI解決方案的選型一直是用的原生的uGUI，因此本人也是使用了一段時間的uGUI，在uGUI的使用方面積累了一些自己的經驗，在此進行一個記錄與總結。
本文接下來將會對uGUI的Runtime性能進行著重討論，其它的因素也很多而且很重要，但是一篇文章講清楚一件事就好了，文后會提供uGUI的最佳實踐與一些使用技巧，不想看全文的建議直接到最下面看杰倫，啊，不對，是結論。
影響uGUI性能的因素與檢查工具
游戲中的UI與其它游戲中的元素本質上是一樣的，相對來說的不同點在于，UI通常是由2D的圖片組合而成，會包含較多的透明元素與漸變元素，而且一般來說會顯示在屏幕的最頂層。
因此，從共同點上說，UI的Runtime性能消耗也可以劃分為CPU消耗、GPU消耗與內存消耗。其中對于每一部分的具體的消耗以及優化，有諸多大神在網絡上發表過文章，比如深入淺出聊Unity3D項目優化：從Draw Calls到GC。但是，總有一個大家都繞不開的點，那就是Drawcall，Drawcall數量直接影響了游戲的幀率，解決了Drawcall問題，應該算是解決了80%的問題，所以接下來就著重針對uGUI的特性講一講UI系統的Drawcall。
Unity 5.0在Drawcall查看方面有一個非常有用的工具，Frame Debugger，通過[Window->Frame Debugger]打開。
使用該工具時，游戲會暫停，然后Unity會將當前正在執行的一幀的內容緩存下來，其中所有Drawcall你都可以進行前進與后退操作，從而能夠從Drawcall級別分析開銷。所以沒有升級5.0的小伙伴趕緊升級啊。
此外，在用FD看UI性能時，有一個小竅門就是新開一個空的Scene，然后將你的UI Prefab拖到該空場景中，此時就不會受場景中其它物體的影響而只顯示UI的Drawcall了。
uGUI性能優化
講了那么多，開始進入正題。
在降低Drawcall方面，一個非常重要的概念就是Batch，因為一次Drawcall相當于CPU與GPU進行一次溝通的成本，如果CPU能一次多打包一些信息給GPU，那么Drawcall數量自然就下來了，這個打包傳輸信息給GPU的過程就叫做Batch，批處理。那么什么情況下這些信息可以打包呢？從uGUI的角度，如果你的UI中組件的材質與紋理均相同，這幾個組件就可以被Batch。在Image組件中，材質對應Source Image，紋理則對應Material；在Text組件中材質對應Font，紋理也是Material。以上對應大部分情況適用，在少部分特殊shader下會失效（待深入研究）。
原理是這樣，但是實際用起來還需要一些技巧，遵循Unity的一些渲染次序的規則，才能真正的實現性能優化。以下就一一進行討論。
打包圖集
上面有提到Source Image圖集，所謂的圖集，就是將好多張零碎的2D小圖片通過Unity自帶的Sprite Packer或第三方的Texture Packer合并到一張大圖，這樣做有幾大好處，
- 圖片尺寸為2的次冪時，GPU處理起來會快很多，小圖自己是做不到每張圖都是2的次冪的，但打成一張大圖就可以（浪費一點也無所謂）；
- CPU在傳送資源信息給GPU時，只需要傳一張大圖就可以了，因為GPU可以在這張圖中的不同區域進行采樣，然后拼出對應的界面。注意，這就是為什么需要用同一個Source Image圖集的原因，是Batch的關鍵，因為一個Drawcall就把所有原材料傳過去了，GPU你畫去吧。
但是顯然把所有圖片打成一張圖集是不合理的，因為這張圖可能非常大，所以就要按照一定規則將圖片進行分類。在分類思路上，我們希望做到Drawcall盡可能少，同時資源量也盡可能少（多些重用），但這兩者某種程度上是互斥的，所以折衷一下，可以遵循以下思路：
- 設計UI時要考慮重用性，如一些邊框、按鈕等，這些作為共享資源，放在1~3張大圖集中，稱為重用圖集；
- 其它非重用UI按照功能模塊進行劃分，每個模塊使用1~2張圖集，為功能圖集；
- 對于一些UI，如果同時用到功能圖集與重用圖集，但是其功能圖集剩下的“空位”較多，則可以考慮將用到的重用圖集中的元素單獨拎出來，合入功能圖集中，從而做到讓UI只依賴于功能圖集。也就是通過一定的冗余，來達到性能的提升。
P.S. 如果你用Unity自帶的Sprite Packer去打包圖集，那么你可能要在運行模式下才能看到效果。
Unity GUI層級合并規則與批次生成規則
uGUI的層疊順序是按照Hierarchy中的順序從上往下進行的，也就是越靠上的組件，就會被畫在越底部。所以UI就是這樣一層一層地疊上去畫出來的。當然這樣一個一個地畫效率肯定是不能接受的，所以要合并，要Batch，Unity自身就提供了一個算法去決定哪些層應該合并到一起，并以什么樣的順序進行繪制。所有相鄰層的可Batch的UI元素將會在一個Drawcall完成。接下來就來討論一下Unity的層級合并與計算算法。
Unity的UI渲染順序的確定有2個步驟，第一步計算每個UI元素的層級號；第二步合并相同層級號中可以Batch的元素作為一個批次，并對批次進行排序；
先從直觀的角度來解釋計算層級號的算法：如果有一個UI元素，它所占的屏幕范圍內（通常是矩形），如果沒有任何UI在它的底下，那么它的層級號就是0（最底下）；如果有一個UI在其底下且該UI可以和它Batch，那它的層級號與底下的UI層級一樣；如果有一個UI在其底下但是無法與它Batch，那它的層級號為底下的UI的層級+1；如果有多個UI都在其下面，那么按前兩種方式遍歷計算所有的層級號，其中最大的那個作為自己的層級號。
這里也給一下偽代碼，假設所有UI元素（拋棄層級關系）都按從上往下的順序被裝在一個list中，那么每個UI元素對應的層級號計算可以參考以下：
function CalLayer(List UIEleLst)
if(UIEleLst.Count == 0 ) return;
//Initial the first UI Element as layer 0
UIEleLst[0].layer = 0;
for(i = 1 ~ UIEleLst.Count){
var IsCollideWithElements = false;
//Compare with all elements beneath
for(j = i-1 ~ 0){
//If Element-i collide with Element-j
if(UIEleLst[i].Rect.CollideWith(UIEleLst[j].Rect)){
IsCollideWithElements = true;
//If Element-i can be batched with Element-j, same layer as Element-j
if(UIEleLst[i].QualifyToBatchWith(UIEleLst[j])){
UIEleLst[i].layer = UIEleLst[j].layer;
}
else{
//Or else the layer is larger
UIEleLst[i].layer = UIEleLst[j].layer + 1;
}
}
}
//If not collide with any elements beneath, set layer to 0
if(!IsCollideWithElements)
{
UIEleLst[i].layer = 0;
}
}
有了層級號之后，就要合并批次了，此時，Unity會將每一層的所有元素進行一個排序（按照材質、紋理等信息），合并掉可以Batch的元素成為一個批次，目前已知的排序規則是，Text組件會排在Image組件之前渲染，而同一類組件的情況下排序規則未知（好像并沒什么規則）。經過以上排序，就可以得到一個有序的批次序列了。這時，Unity會再做一個優化，即如果相鄰間的兩個批次正好可以Batch的話就會進行Batch。舉個栗子，一個層級為0的ImageA，一個層級為1的ImageB（2個Image可Batch）和一個層級為0的TextC，Unity排序后的批次為TextC->ImageA->ImageB，后兩個批次可以合并，所以是2個Drawcall。再舉個栗子，一個層級為0的TextD，一個層級為1的TextE（2個Text可Batch）和一個層級為0的ImageF，Unity排序后的批次為TextD->ImageF->TextE，這時就需要3個Drawcall了！（是不是有點暈，再回顧下黑體字）
以下的偽代碼有些偷懶，實在懶得寫排序、合并之類的，一長串也不好讀，幾個步驟列一下，其它諸位看上面那段文字腦補下吧...
function MergeBatch(List UIEleLst)
{
//Order the UI Elements by their layers and batch-keys,
//batch-key is a combination of its component type,
//texture and material info
UIEleLst.OrderBy(
(uiElement)=>{return this.layer > uiElement.layer
|| this.BatchKey() > uiElement.BatchKey()}
);
//Merge the UI Elements with same layer and batch-key as a batch
var BatchLst = UIEleLst.MergeSameElementsAsBatch();
//Make adjacent batches with same batch-key merged
BatchLst.MergeAdjacentBatches();
return BatchLst;
}
根據以上規則，就可以得出一些“擺UI”的技巧：
- 有相同材質和紋理的UI元素是可以Batch的，可以Batch的UI上下疊在一塊不會影響性能，但是如果不能Batch的UI元素疊在一塊，就會增加Drawcall開銷。
- 要注意UI元素間的層疊關系，建議用“T”工具查看其矩形大小，因為有些圖片透明，但是卻疊在其它UI上面了，然后又無法Batch的話，就會無故多許多Drawcall；
- UI中出現最多的就是Image與Text組件，當Text疊在Image上面（如Button)，然后Text上又疊了一個圖片時，就會至少多2個Drawcall，可以考慮將字體直接印在下面的圖片上；
- 有些情況可以考慮人為增加層級從而減少Drawcall，比如一個Text的層級為0，另一個可Batch的Text疊在一個圖片A上，層級為1，那此時2個Text因為層級不同會安排2個Drawcall，但如果在第一個Text下放一個透明的圖片（與圖片A可Batch），那兩個Text的層級就一致了，Drawcall就可以減少一個。
少用Mask
Mask對于uGUI性能來說是噩夢一般的存在，因為很可能因為這個東西，導致Drawcall數量成倍增長。
Mask實現的具體原理是一個Drawcall來創建Stencil mask(來做像素剔除)，然后畫所有子UI，再在最后一個Drawcall移掉Stencil mask。這頭尾兩個Drawcall無法跟其他UI操作進行Batch，所以表面上看加個Mask就會多2個Drawcall，但是，因為Mask這種類似“漢堡包式”的渲染順序，所有Mask的子節點與其他UI其實已經處在兩個世界了，上面提到的層級合并規則只能分別作用于這兩個世界了，所以很多原本可以合并的UI就無法合并了。
所以，在使用uGUI時，有一些建議：
- 應該盡量避免使用Mask，其實Mask的功能有些時候可以變通實現，比如設計一個邊框，讓這個邊框疊在最上面，底下的UI移動時，就會被這個邊框遮住；
- 如果要使用Mask時，需要評估下Mask會帶來的性能損耗，并盡量將其降到最低。比如Mask內的UI是動態生成的話（比如List組件），那么需要注意UI之間是否有重疊的現象。
總結
uGUI的性能其實涉及到的方面很多，這里列出來的只是目前能想到的，因為個人能力有限，可能出些紕漏。對于文中的一些建議，這里整理一下得出一些最佳實踐：
- 設計UI時要考慮重用性，如一些邊框、按鈕等，這些作為共享資源，放在1~3張大圖集中，稱為重用圖集；
- 其它非重用UI按照功能模塊進行劃分，每個模塊使用1~2張圖集，為功能圖集；
- 對于一些UI，如果同時用到功能圖集與重用圖集，但是其功能圖集剩下的“空位”較多，則可以考慮將用到的重用圖集中的元素單獨拎出來，合入功能圖集中，從而做到讓UI只依賴于功能圖集。也就是通過一定的冗余，來達到性能的提升。
- 有相同材質和紋理的UI元素是可以Batch的，可以Batch的UI上下疊在一塊不會影響性能，但是如果不能Batch的UI元素疊在一塊，就會增加Drawcall開銷。
- 要注意UI元素間的層疊關系，建議用“T”工具查看其矩形大小，因為有些圖片透明，但是卻疊在其它UI上面了，然后又無法Batch的話，就會無故多許多Drawcall；
- UI中出現最多的就是Image與Text組件，當Text疊在Image上面（如Button)，然后Text上又疊了一個圖片時，就會至少多2個Drawcall，可以考慮將字體直接印在下面的圖片上；
- 有些情況可以考慮人為增加層級從而減少Drawcall，比如一個Text的層級為0，另一個可Batch的Text疊在一個圖片A上，層級為1，那此時2個Text因為層級不同會安排2個Drawcall，但如果在第一個Text下放一個透明的圖片（與圖片A可Batch），那兩個Text的層級就一致了，Drawcall就可以減少一個。
- 應該盡量避免使用Mask，其實Mask的功能有些時候可以變通實現，比如設計一個邊框，讓這個邊框疊在最上面，底下的UI移動時，就會被這個邊框遮住；
- 如果要使用Mask時，需要評估下Mask會帶來的性能損耗，并盡量將其降到最低。比如Mask內的UI是動態生成的話（像List組件），那么需要注意生成的UI之間是否有重疊的現象；
- 有空好好看下Unity GUI層級合并規則與批次生成規則這一節。
