CocosCreator客户端优化系列（二）：渲染优化

CocosCreator客户端优化系列（二）：渲染优化

转载请保留原文链接：https://blog.csdn.net/zzx023/article/details/85319733

渲染方面优化主要集中在如何降低draw call上，draw call越多，渲染的压力也就越大，对应的帧率可能就会下降，正常情况下如果draw call超过100就有可能带来卡顿，所以要注意这方面的优化

自动图集批处理

这方面相关的官方文档比较少，可以参考：BMFont 与 UI 合图自动批处理，但需要注意，这个文档比较旧了，现在新版本的情况都没有更新上去，只能参考一下。

draw call是openGL的描绘次数
一个简单的openGL的绘图次序是：设置颜色→绘图方式→顶点座标→绘制→结束。
每帧都会重复以上的步骤。这就是一次draw call
通常每一张图片都是一个纹理，一次draw call

如果有两个纹理，那么就需要两次draw call

自动图集批处理所做的事情就是将两张图片放在一张纹理里面进行绘制，这样的话每帧就只有1个draw call

目前creator的自动图集批处理机制为，根据节点renderCmd的顺序，将相邻顺序的所需纹理放入到同一个批次进行处理。实际表现的话大致可以理解为节点树中相邻的节点会进入同一批次。

例如下面这样，场景中只有一个单色精灵时，它的draw call就为1。（这里解释一下为什么左下角显示为2，这是因为左下角的信息显示也需要一次draw call，本文后面所说的drawcall都是去掉这个fps显示draw call的数量）

下面这个渲染了2个纹理，3个精灵节点，同样draw call也是1，这就是因为自动图集批处理将2个纹理进行了合并处理，将原本需要2个draw call才能完成的事情合并成1个draw call

以上就是关于draw call和自动图集批处理的简单介绍。

那在实际的项目过程中，既然已经有了自动图集批处理的机制，为何我们的draw call还居高不下？
这是因为并不是所有的纹理都可以放到自动图集批处理中。

使用自动图集批处理有几个限制：
1、单图尺寸小于512512并且大于88
2、渲染buffer必须为MeshBuffer类型的资源才能批处理
3、对节点部分特殊的操作不能进入批处理

第1点比较好理解，第2点的话需要各位自己去看引擎关于各个renderComponent的源码了。
像bmfont label和sprite都是MeshBuffer，所以它们可以进入到批处理中。而像9ScaleSprite，Spine这些所使用的为QuadBuffer，因此没办法进行批处理。

上面记住第1条就好，其他的感兴趣自己可以去研究研究，这里总结了一个表：