Unity - 性能优化实战07 - UGUI优化

2023-09-06 本文已影响0人能不写代码么

一、Canvas Batch

一个Canvas绘制Mesh的过程中，如果每个UI元素都绘制一次（DrawCall），则耗时会很长。因此Canvas会先对其UI元素按照材质和渲染顺序排序，将能够一起绘制的UI元素合并到一个Mesh中，然后绘制。这样可以有效减少DrawCall

在WillRenderCanvases事件调用PerformUpdate::CanvasUpdateRegistry接口
- 通过ICanvasElement.Rebuild方法重新构建Dirty的Layout组件
- 通过ClippingRegistry.Cullf方法，任何已注册的裁剪组件Clipping Compnents(Such as Masks)的对象进行裁剪剔除操作
- 任何Dirty的 Graphics Compnents都会被要求重新生成图形元素
Layout Rebuild
- UI元素位置、大小、颜色发生变化
- 优先计算靠近Root节点，并根据层级深度排序
Graphic Rebuild
- 顶点数据被标记成Dirty
- 材质或贴图数据被标记成Dirty

Canvas负责管理UGUI元素，负责UI渲染网格的生成与更新，并向GPU发送DrawCall指令
UI组件的基类是Graphic，Graphic核心是组织Mesh和Material传到底层（CanvasRenderer）
CanvasRenderer将Mesh和Material传递给Canvas，Canvas做合批。CanvasRenderer的两个核心SetMesh和SetMaterial。每个Graphic有一个CanvasRenderer，保存了保存当前元素的Mesh和材质。一个Graphic为dirty，Canvas就要重新合批

UGUI中渲染是在Transparent半透明渲染队列中完成的，半透明队列的绘制顺序是从后往前画，由于UI元素做Alpha Blend,我们在做UI时很难保障每一个像素不被重画，UI的Overdraw太高，这会造成片元着色器利用率过高，造成GPU负担。
UI SpriteAtlas图集利用率不高的情况下，大量完全透明的像素被采样也会导致像素被重绘，造成片元着色器利用率过高；同时纹理采样器浪费了大量采样在无效的像素上，导致需要采样的图集像素不能尽快的被采样，造成纹理采样器的填充率过低，同样也会带来性能问题。

1.1 Canvas Re-batch 时间过长

指Canvas分析其UI节点信息，生成最优批次的过程
耗时：节点数量，层级深度，元素重叠，材质数量等
触发时机：当Canvas中的UI节点的Mesh改变时（SetActive，transform，颜色……..）
触发过程：根据UI元素深度关系进行排序、检查UI元素的覆盖关系、检查UI元素材质并进行合批
触发结果：重新Batch一次，无论当前Mesh的改变是否影响了父节点（也就是说一个很小的变化，就会让当前Canvas重新Batch一次）
解决方案：
1. 可以用多个同级Canvas或者Canvas套Cnavas的方法，来将复杂层级划分到不同Canvas中去，需要注意的是每个Canvas都至少有一个DrawCall（当有子UI元素时），这样可能会增加DrawCall
2. 使用动静Canvas分离的方案可以将ReBatch的范围限制在动态Canvas中
3. 减少层级复杂度，少用嵌套的树形UI结构，同时将材质相同的UI尽量放到同一层级

1.2 Canvas Over-dirty, Re-batch次数过多

1.3 生成网格顶点时间过长

1.4 片元利用率高 - Fill-rate overutilization

不需要交互的UI元素一定要关闭Raycast Target选项
如果是较大的背景图的UI元素建议也要使用Sprite的九宫格拉伸处理，充分减小UI Sprite大小，提高UI Atlas图集利用率
对于不可见的UI元素，一定不要使用材质的透明度控制显隐，因为那样UI网格依然在绘制，也不要采用active/deactive UI控件进行显隐，因为那样会带来gc和重建开销
使用全屏的UI界面时，要注意隐藏其背后的所有内容，给GPU休息机会。
在使用非全屏但模态对话框时，建议使用OnDemandRendering接口，对渲染进行降频。
优化裁剪UI Shader，根据实际使用需求移除多余特性关键字。