四、動靜分離

動靜分離就是說同一個界面下的UI，可活動的元素(血條，藍條，傷害數字，CD)放在一個Canvas下，不可活動的元素(人物頭像，商城，和平，抽獎等按鈕)放在另一個Canvas下。雖然兩個Canvas打斷了合批，但是卻減少了網格的重建時間，總體上是有優化的。

為什么要避免網格重建那? 如果重建的網格過大，就會很卡。比多一個drawcall還卡。

假如同一個Canvas里面有100個Image，Canvas將會把100個單獨的Mesh合并成一個大的ShareMesh，用于渲染。

如果剛好這100個Image都是使用了相同的圖片或者是同一個圖集里面的圖片，那么由于使用的Mesh只有一個(ShareMesh)，假如UI元素非常多，ShareMesh可能有2M大小(這是一個比較極端的例子，實際上一般的ShareMesh都是幾百K，出現這么大的ShareMesh本身就需要注意了)，材質球都是同一個(內置的默認材質球)，貼圖也是同一張，所以得到的結果就是，DrawCall只有一個。

如果這個100個Image是不會動的，合并ShareMesh沒有太大的問題

但是如果是上面的血條，藍條，名字板，CD,文字聊天信息這些需要動的UI元素和其他UI元素合并同一個ShareMesh的，那么問題就來了，血條由長變短，頂點發生了改變，導致2M的整體ShareMesh也需要重新的生成頂點信息，并且整個ShareMesh重新渲染，這明顯是得不償失的。

當然動態的UI還包括文字部分，其中Text是UGUI產生頂點數量的重災區，一個字符產生4個頂點，如果再加上Shadow則相當于又把Text復制了一遍產生8個，

Outline則會將Text復制4遍產生20個頂點。所以Shadow、Outline不但會產生額外的OverDraw外還會產生過多的頂點數，

一定慎用，確實需要請選擇用圖片背景替代，其次選擇相對較省的Shadow。

五、動態圖集

所謂動態圖集，就是圖集是在游戲運行過程中生成的，而不是在游戲制作階段生成的。程序生成一張或n張較大的Texture圖集(根據項目需求，可以設置Texture大小為1024*1024或2048*2048等等)，Image加載進來的Texture不直接使用，而是將Texture信息按照一定規則和排列拷貝到這張Texture上，以達到n個Image共用一張Texture，合并Draw Call的目的，同時Image銷毀不用之后，Texture信息從大的Texture圖集中移除，達到圖集空間重復利用的目的。

什么時候需要打動態圖集那?

我們先來看看靜態圖集的缺點:

1、如果某個界面只需要出現一個圖集中包含的小圖標(比如掉了一個物品，學會某種技能)，這個小圖片是包含在一個大的靜態圖集里的，那為了顯示一個很小的圖標，就得加載一個很大的圖集，從而導致打開該界面很慢(由于加載大的圖集)。

并且后期熱更新的時候，如果修改或者添加一張圖片資源，那么就意味著要更新整個圖集的資源。

2、那打成多靜態個圖集那?這樣只有一個圖標的界面沒問題了。有多個圖標出現的界面就有問題了，加載的也多，drawcall也多，并且為了合并Draw Call不被打斷，要小心地設置UI的層級，避免ABA問題造成合批被打斷，操作復雜度就提高了。

物品圖標打了多個圖集

一個界面顯示多種物品圖標

下面demo只是簡單的演示一下動態圖集的主要思路，圖片分配算法也只是將大圖片分成64x64的一個一個分區，每個分區采用引用計數開控制是否在使用圖片，用于維護整個UI系統的話，這種算法并不適用，但是如果只是用于icon圖標的話，由于icon圖標是固定尺寸的，所以這套算法就很合適了。

動態圖集的缺點：當然動態圖集也是有缺點的

1、動態圖集因為將圖集的生成過程延遲到了游戲運行時，所以必然會比靜態圖集多了圖集生成的成本，當然這也是可以優化的。

2、并且在目前的動態圖集生成方案中，還沒有出現公開的支持壓縮的動態圖集解決方案。

3、還有一點，靜態圖集由于圖片在生成過程中是確定的，可以將分配算法做得很好，圖集的利用率也能做到很高。動態圖集由于圖片是動態生成的，在游戲運行過程中也會動態的增減圖片，類似操作系統的內存分配算法，圖集必然會出現碎片，圖集的利用率也不可能做得很高

總之， 如果能把以上五個方面都做到了，那么UI的優化就不成問題。當然有的項目不需要都做到，做到其中幾部分就可以了。也有的項目需要做的比 上面的還多。這都得具體問題具體分析，如果游戲中3D場景，人物，特效部分優化做的好，那么UI的壓力就小點，如果3D部分優化的不好，那么UI的壓力就大點，需要優化的東西就多些。