Unity GUI(uGUI)使用心得與效能總結

背景和目的

小哈接觸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]開啟。
Frame Debugger(Only in Unity5.0+)

使用該工具時，遊戲會暫停，然後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下會失效（待深入研究）。
Common UI Components

原理是這樣，但是實際用起來還需要一些技巧，遵循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層級合并規則與批次建置規則這一節。