大家好，又见面了，我是你们的朋友全栈君。
UGUI drawcall合并原理
高数量的drawcall带来的坏处不用多说了，本篇重点说的是UGUI是如何合并drawcall的。 通过这篇博客，你将学会如何精算一个UGUI界面到底有几个drawcall，并且能想象出各UI控件的渲染顺序（即Frame Debugger窗口里的渲染顺序）。 以下案列的unity版本：
##一、 概念篇 在学习本篇之前，你需要了解以下几个名词。
bottomUI
A是B的bottomUI需要满足：(单条只是必要条件，1、2、3合起来才是充分条件）
- B的mesh构成的矩形和A的mesh构成的矩形有相交，注意不是RectTransform的矩形相交，这点需要认真理解一下，下面给出一组案列帮助大家理解。
- A.siblingIndex < B.siblingIndex (即在Hierachy里A在B之上）
- 如果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，看看它是不是真的那么不堪，还是我们了解的还不够！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/191708.html原文链接：https://javaforall.cn
