游戏开发的朋友都知道,在游戏开发过程中,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 选项的精灵才能够参与动态合图,该选项默认开启。