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，下面的显示就达到了预期的效果。
