打断UGUI合批的肇事手段RectTransform

我们先搭建一个测试场景

我们可以看到4个but的话是进行合批只有2个DrawCall，当我们将第二个button的RectTransform的PosZ进行修改

可以发现DrawCall增加了4个，我们通过FrameDebug来查看合批的过程可以发现

修改了PosZ打断了正常的合批流程，导致btn1和btn3，btn4的合批被分开了，增加了2个draw，加上修改了posZ的原来的btn2自带的两个drawCall，就增加了4个drawcall。

因为没有源码可以看，我们假设一下是只有相同平面下的PosZ才能进行合批，那我们尝试修改btn1的posZ也为1，和btn2的PosZ一致，保证他们两个再同个平面上

你会发现DrawCall并没有减少，一样是分开渲染。因为没有源码的佐证，从现象分析笔者猜测这块平面合批的策略只适用于PosZ为0的平面上其余平面下的draw都是单独渲染。那分开渲染的东西会影响depth的深度计算吗？我们做一个实验，

先是正常的将同一个平面下的btn2移动到btn4下，打断btn4和btn3的合批。

结果是我们想要的，那当我们将btn2的PosZ修改为1呢？

会发现并没有打断btn3和4的合批，代表depth的计算根本没有考虑不再同一个平面的物体。

那假设unity的合批收到同一个平面的限制，那unity是一个3D的引擎，物体可以做平移旋转缩放，那我们就可以联想到，对于旋转造成的异面他是怎么处理的呢？是不是也会如我们设想的一样和posZ一样的情况呢？

我们进行测试，将btn2的rotationX设置50：

情况和我们预计的一样是未进行合批的，因为不在一个平面，那我们再次假设，当180时，他虽然进行了旋转但是还是在一个平面，他能否进行合批呢？

果然是能够进行合批的，也侧面验证了我们的推断，所以当XY旋转角度为180的倍数时，不影响合批。其他的角度都会造成异面打断合批。（当然Z除外，这个怎么转都是一个平面）