四、動(dòng)靜分離

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

為什么要避免網(wǎng)格重建那? 如果重建的網(wǎng)格過大，就會(huì)很卡。比多一個(gè)drawcall還卡。

假如同一個(gè)Canvas里面有100個(gè)Image，Canvas將會(huì)把100個(gè)單獨(dú)的Mesh合并成一個(gè)大的ShareMesh，用于渲染。

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

如果這個(gè)100個(gè)Image是不會(huì)動(dòng)的，合并ShareMesh沒有太大的問題

但是如果是上面的血條，藍(lán)條，名字板，CD,文字聊天信息這些需要?jiǎng)拥腢I元素和其他UI元素合并同一個(gè)ShareMesh的，那么問題就來了，血條由長變短，頂點(diǎn)發(fā)生了改變，導(dǎo)致2M的整體ShareMesh也需要重新的生成頂點(diǎn)信息，并且整個(gè)ShareMesh重新渲染，這明顯是得不償失的。

當(dāng)然動(dòng)態(tài)的UI還包括文字部分，其中Text是UGUI產(chǎn)生頂點(diǎn)數(shù)量的重災(zāi)區(qū)，一個(gè)字符產(chǎn)生4個(gè)頂點(diǎn)，如果再加上Shadow則相當(dāng)于又把Text復(fù)制了一遍產(chǎn)生8個(gè)，

Outline則會(huì)將Text復(fù)制4遍產(chǎn)生20個(gè)頂點(diǎn)。所以Shadow、Outline不但會(huì)產(chǎn)生額外的OverDraw外還會(huì)產(chǎn)生過多的頂點(diǎn)數(shù)，

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

五、動(dòng)態(tài)圖集

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

什么時(shí)候需要打動(dòng)態(tài)圖集那?

我們先來看看靜態(tài)圖集的缺點(diǎn):

1、如果某個(gè)界面只需要出現(xiàn)一個(gè)圖集中包含的小圖標(biāo)(比如掉了一個(gè)物品，學(xué)會(huì)某種技能)，這個(gè)小圖片是包含在一個(gè)大的靜態(tài)圖集里的，那為了顯示一個(gè)很小的圖標(biāo)，就得加載一個(gè)很大的圖集，從而導(dǎo)致打開該界面很慢(由于加載大的圖集)。

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

2、那打成多靜態(tài)個(gè)圖集那?這樣只有一個(gè)圖標(biāo)的界面沒問題了。有多個(gè)圖標(biāo)出現(xiàn)的界面就有問題了，加載的也多，drawcall也多，并且為了合并Draw Call不被打斷，要小心地設(shè)置UI的層級(jí)，避免ABA問題造成合批被打斷，操作復(fù)雜度就提高了。

物品圖標(biāo)打了多個(gè)圖集

一個(gè)界面顯示多種物品圖標(biāo)

下面demo只是簡單的演示一下動(dòng)態(tài)圖集的主要思路，圖片分配算法也只是將大圖片分成64x64的一個(gè)一個(gè)分區(qū)，每個(gè)分區(qū)采用引用計(jì)數(shù)開控制是否在使用圖片，用于維護(hù)整個(gè)UI系統(tǒng)的話，這種算法并不適用，但是如果只是用于icon圖標(biāo)的話，由于icon圖標(biāo)是固定尺寸的，所以這套算法就很合適了。

動(dòng)態(tài)圖集的缺點(diǎn)：當(dāng)然動(dòng)態(tài)圖集也是有缺點(diǎn)的

1、動(dòng)態(tài)圖集因?yàn)閷�圖集的生成過程延遲到了游戲運(yùn)行時(shí)，所以必然會(huì)比靜態(tài)圖集多了圖集生成的成本，當(dāng)然這也是可以優(yōu)化的。

2、并且在目前的動(dòng)態(tài)圖集生成方案中，還沒有出現(xiàn)公開的支持壓縮的動(dòng)態(tài)圖集解決方案。

3、還有一點(diǎn)，靜態(tài)圖集由于圖片在生成過程中是確定的，可以將分配算法做得很好，圖集的利用率也能做到很高。動(dòng)態(tài)圖集由于圖片是動(dòng)態(tài)生成的，在游戲運(yùn)行過程中也會(huì)動(dòng)態(tài)的增減圖片，類似操作系統(tǒng)的內(nèi)存分配算法，圖集必然會(huì)出現(xiàn)碎片，圖集的利用率也不可能做得很高

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