前言
昨天在通过FrameDebug查看DrawCall时，发现批次结果与理解中的不一致，又去补充了一下这方面知识，笔记记录下，只关乎UGUI。
基础场景
首先列一下无法合批的一些基础场景
1.图片无图集或图集不同，图片是运行时生成的
2.字体不同
3.对象缩放不同
4.材质不同
5.有Mask或RectMask2D组件
特殊场景
在不存在任一基础场景下，有些特殊场景也会导致无法合批
1.Z轴偏大或偏小的元素。 这种元素通常是不显示在Game视图内的，发现这个是因为之前一直以为在Game视图外的元素是不参与渲染，也就不会产生DrawCall。但是事实并不是如此，因为UGUI系统并不会自动剔除相机视野外的元素。而且由于我把元素的Z坐标设置的异常大（-55555），导致又触发了强制分离批次机制，即当Z坐标设置过大/小时，Unity会认为该UI元素深度严重偏离其他元素，从而强制分批，避免视觉错误。在这种情况下，原UI元素的正常DrawCall是9，但是由于触发了强制分批，会导致本身应该合批的也没有进行合批，DrawCall飙升到了22。这种情况下，应该采用的方式是给元素添加CanvasGroup组件，alpha设置为0，不参与渲染。这样既保留了元素的逻辑，又不会增加DrawCall。
2.**UI存在遮挡关系。**这是最常见的场景，明明图集一样，材质和其他所有设置都一样，但是仍然无法合批，通过FrameDebug去查看时，会发现被其他元素打断了。举个例子，Toast一般是由一个Image背景和Text内容组成的预制体，当快速弹出多个Toast时（假设没有缩放动画），之前的理解是只会有2个DrawCall，一个是Image，一个是Text。但是实际情况下，每多一个Toast，DrawCall都会增加2。这是因为这些Toast之间存在了遮挡关系，因为Toast都是在一个地方出现的，当快速弹出多个时，很多个Toast重叠在一起，Image之间的合批被穿插的Text打断，同理Text的合批被Iamge打断，导致无法合批。但是当错开Toast时，比如将一个重叠的Toast移出重叠区域，这时会发现DrawCall降低了2，当把所有Toast都移动一下，保证互不重叠时，会发现，所有Taost加起来也只有2个DrawCall，即合批成功了。这只是一种简单的场景，实际UI界面中，因为存在背景，渐变，透明等原因，实际渲染效果并不一定跟Hierarchy完全一致，此时就会因为遮挡问题导致打断合批。要尽量减少这些打断合批的情况，需要开发规划好UI元素结构，结合FrameDebug找出打断合批的元凶（比如本来DrawMesh20和DrawMesh23正常情况下是要合批的，但是现在分开了，那么DrawMesh21,22就是打断合批的元凶），然后根据情况去处理。
遇到更多场景再更新...