UGUI在合批之前，會根據ui的Depth、MatID 、ImgID、RendererOrder進行排序，之后對相鄰的UI進行檢測，判斷ImgID和MatID是否相同，如果相同則可以進行合批處理，如果這兩個UI的MatID和ImgID都相同，但是不連續，中間有其他不同MatID或ImgID的UI則會打斷合批。
Depht排序：
先篩選掉Depht為-1的值，這部分默認不渲染
接着判斷是否該元素底部是否有物體，如果沒有則賦值Depth為0，如果蓋住物體（這塊是通過Mesh進行判斷，判斷Mesh是否相交）則等於底部蓋住的UI元素中Depth最大的值+1、
如果兩個相鄰元素通過了合批測試，則這兩個相鄰元素的深度值相等。
深度排序之后，就會根據matID進行排序，如果材質相同則對ImgID進行排序，如果也相同，那會根據inspection面板上的RendererOrder，最后真正進行UI的合批。
如圖示：
hierrchy面板順序如圖
drawCall如下：
可以看到是5個，因為文本打斷了Depth的合批。
在Debug Frame里我們可以清楚的看到他有3個DrawMesh
那只需要將hierrchy的順序修改到最后，我們看會發生什么。
hierrchy面板順序如圖：
drawCall如下：
降為了4，代表三張image進行了合批。
用FrameDebug也可以清楚的看到優化是成功的。
特殊情況：
下面我們在看一個特殊的案例
請注意面板上的順序，按我們理解的情況看，他應該排序后的順序是：文本，圖片，圖片，之后因為兩個圖片的材質一致所以能夠進行合批。
但是通過frameDebug我們發現，實際上順序卻是：圖片，文本，圖片這樣的順序，那這是為什么呢，我們更進一步，通過Profiler的UI的modules來看具體的細節
給出的原因是貼圖不同，目前兩個圖片的貼圖都是Nil，那我們嘗試修改兩張圖片的貼圖
之后我們再觀察會發現
這里的順序就是我們預期的順序文本，圖片，圖片了，那為什么會發現這種問題呢，是因為在默認情況下，排序了depth之后，這兩個層級相同，就會比較matID，image和text的默認材質都是ui defult，mat也一致，在比較TextureID時，img為nil比默認的Text的TextureID小，所以排序在了text前，但是替換了貼圖后，圖片的TextureID大於Text的TextureID，下面的顯示就達到了預期的效果。
這節分享就到這里，下節我們繼續聊聊Mask對合批的影響