1界面：使用写真集，降低drawcall
批处理：批渲染
基本原理是将几个呈现状态一致的物体合成为一个大物体，然后一次提交给gpu进行绘制
如果不退格，就必须多次提交。 这可以显著节约绘制调用。 事实上，这主要是节约cpu的时间。 从多次提交到提交，cpu对gpu来说也不需要多次切换渲染状态。
当然batch可以的前提必须是渲染状态一致的一组物体。
简单地说，使用软件将写真集移到大照片上，DrawCall就会下降
这里推荐以下软件：
纹理包，自由版本有水印。 ***
2机型：
批量生产前序也影响DrawCall的动态批处理
首先，创建了几个基本的Prefab、Capsule、Cube、Cylinder和Sphere。
1无论加载顺序如何，Capsule、Sphere都无法动态批处理。 Unity无法批处理，因为两个Prefab的顶点数超过300个。
2连续加载两者都可以批处理的Prefab时，无论采用哪种加载方式，都会动态进行批处理
3如果同时加载可批处理的Prefab，或者加载不可批处理的Prefab，则加载顺序的差异会影响DrawCall
在41个循环中同时加载两个Prefab。 在这里，您可以看到Cube没有动态批处理
4.1-----------------请参阅
5 :10个Cube调用一次动态批处理，但10个球调用10次。 总的批处理次数合计为11次，可以节约9次批处理。。
关于UGUI的DrawCall的一些转载：
从UGUI的角度看，如果UI中组件的材质和纹理相同，则可以对这些组件进行Batch。
向GPU发送资源信息时，CPU只需传递大图即可。 因为GPU可以在此图的不同区域进行采样，并创建相应的接口。 所以你需要用同样的Source
1
Image阿特拉斯的理由是Batch的关键。 只要一个Drawcall就能传递所有的素材，请GPU画画。
但是，把所有的图像都变成一张写真集显然是不合理的。 这张图可能非常大，所以必须按照一定的规则对图像进行分类。 在分类方面，我们希望尽量减少Drawcall，同时也尽量减少资源量，但这两者在某种程度上是互斥的，所以权衡后可以遵循以下思路。
1
必须考虑一些边框和按钮等的复用性来设计用户界面。 这些作为共享资源，放置在1~3张大写真集中，被称为再利用写真集。
1
其他非重用UI按功能模块划分，每个模块使用一到两张插图集，为功能插图集；
1
根据UI的不同，如果同时使用功能映射集和重用映射集，且功能映射集的其馀“空闲”较多，则可以单独提取要使用的重用映射集中的元素并将其合并到功能映射集中，从而使UI仅依赖于功能映射集也就是说，通过一定的冗馀性来提高性能。
1
一旦有了层次结构编号，就合并批次。 在这种情况下，Unity将每个层次的所有元素都放在一个排序中。 根据材质、纹理等信息，将可Batch元素合并为一个批次。 当前已知的排序规则是将Text组件并排呈现在Image组件之前，但对于同一类组件，排序规则是未知的。 好像没有规则。 经过以上顺序，可以得到有序的批量顺序。
在这种情况下，Unity还会进行另一种优化：如果两个相邻批次正好可以进行Batch，则进行Batch。
1
举个板栗，0级ImageA、1级imageb (两个image可以Batch )、0级TextC、Unity排序后的批次为TextC-ImageA-ImageB，后面两个批次可以合并
1
举个板栗吧。 0级文本、1级文本(两个文本可堆栈)、0级ImageF和Unity排序的批处理为TextD-ImageF-TextE。 此时，需要3个绘制调用。 )是不是有点头晕？ 让我们再回顾一下黑体字。
1
不使用掩码
对于uGUI的性能来说，掩码就像噩梦一样。 因为这样很可能会使Drawcall的数量翻倍。
Mask实现的具体原理是用于创建Stencil的绘制调用
mask (像素剔除)，绘制所有子UI，然后在最后一次绘制调用中删除Stencil mask。
由于这头尾两个Drawcall无法与其他UI操作进行Batch，因此表面上添加遮罩会增加两个Drawcall。
但是，由于Mask的“像汉堡一样”呈现顺序，所有Mask的子节点和其他UI实际上已经存在于两个世界中。
上述水平
合并规则只能分别作用于这两个世界了，所以很多原本可以合并的UI就无法合并了。1
所以，在使用uGUI时，有一些建议：
1
应该尽量避免使用Mask，其实Mask的功能有些时候可以变通实现，比如设计一个边框，让这个边框叠在最上面，底下的UI移动时，就会被这个边框遮住；
1
如果要使用Mask时，需要评估下Mask会带来的性能损耗，并尽量将其降到最低。比如Mask内的UI是动态生成的话（比如List组件），那么需要注意UI之间是否有重叠的现象。
总结：
1
uGUI的性能其实涉及到的方面很多，这里列出来的只是目前能想到的，因为个人能力有限，可能出些纰漏。对于文中的一些建议，这里整理一下得出一些最佳实践：
1 设计UI时要考虑重用性，如一些边框、按钮等，这些作为共享资源，放在1~3张大图集中，称为重用图集；
2 其它非重用UI按照功能模块进行划分，每个模块使用1~2张图集，为功能图集；
3 对于一些UI，如果同时用到功能图集与重用图集，但是其功能图集剩下的“空位”较多，则可以考虑将用到的重用图集中的元素单独拎出来，合入功能图集中，从而做到让UI只依赖于功能图集。也就是通过一定的冗余，来达到性能的提升。
4 有相同材质和纹理的UI元素是可以Batch的，可以Batch的UI上下叠在一块不会影响性能，但是如果不能Batch的UI元素叠在一块，就会增加Drawcall开销。
5 要注意UI元素间的层叠关系，建议用“T”工具查看其矩形大小，因为有些图片透明，但是却叠在其它UI上面了，然后又无法Batch的话，就会无故多许多Drawcall；
6 UI中出现最多的就是Image与Text组件，当Text叠在Image上面（如Button)，然后Text上又叠了一个图片时，就会至少多2个Drawcall，可以考虑将字体直接印在下面的图片上；
7 有些情况可以考虑人为增加层级从而减少Drawcall，比如一个Text的层级为0，另一个可Batch的Text叠在一个图片A上，层级为1，那此时2个Text因为层级不同会安排2个Drawcall，但如果在第一个Text下放一个透明的图片（与图片A可Batch），那两个Text的层级就一致了，Drawcall就可以减少一个。
8 应该尽量避免使用Mask，其实Mask的功能有些时候可以变通实现，比如设计一个边框，让这个边框叠在最上面，底下的UI移动时，就会被这个边框遮住；
9 如果要使用Mask时，需要评估下Mask会带来的性能损耗，并尽量将其降到最低。比如Mask内的UI是动态生成的话（像List组件），那么需要注意生成的UI之间是否有重叠的现象；
10 有空好好看下Unity GUI层级合并规则与批次生成规则这一节。
1
作者：kingshijie
链接：http://www.jianshu.com/p/061e67308e5f 來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。