UGUI drawcall合并

UGUI drawcall合并原理

高数量的drawcall带来的坏处不用多说了，本篇重点说的是UGUI是如何合并drawcall的。 通过这篇博客，你将学会如何精算一个UGUI界面到底有几个drawcall，并且能想象出各UI控件的渲染顺序（即Frame Debugger窗口里的渲染顺序）。
以下案列的unity版本：

##一、 概念篇
在学习本篇之前，你需要了解以下几个名词。

bottomUI

A是B的bottomUI需要满足：(单条只是必要条件，1、2、3合起来才是充分条件）

1. B的mesh构成的矩形和A的mesh构成的矩形有相交，注意不是RectTransform的矩形相交，这点需要认真理解一下，下面给出一组案列帮助大家理解。
2. A.siblingIndex < B.siblingIndex (即在Hierachy里A在B之上）
3. 如果B有多个UI满足1、2条规则，则B的bottomUI应取siblingIndex差值的绝对值最小的那个（有点绕哈，depth的案例有这种情况）

黑色的线框即是mesh的矩形了，上图的Text组件和image组件是没有相交的，但注意他们的RectTransform其实是已经有相交了。此时，Text组件不能算作Image组件的bottomUI，因为不满足第1条。

合批

当两个UI控件的材质球的instanceId（材质球的instanceId和纹理）一样，那么这两个UI控件才有可能合批

depth

depth是UGUI做渲染排序的第一参考值，它是通过一些简单的规则计算出来的。 在理解了bottomUI的基础上，depth就很好算了。先给出计算规则：

下面给出一个案例来帮助理解:

根据树的深度优先遍历，容易得到UI节点遍历顺序：I1、T1、I2、R2、R1
根据depth的计算规则，得到每个UI控件的depth值

UI控件名称	depth值	说明（I=Image、T=Text、R=RawImage）
I1	0
T1	1
I2	2	I2的bottomUI是T1，且两者的mesh有相交，还不能合批，所以I2.depth = T1.depth + 1 = 1 + 1 = 2
R2	2	先来确定R2的bottomUI应该是I2，而非I1，因为依据bottomUI规则的第3条，R2.siblingIndex - I2.siblingIndex = 1,R2.siblingIndex - I1.siblingIndex = 3。然后R2和I2能够合批（为什么能够合批，后文会做解释），所以 R2.depth = I2.depth = 2
R1	2

这样就算出了各个UI控件的depth值了。
不要以为 I2 和 R2 的控件类型不一样就不能合批了，UGUI的渲染引擎不会去考虑两个UI控件类型是否一样，它只考虑两个UI控件的材质球及其参数是否一样，如果一样，就可以合批，否则不能合批。而实际项目中，我们往往都会认为一个RawImage就会占用一个drawcall，其实这个说法只是一种经验，并不完全正确。因为我们使用RawImage的时候都是拿来显示一些单张的纹理，比如好友列表里的头像，如果这些头像都是玩家自定义上传的头像，往往互不相同，当渲染到RawImage的时候，就会导致头像的材质球使用的纹理不同而导致不能合批而各占一个drawcall。但如果是使用的系统头像，那么就可以让两个使用了相同系统头像的RawImage合批。我们这个案例，I2和R2使用的材质球（Default UI Material) 和 纹理（Unity White）都是一样的，所以能够合批。

材质球ID

材质球的 InstanceID

纹理ID

纹理的InstanceID

二、排序and计算drawcall 数

有了上面的数据，UGUI会对所有的UI控件(CanvasRenderer)按depth、材质球ID、纹理ID做一个排序，那么这些字段的排序优先级也是有规定的：

给出一个案列来帮助理解：

UI控件名称	使用的材质球	使用的纹理
I1	M_InstID_Bigger	texture_InstID_Smaller
I2	M_InstID_Smaller	texture_InstID_Smaller
R1	M_InstID_Bigger	texture_InstID_Bigger
T1	UI Default Matiaral(UGUI 默认材质球)	Font Texture(unity自带的一个字体纹理)

步骤1：先算各个UI控件的depth值

UI控件名称	depth值
I1	0
I2	0
R1	0
T1	1

步骤二：排序
1、**按depth值做升序排序。**得 I1、I2、R1、T1
2、**材质球ID排序。**因为 I1、I2、R1的depth值相等，那么再对他们进行材质球ID进行升序排序，得：
I2.materialID < I1.materialID = R1.materialID
所以经过材质球排序后：I2、I1、R1、T1
3、纹理ID排序。因为I1和R1的材质球ID相同，故需要进行纹理ID降序排序，得 R1.TexutureID > I1.TextureID
所以经过纹理排序后：I2、R1、I1、T1

至此，就把所有的UI控件都排好序了，得到了所谓的 VisibleList = {I2,R1,I1,T1}
用表格来表示：

UI控件名称	depth值
I2	0
R1	0
I1	0
T1	1

步骤三：**合批。**对depth相等的连续相邻UI控件进行合批（注意只有depth相等的才考虑合批，如果depth不相等，即使符合合批条件，也不能合批）。很显然，I2，I1，R1虽然他们depth相等，但不符合合批条件，所以都不能合批。

步骤四：**计算drawcall。**合批步骤完成后就可以计算drawcall数了，即drawcall count = 合批1 + 合批2 + … + 合批n = n * 1 = n (其中 合批i = 1）
所以这个案例的 drawcall count = 1 + 1 + 1 + 1 = 4。渲染顺序（就是我们最终排好序的顺序）是：先画 I2，其次 R1，其次 I1，最后T1。只要打开 Window > Frame Debugger 窗口就可以轻松验证，这里就不贴图了。

最后，希望想搞明白点的能动动手，自己建一个空工程，摆弄一些案例，利用本文的知识来自己算算drawcall数及推出UGUI的渲染顺序。最后经过反复的练习能够总结出一些用较少的drawcall来拼UI的规律。

下一篇，将探究臭名昭著的mask，看看它是不是真的那么不堪，还是我们了解的还不够！