Unity优化之减少Drawcall

怼烎@ 2023-03-03 04:53 35阅读 0赞

简单来说，Drawcall就是屏幕渲染一次所需要的开销，为了较少消耗，提高性能.

什么是DrawCall以及如何对DrawCall进行优化操作。

# 一、什么是DrawCall？ #

在unity中，每次CPU准备数据并通知GPU的过程就称之为一个DrawCall。

具体过程就是：设置颜色-->绘图方式-->顶点坐标-->绘制-->结束，所以在绘制过程中，如果能在一次DrawCall完成所有绘制就会大大提高运行效率，进而达到优化的目的。

# 二、DrawCall为什么会影响效率？ #

说道为什么会影响效率，就首先要了解一下他的工作原理：为了CPU和GPU可以进行并行工作，就需要一个命令缓冲区，就是由CPU向其中添加命令，然后又GPU从中读取命令，这样就实现了通过CPU准备数据，通知GPU进行渲染。

在每次调用DrawCall之前，CPU需要向GPU发送很多内容，主要是包括数据，渲染状态（就是设置对象需要的材质纹理等），命令等。CPU进行的操作具体就是：

*  准备渲染对象，然后将渲染对象从硬盘加载到内存，然后从内存加载到显存，进而方便GPU高速处理
 *  设置每个对象的渲染状态，也就是设置对象的材质、纹理、着色器等
 *  输出渲染图元，然后向GPU发送DrawCall命令，并将渲染图元传递给GPU

所以如果DrawCall数量过多就会导致CPU进行大量计算，进而导致CPU的过载，影响游戏运行效率。

注意：

*场景中有100个gameobject,它们拥有完全一样的Material,那么这100个物体很可能会被Unity里的Batching机制结合成一个Batch。所以用“Batches”来描述Unity的渲染性能是不太合适的，它只能反映出场景中需要批处理物体的数量。那么可否用“Draw calls”来描述呢？答案同样是不适合。**每一个“Draw calls”是CPU发送个GPU的一个渲染请求**，请求中包括渲染对象所有的顶点参数、三角面、索引值、图元个数等，**这个请求并不会占用过多的消耗**，**真正消耗**渲染资源的是在GPU得到请求指令后，把指令发送给对应物体的Shader,让**Shader读取指令并通知相应的渲染通道（Pass）**进行渲染操作。*

*       我的上篇博文【U3D】[进入shader编程的世界][shader]里有简单介绍过Shader,不懂的童鞋可以去看看。接着上边的问题进行说明，场景上有1个gameobject，希望能显示很酷炫的效果，它的Material上带有许多特定的Shader。为了实现相应的效果，Shader里或许会包含很多的Pass,每当GPU即将去运行一个Pass之前，就会产生一个“SetPass call”，因此在描述渲染性能开销上，“SetPass calls”更加有说服力。 *

# 三、如何优化DrawCall？ #

> ### 1.渲染顺序：图集、材质、层级的处理 ###

想看这些如何进行优化，就需要对他们的工作原理进行理解一下。下面我们以NGUI为例，讲解一下他们之间的关系：

NGUI主要是有三大模块组成：UIPanel，UIWidget，UIDrawcall组成，其中UIPanel是用来管理UIWidget控件和UIDrawCall，而UIWidget是所有组件的基类。

在NGUI框架中，会有一个静态的list用来存放所有的Panel，然后每个单独的Panel下会保存自己的UIWidget和UIDrawCall，就是在每次绘制的时候panle会遍历自己下面的所有层级下的子物体，直到查找结束，或者遇到新的panel会跳出当前分支，继续寻找其他分支，直到全部查找结束。所以说在实际运行中，每次都会为一个UIWidget绘制一个DrawCall，如果这时候连续的多个UIWidget使用的材质和纹理一致，就会公用一个DrawCall，下面给大家看下具体的情形：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70][]

这是使用不同材质和纹理的情况

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 1][]

这是使用相同的材质和纹理的情况

所以并不是好多人的认知是只要同一个图集就会占用同一个DrawCall，通过上图分析发现**不光是要使用同一个图集，还要使用同样的材质在同一个panel下**才可以，否则就会重新进行调用一次DrawCall。另外需要注意的是，如果使用同一个图集、材质，但是**中间夹杂了其他的渲染状态，也会导致重新调用一次DrawCall**。

另外还需要注意一点就是在panel下如果动态的物体，就是为了实现某种效果，需要UI 进行位置移动，这种情况下，最好做成动态分离，因为只要panle下UI有移动，panle就会对清空之前的保存的UIWidget和UIDrawCall，重新进行渲染，这样就会造成性能浪费，有的同学会说这样不是增加了DrawCall吗，但是相对于每次都重新绘制，应该还是会更加节省性能的吧，你说呢?

所以说在对UI进行界面排布就需要对图集和层级做好规划，进而减少DrawCall次数。

**关于渲染顺序**

U3D的渲染是有顺序的，U3D的渲染顺序是由我们控制的，控制好U3D的渲染顺序，你才能控制好DrawCall

一个DrawCall，表示U3D使用这个材质/纹理，来进行一次渲染，那么这次渲染假设有3个对象，那么当3个对象都使用这一个材质/纹理的 时候，就会产生一次DrawCall，可以理解为一次将纹理输送到屏幕上的过程，（实际上引擎大多会使用如双缓冲，缓存这类的手段来优化这个过程，但在这 里我们只需要这样子认识就可以了），假设3个对象使用不同的材质/纹理，那么无疑会产生3个DrawCall

接下来我们的3个对象使用2个材质，A和B使用材质1，C使用材质2，这时候来看，应该是有2个DrawCall，或者3个DrawCall。 应该是2个DrawCall啊，为什么会有3个DrawCall？？？而且是有时候2个，有时候3个。我们按照上面的DrawCall分析流程来分析一 下：

1.渲染A，使用材质1  
2.渲染B，使用材质1  
3.渲染C，使用材质2

在这种情况下是2个DrawCall，在下面这种情况下，则是3个DrawCall

1.渲染A，使用材质1  
2.渲染C，使用材质2  
3.渲染B，使用材质1

因为我们没有控制好渲染顺序（或者说没有去特意控制），所以导致了额外的DrawCall，因为A和B不是一次性渲染完的，而是被C打断了，所以导致材质1被分为两次渲染

那么是什么在控制这个渲染顺序呢？首先在多个相机的情况下，U3D会根据相机的深度顺序进行渲染，在每个相机中，它会根据你距离相机的距离，由远到近进行渲染，在UI相机中，还会根据你UI对象的深度进行渲染

那么我们要做的就是，对要渲染的对象进行一次规划，正确地排列好它们，规则是，按照Z轴或者深度，对空间进行划分，然后确定好每个对象的Z轴和深度，让使用同一个材质的东西，尽量保持在这个空间内，不要让其他材质的对象进入这个空间，否则就会打断这个空间的渲染顺序

在这个基础上，更细的规则有：

场景中的东西，我们使用Z轴来进行空间的划分，例如背景层，特效层1，人物层，特效层2  
NGUI中的东西，我们统一使用Depth来进行空间的划分  
人物模型，当人物模型只是用一个材质，DrawCall只有1，但是用了2个以上的材质，DrawCall就会暴增（或许对材质的RenderQueue 进行规划也可以使DrawCall只有2个，但这个要拆分好才行），3D人物处于复杂3D场景中的时候，我们的空间规则难免被破坏，这只能在设计的时候尽 量去避免这种情况了  
使用了多个材质的特效，在动画的过程中，往往会引起DrawCall的波动，在视觉效果可以接受的范围内，可以将特效也进行空间划分，假设这个特效是2D显示，那么可以使用Z轴来划分空间

> ### 2.动态与静态合批 ###

批处理从字面意思就是一块处理多个物体的意思，但是是什么样的都可以进行批处理吗？答案就是使用同一个材质的物体才可以。unity中有个两种批处理方式，动态批处理和静态批处理。对于动态批处理来说，好处就是一切都是自动处理的，并且物体是可以移动的，但是限制颇多，具体有哪些限制下面会进行分析。对于静态批处理来说，好处就是自由度很高，限制条件少，但是它会占用更多的内存，并且经过批处理的物体不可以在进行移动。

首先说一下动态批处理，条件是物体使用同一个材质，并且满足对应的特定条件，unity就会自动为我们做动态批处理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 2][]

这里可以看到动态批处理中，四个物体但是只占用了三个DrawCall，就是unity进行了动态批处理，两个cube只占用了一个DrawCall。

下面说下动态批处理限制：

*  顶点属性最大限制900,
 *  使用lightmap的物体不行进行批处理
 *  使用MultiplePass的shader也不会进行批处理
 *  接受实时阴影的物体也不会进行批处理

下面说下静态批处理， 静态批处理前提当然也是使用了同一个材质，然后就是讲对应的对象设置为static：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 3][]

这时你会发现DrallCall变为1了，这就是静态批处理的作用，但是这时候你会发现VBO Total比刚才大了，这就是静态批处理坏处，通过内存来换取性能，下面我们看下官方的解释：

如果在静态批处理前有一些物体共享了相同的网格（例如这里的两个箱子），那么每一个物体都会有一个该网格的复制品，即一个网格会变成多个网格被发送给GPU。在上面的例子看来，就是VBO的大小明显增大了。如果这类使用同一网格的对象很多，那么这就是一个问题了，这种时候我们可能需要避免使用静态批处理，这意味着牺牲一定的渲染性能。例如，如果在一个使用了1000个重复树模型的森林中使用静态批处理，那么结果就会产生1000倍的内存，这会造成严重的内存影响。

**关于合批**

1.动态批处理

如果动态物体共用着相同的材质，那么Unity会自动对这些物体进行批处理。动态批处理操作是自动完成的，并不需要你进行额外的操作,你可以在buildsetting中设置他。

动态批处理是消耗2倍的内存来提升显示的速度，也就是空间换时间，如果内存消耗过大，需要考虑时间和空间的平衡。

如果发现动态批处理后DC并没有减少，你可以检查以下方面:

<1>批处理动态物体需要在每个顶点上进行一定的开销，所以动态批处理仅支持小于900顶点的网格物体。

<2>如果你的着色器使用顶点位置，法线和UV值三种属性，那么你只能批处理300顶点以下的物体；如果你的着色器需要使用顶点位置，法线，UV0，UV1和切向量，那你只能批处理180顶点以下的物体。请注意：属性数量的限制可能会在将来进行改变。

<3>不要使用缩放尺度（scale）。分别拥有缩放尺度(1,1,1)和(2,2,2)的两个物体将不会进行批处理。

<4>统一缩放尺度的物体不会与非统一缩放尺度的物体进行批处理。使用缩放尺度(1,1,1)和 (1,2,1)的两个物体将不会进行批处理，但是使用缩放尺度(1,2,1)和(1,3,1)的两个物体将可以进行批处理。

<5>使用不同材质的实例化物体（instance）将会导致批处理失败。

<6>拥有lightmap的物体含有额外（隐藏）的材质属性，比如：lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理（除非他们指向lightmap的同一部分）。

<7>多通道的shader会妨碍批处理操作。比如，几乎unity中所有的着色器在前向渲染中都支持多个光源，并为它们有效地开辟多个通道。

2.静态批处理

只要物体不移动，并且拥有相同的材质，那么就可以进行静态批处理。因此，静态批处理比动态批处理更加有效，你应该尽量低使用它，因为它需要更少的CPU开销。

为了更好地使用静态批处理，你需要明确指出哪些物体是静止的，并且在游戏中永远不会移动、旋转和缩放。想完成这一步，你只需要在检测器（Inspector）中将Static复选框打勾即可，如下图所示：

![20200730083635793.png][]

使用静态批处理操作需要2倍的内存开销来储存合并后的几何数据。

> ### 3.减少实时光和阴影 ###

同样的设置，但是如果你将灯光的阴影效果打开，你会发现DrawCall大幅增加：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 4][]

所以在项目中，如果想让场景更加完美，可以使用lightmap满足你想要的阴影效果。

综上所述就是要对图集进行和层级处理要做好整体规划，尽量将材质纹理合并，对于灯光的根据当前情况做好相应处理。

# 四、 UI优化Drawcall 与 Overdraw.  #

降低Drawcall, 主要是通过UGUI内部智能排序完成. 因此我们的优化方向主要是不要打乱UGUI排序的判定依据.  
能否排序的两个要点:

1. Z轴是否为0,

2. UI是否有重叠

优化点:

### ** 1. Z轴归零 ** ###

** **对象实例化后, Z轴不为0. 代码中强制为0.  
原理: Z轴不为0的UI, UGUI 不会对其自动排序.

### **2. 头像UI去除Mask, 降低DrawCall与Overdraw** ###

使用Custom Image 直接截取其UV 值, 而不是通过 Mask 对其图片进行截取.  
不但将降低了Mask 的DrawCall,  而且图形在网格部分保证了不会出现重叠导致UGUI 对其排序产生影响.

### **3. 优化会频繁Active 的界面** ###

在购买完英雄后, 会覆盖变灰的UI. 节点Recruited 会设置为True.   
现在将该节点长设为True, 然后透过透明度将该节点隐藏. 可提升设置该节点被设置为Active后照成的UI 合批中断与SetActive本身的消耗.

### **4.  Image 使用PolygonImage 代替** ###

对Buttom 的Image 使用PolygonImage 代替,因为尽管这个Image不显示. 但还是会产生DrawCall.   
   使用PolygonImage可以不产生UI 的 Mesh , 这样完全不产生任何渲染消耗

### **5**.    **FillCenter 勾选去除**. ###

对头像边框的Image控件中的FillCenter 勾选去除.  
由于9宫格头像边框中间是透明的, 因此中间部分不用渲染, 效果是一样的. 这样可以显著降低其Overdraw

### **6**.  **Raycast Target 勾选去除**. ###

对不参与交互的Image中的Raycast Target 勾选去除.

### **7. 回收减少UI 对象的创建数量** ###

回收角色对象上的UI,  减少该类对象的创建数量， 比如选人的特效

[shader]: https://blog.csdn.net/wdmzjzlym/article/details/51325811
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70]: /images/20230208/39c9f5af03474f2f954b91c9d5c4aa1d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 1]: /images/20230208/8c0adec46f9a4d4f9043d5362e1fa76a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 2]: /images/20230208/c8cd161049bf47439f3e5679510862b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 3]: /images/20230208/4bde059a796c4f9fae1a7503b7824f23.png
[20200730083635793.png]: /images/20230208/a2e4293e3462489dacbf1be0b6d8c372.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l1MTM2ODA3MjMzMg_size_16_color_FFFFFF_t_70 4]: /images/20230208/e772b963da4445188e495c6568248e0a.png