这的确是一个可行的方案，相当于之前的 global z order，目前为了引擎核心层的简单干净，我们去除了这个概念，在渲染层重构的过程中，是有可能加入这个功能的。
嗯 因为我发现 按照现在架构， 在实际 应用上，在ui这一块 基本没有几个能合并 的drawcall
还是跟场景结构有关 很典型的 排版 一张图片 一个label 这两个节点挂 在一个你物件上，成为一个item 如果有隐藏显示的逻辑 肯定是直接隐藏父节点，如果为了合并drawcall而不得不把所有的item拆开来 图片放一起 label放一起，那么逻辑会非常混乱
你的文字只要是 bmfont 是可以合并的
我现在在尝试自己添加个Depth到CCNode的属性中 如何让这个属性在Cretor编辑器中显示出来?
目前自己改造了一版，大致思路就是 node可以设置为合并drawcall的父节点，其下的子节点RenderCommand 按照 depth 排序，同一个depth的 按照贴图调整顺序，这里同一贴图的保证还是按之前的场景树中的顺序。
@panda 借楼提两个问题
1、cocos2dx中对于drawcall的控制是否要达到unity中那么严格
其他的程序说在做UNITY项目的时候，drawcall是能省则省。但是我做cocos的项目时觉得文字稍微多占一些drawcall对于帧率并没有影响。
2、使用ugui的drawcall合并规则（如果两节点之间的其他节点与这两节点不重叠，则可尝试合并drawcall），这样的规则是否会提高性能，还是在判断矩形是否重叠时反而会让性能降低？
- drawcall 一定会对性能有影响，文字你觉得影响不大可能是因为填充率不高，所以占用的损耗不高，但损耗一定存在。
- ugui 那种合并 draw call 的策略在 creator 中目前还不支持
ugui 什么时候优化到这地步了？
谢谢回答。
关于第二个问题，ugui的drawcall合并思路，是否一定会提高性能？因为我想着 如果要判断的矩形过多，对于cpu来讲消耗也是比较大的。是否还需要配合例如“是否是静态ui”之类的判断，才能发挥出效果？
反正我试了最新版是这样的。
我在想的是不是可以吧labelttf，或者系统label预生成贴图，然后就可以跟bmFont一样合并了。。
不错~~~~
贼TM先进，静态UI这个方法不错，但是我看到Creator的roadmap里有个多个节点合并成一张贴图的功能，不知道跟这个的区别。
那背包怎么处理？？？
官方是不是可以考虑出个方案优化一下drawcall合并了啊
NGUI制作背包等有大量物品图片的界面时候如何优化Drawcall？ - 权然的回答 - 知乎
https://www.zhihu.com/question/26022356/answer/136778658
这位老哥的处理看起来比较靠谱
了解了DrawCall之后如何帮助实践：