Ngui Draw Call 优化整理

1，什么是Drawcall

这个是绘制图像的重要指标，可以作为衡量场景绘制效率的首要参考。

一个 Draw Call，等于呼叫一次 DrawIndexedPrimitive (DX) or glDrawElements (OGL)，等于一个 Batch。

摸过 DirectX 或 OpenGL 的人来说，对 DrawIndexedPrimitive 与 glDrawElements 这 API 一定不陌生。当我们准备好资料 (通常为三角面的顶点资讯) 要 GPU 划出来时，一定得呼叫这个函式。换句话说，如果在画面上有一张 “木" 椅子、一张 “铁" 桌子，那理论上就会有两个 Draw Call。

有看到特别点出 “木" 与 “铁" 吗？这代表两物件是使用不同材质球或者不同的 Shader。在 DirectX 或 OpenGL 里，对不同物件指定不同贴图或不同 Shader 的描述，就会需要呼叫两次Draw Call。

每次对 Shader 的更动或者贴图的更动，基本上就是对 Rendering Pipeline 的设定做修改，所以需要不同的 Draw Call 来完成物件的绘制。现在了解为什么 Unity 官方文件里，老是要你尽量使用同样材质球，以减少 Draw Call 数量了吧！

再来谈到 Batch，其实也是 Draw Call 的另一种称呼。你可以想成每一次的 Draw Call 会产生一个 Batch，而 Batch 里装的是物件顶点资料，Batch 由 CPU 透过 “驱动程式” 将顶点资料送往 GPU，GPU接手后将物件画在画面上。由此可知，越多 Draw Call，CPU 就越忙碌。这下更清楚知道 Draw Call 数量所影响的是 CPU 效能而非 GPU。

NVIDIA 在 GDC 曾提出，25K batchs/sec 会吃满 1GHz 的 CPU，100的使用率。所以他们推出了一条公式，来预估游戏中大概可以 Run 多少个 Batch：

25K∗n(GHZ)∗Percentage/Framerate=Batch/Frame

举个例子：如果你的目标是游戏跑30FPS、使用2GHz的CPU、20š„工作量拨给Draw Call来使用，那你每秒可以有多少Draw Call呢？

333 Batchs/Frame = 25K * 2 * (0.2/30)

那既然 Batch 是个箱子，里头装着物件的顶点资料，再依据我们上面的描述，那表示同样材质或 Shader 的物件，可以合并成一个 Batch 送往 GPU，这样就是最省事的方法！

将N个纹理打包成一个图集，这个图集就只会产生一个DrawCall，如果不打成图集，那么就会有N个DrawCall，这个观点在很多人的认识里都是正确的，因为可以通过简单的操作来验证，但严格来说，这个观点是错误的，因为它还受层级关系影响！

2，DrawCall是和渲染顺序相关的

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

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

1.渲染A，使用材质1

2.渲染B，使用材质1

3.渲染C，使用材质2

在这种情况下是2个DrawCall

1.渲染A，使用材质1

2.渲染C，使用材质2

3.渲染B，使用材质1

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

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

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

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

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

1，场景中的东西，我们使用Z轴来进行空间的划分，例如背景层，特效层1，人物层，特效层2

2，NGUI中的东西，我们统一使用Depth来进行空间的划分

3，人物模型，当人物模型只是用一个材质，DrawCall只有1，但是用了2个以上的材质，DrawCall就会暴增（或许对材质的RenderQueue进行规划也可以使DrawCall只有2个，但这个要拆分好才行），3D人物处于复杂3D场景中的时候，我们的空间规则难免被破坏，这只能在设计的时候尽量去避免这种情况了

4，使用了多个材质的特效，在动画的过程中，往往会引起DrawCall的波动，在视觉效果可以接受的范围内，可以将特效也进行空间划分，假设这个特效是2D显示，那么可以使用Z轴来划分空间

3，打包图集相关

每个材质/纹理的渲染一定是会产生DrawCall的，这个DrawCall只能通过打包图集来进行优化

制作图集一般遵循几个规则：

1，从功能角度进行划分，例如UI可以划分为公共部分，以及每个具体的界面，功能上，显示上密切相关的图片打包到一起

2，不要一股脑把所有东西打包到一个图集里，特别是那些不可能同时出现的东西，它们就不应该在一个图集里，这样的图集意义不大，减少不了DrawCall，并且一个你不需要显示的图片，会一直占用你的内存，这让我非常不爽

注意控制图集的大小，不要让图集太大，一 个超级大图集的DrawCall消耗或许顶的上十几个小图集的消耗

3，字符图集，在使用BMFont或者其他工具生成图片字的时候，我们往往是直接导入一大串文字，然后直接生成图片，但实际上这上面的操作也有优化空间，例如BMFont生成的图片大小，是可以设置的，有两个规则， 一个规则是导出的图片尽量小，另一个是导出的图片尽量少，默认的大小应该是512×512，假设你生成的图片256×256就可以容纳，那么多做一个操作你可以节省这么多空间，另外当你输入多几个字，就导致增加一张图片时，例如1024变成2048，那么你可以考虑使用3张512的图片，这样也会节省空间