工具
Profiler(command + 7)
![](https://i-blog.csdnimg.cn/blog_migrate/2df8c1854518d90bf54b908467881eff.png)
这个是我认为最好用的工具了,哪里不会点哪里,预览明明白白
Frame Debug
![](https://i-blog.csdnimg.cn/blog_migrate/178b2a0e349a3813ebf3fa8d55e60d28.png)
FrameDebug也能看到诸如批次,Texture ,Matreical 等信息,不过不如Prefiler好用
原理图解
批处理: 大致就是Unity在运行时可以将一些物体进行合并,本来需要多个drawcall指令才能渲染完成的降为1个drawcall就能搞定
使用: UGUI在合批之前,会根据ui的Depth
、MaterialID
、MaterialID
、RendererOrder
进行排序,之后对相邻的UI进行检测。判断MaterialID
和TextureID
是否相同,如果相同则可以进行合批处理。如果不同则会打断合批
先决条件:MaterialID,TextureID
相同
这两个很容易达成,不对默认Material做修改,并使用同一个图集即可
我们这里主要讲解的是打断合批的情况
排序图解
首先看下图
文字 Texture 是Font Texture
空白图片 Texture 是UnityWhite
![](https://i-blog.csdnimg.cn/blog_migrate/657f22f336d2cd73cbf50a4e0f448115.png)
1.首先由Depth排序,盖在最里面的白色图片深度为0
2.Text在白色图片上面,二者材质(Material)相同,但纹理(Texture)不同,不能合批,Text深度为1
3.再往下,红色图片盖在Text上面,同理不能合批,red深度为2
4.黄色和红色材质和纹理都相同,可以合批,yellow深度为2
5.同理绿色图片green深度为2
这里我们打开Profiler(command + 7)看一下,3个批次符合判断
注一
以上覆盖关系与控件大小无关,与控件在Hierarchy的布局位置无关,只与渲染的三角面有关,如图
scene选择Wireframe,可以看到渲染的三角面
显示如下,控件大小为蓝色调整大小的区域,实际渲染的只有左上的小方块三角面
红色图片的方框一部分与Text线框重合。所以打断了合批。
我们尝试把Text上移一些,如下图
对比以上图片可发现,Hierarchy布局未发生变化,只是移动了Text的位置,Text区域框依然和red区域有重叠。合批却发生了变化。
实例图解
实际应用案例
下面是一个常见界面,对比一下合批的效果
不打包图集
![](https://i-blog.csdnimg.cn/blog_migrate/6fb101475980c26838ec284246686f75.png)
使用图集
![](https://i-blog.csdnimg.cn/blog_migrate/c08ec5b15fa27e2259a31e8efa4a6ea8.png)
一些注意事项
1.一些打断合批的细节
如图,第一个道具的 label_destory 没有隐藏,img_btn 能完全覆盖,显示效果是一样的。
但是label_destory 会打断 img_cellBg 与 img_btn的合批,平白多出2个批次
2.图集打包的注意事项
drawcall并不是最求极限越小越好。
如文中的道具图标,如果有大量图标,打包到同一个图集里会使图集很大。
决定渲染模块性能的除了Draw Call之外,还有用于传输渲染数据的总线带宽。当我们使用Draw Call Batching将同种材质的网格模型拼合在一起时,可能会造成同一时间需要传输的数据(Texture、VB/IB等大大增加,以至于造成带宽“堵塞”,在资源无法及时传输过去的情况下,GPU只能等待,从而反倒降低了游戏的运行帧率
这种界面一般重复使用的UI打包为一个图集。
图标根据数量分为多个图集,或者由美术直接提供图集自己做裁切。
图集大小根据各公司规范略有不同,大多是512或1024