Cocos Creator3.8 项目实战（八）2D UI DrawCall优化详解（上）
游戏开发的朋友都知道，在游戏开发过程中，DrawCall 是我们优化性能的一个非常重要的指标，直接影响游戏的整体性能表现，DrawCall数量越多，帧率会降低，能明显感觉到卡顿。
那今天我们就来聊一聊，2D UI DrawCall优化方法。
本文的主要内容： 什么是Draw call ？ Draw Call 中造成性能问题的原因是什么？以及在 Cocos Creator 项目中如何减少DrawCall？
一、Draw Call 介绍
1、什么是Draw Call？
通常我们把 CPU提交数据给GPU，向GPU下渲染命令的过程，称为DrawCall，也叫同一批次渲染。一次 Draw call 就代表一次图形绘制命令。
例如：
CPU调用DirectX中的DrawIndexedPrimitive命令，进行渲染的操作。
CPU调用OpenGL中的glDrawElement命令，进行渲染的操作。
2、Draw Call 中造成性能问题的原因？
CPU和GPU能并行工作，有一个命令缓冲区(Command Buffer)，命令缓冲区包含了一个命令队列，当CPU需要渲染对象时，它可以向命令缓冲区添加命令，而GPU完成了上次的渲染任务后，可以继续从命令队列里取出一个命令并执行。
从以上流程，可以看出，性能问题的原因有两个方面：
-
CPU 方面
CPU在每次调用Draw Call 之前， 需要向GPU 发送很多内容，包括数据、状态和命令等。
在这一阶段， CPU 需要完成很多准备工作，例如检查渲染状态等，一旦CPU 完成了这些工作， GPU 就可以开始本次的渲染。
如果Draw Call 的数量太多， CPU 就会把大量时间花费在提交Draw Call 上，造成CPU的性能瓶颈。
-
GPU 方面
由于CPU的频繁调用绘图指令，那么GPU 也会进行频繁的渲染状态切换。渲染状态就包括：纹理状态，Blend 模式，Stencil 状态，Depth Test 状态等等，也会带来GPU的性能消耗。
那么综合以上的原因，一个很显然的优化想法：就是通过批次合并（后面简称合批）来降低 Draw call 的调用次数。
合批的本质：在一帧的渲染过程中，保证连续节点的渲染状态一致，将尽可能多的节点数据合并一次性提交，从而减少绘图指令的调用次数，降低图形 API 调用带来的性能消耗，同时也可以避免 GPU 进行频繁的渲染状态切换。
需要注意：
由于我们需要在CPU 的内存中合并Draw Call，而合并的过程也需要消耗时间。
因此，合并技术更加适合于静态的物体，对于静态物体只需要合并一次即可。
当然，也可以对动态物体进行合并，但由于这些物体是不断运动的，每一帧都需要进行合并然后再发送给GPU，这对空间和时间都会造成一定的影响。
二、合批的条件
1、节点的 Layer 相同才能合批，不同的 Layer 之间不能合批
在游戏运行时，Cocos 引擎是按照节点树的渲染方式，即按层级顺序，从上往下由浅到深进行渲染。
理论上每渲染一张图像（文本最终也是图像）都需要一次 DrawCall。
例如：
下图（1），猜一下DrawCall 次数是多少？
DrawCall 次数结果是： 5
为什么是5呢？ 因为4个item 子对象，每一次都是一次drawcall, 再加上本身引擎有一次drawcall 。
下图（2），调整了一下排列顺序，猜一下DrawCall 次数是多少？
仅仅调整了一下顺序，将相同Layer的放在一起，drawcall 次数变成了4 。
因此，根据上面介绍的游戏渲染按顺序可知，合批的条件之一是：节点的 Layer 相同，不同的 Layer 之间不能进行合批。
2、部分组件无法合批，且会打断其他组件合批
需要进行分模块管理节点树布局，以达到更好的合批效果，无法合批的组件：
- 内置组件 Mask、Graphics 和 UIMeshRenderer 组件由于材质不同和数据组织方式的差异，无法与其他组件合批。
- TiledMap、Spine 和 DragonBones 这三个中间件组件遵循自己的内部合批机制。
了解了DrawCall的原理和合批的条件后，接下来就是今日的重点，2D UI DrawCall 优化方法有哪些？
三、2D UI DrawCall 优化方法有哪些？
1、Label 组件DrawCall 优化
（1）、 将要使用的文字制作成图片，然后使用自动图集或 TexturePacker 对文字图片合并到图集
比如游戏中常用的 26个英文字母 、 数字 0-9 ， 建议美术可以根据不同颜色、不同大小、不同风格分别制作一张文字图片。
（2）、Cache Mode 缓存类型的合理选择
官方 Cache Mode 说明：
| 类型 | 功能说明 |
|---|---|
| NONE | 默认值，Label 中的整段文本将生成一张位图。 |
| BITMAP | 选择后，Label 中的整段文本仍将生成一张位图，但是会尽量参与动态合图。只要满足动态合图的要求，就会和动态合图中的其它 Sprite 或者 Label 合并 Draw Call。由于动态合图会占用更多内存，该模式只能用于文本不常更新的 Label。此模式在节点安排合理的情况下可大幅降低 Draw Call，请酌情选择使用。 |
| CHAR | 原理类似 BMFont，Label 将以“字”为单位将文本缓存到全局共享的位图中，相同字体样式和字号的每个字符将在全局共享一份缓存。能支持文本的频繁修改，对性能和内存最友好。不过目前该模式还存在如下限制，我们将在后续的版本中进行优化： 1. 该模式只能用于字体样式和字号（通过记录字体的 fontSize、fontFamily、color、outline 为关键信息，以此进行字符的重复使用，其他有使用特殊自定义文本格式的需要注意）固定，并且不会频繁出现巨量未使用过的字符的 Label。这是为了节约缓存，因为全局共享的位图尺寸为 2048 * 2048，只有场景切换时才会清除，一旦位图被占满后新出现的字符将无法渲染。 2. Overflow 不支持 SHRINK。 3. 不能参与动态合图（同样启用 CHAR 模式的多个 Label 在渲染顺序不被打断的情况下仍然能合并 Draw Call） 4. 目前暂不支持 IsBold、IsItalic 和 IsUnderline 属性。 |
对上表的实践说明：
-
NONE 一个贴图单独创建一个文本贴图，不能重用，单个贴图占用一个drawcall，不参与动态合批。即使两个相同文本的label也不能合批渲染。
最佳实践：适用于用完即删且可能会频繁更新大批量文本的需求，如: 聊天功能。
-
BITMAP：动态合图只能往图集上加贴图，而不能继续重用上次的，更不会删除已经作废的子贴图，改变一次就多生成一张文字贴图添加到大小为 2048*2048的通用动态图集中。如果频繁使用动态的文字，则会占用大量内存。
最佳实践：适用内容不会改变的静态文本，如:界面标题
-
CHAR： 每个字符绘制一次，并添加到大小为2048*2048 的字符图集中，场景不切换时，纹理不会重建，因为纹理大小是有限的，
导致能显示的字符数也有限。最佳实践：适用频繁更新且文本字符内容有限的文本如:分数、倒计时
2、Sprite 组件 Drawcall 优化
对于 Sprite 组件，有静态合图和动态合图两种合批方案。
（1）、静态合图
静态合图就是在开发时将一系列碎图整合成一张大图。
图集对于 DrawCall 优化来说非常重要，但是并不是说，把所有图片不管三七二十一，全部打成图集就万事大吉了，这里面也有门道，胡乱打图集的话说不定还会变成负优化。
这个门道就是：尽量将处于同一界面（UI）下的相邻且渲染状态相同的碎图，打包成图集，才能达到减少 DrawCall 的目的。
整合成大图有两种方式：
-
使用手动图集资源
-
使用自动图集资源
以上两种整合大图的方式，在往期文章 CocosCreator3.8研究笔记（十）CocosCreator 图像资源的理解，有详细介绍，这里就不再细说。
（2）、动态合图
Cocos Creator 提供了 动态合图（Dynamic Atlas）的功能，能在项目运行时动态地将贴图合并到一张大贴图中。
当渲染一张贴图的时候，动态合图系统会自动检测这张贴图是否已经被合并到了图集（图片集合）中，如果没有，并且此贴图又符合动态合图的条件，就会将此贴图合并到图集中。
动态合图是按照 渲染顺序 来选取要将哪些贴图合并到一张大图中的，这样就能确保相邻的 DrawCall 能合并为一个 DrawCall。
动态合图遵循上述第二点的合批的条件。
启用、禁用动态合图
Cocos Creator 在初始化过程中，会根据不同的平台设置不同的CLEANUP_IMAGE_CACHE参数，当禁用 CLEANUP_IMAGE_CACHE 时，动态合图就会默认开启。
强制开启动态合图
macro.CLEANUP_IMAGE_CACHE = false;
dynamicAtlasManager.enabled = true;
强制禁用动态合图
dynamicAtlasManager.enabled = false;
注意：
(1)、这些代码请写在项目脚本中的最外层
不要写在 onLoad/start 等类函数中，才能确保在项目加载过程中即时生效。
否则如果在部分贴图缓存已经释放的情况下才启用动态图集，可能会导致报错。
（2）、只有纹理开启了 Packable 选项的精灵才能够参与动态合图，该选项默认开启。
