浅析UGUI渲染机制

浅析UGUI的渲染机制

本篇简要介绍UGUI的渲染方面的概念、常用技巧和优化方法。可能写的不太系统，而意在写一些重点。

渲染器

UGUI的渲染器是 Canvas Renderer（下文简称为CR），首先来看看其与同样是渲染2D物体的 Sprite Renderer（下文简称为SR） 的区别和联系（原文链接）。

相似点

• 都有一个渲染队列来处理透明物体，从后往前渲染。

• 都可以通过图集（Atlas）来合并渲染批次，降低Drawcall。

不同点

• CR与RectTransform配合，因此可以有专门的布局适配，但必须在Canvas中使用，常用于UI。SR与Tranform配合，没有适配，常用于GamePlay。

• CR是基于矩形分割的三角网格，一张网格最少有两个三角形，透明部分也占用空间。SR的三角网格比较复杂，不过也是自动生成的，能剔除大部分透明部分。

之所以使用CR渲染一张图最少有2个三角形，是因为仅在ImageType设置为simple时成立。设置为sliced（九宫格），将会有18个三角形，设置为tiled可能更多。

非连通sprite mesh

对于sprite renderer，若非透明的部分不连通，则为每个非连通部分各自生成网格。在Unity编辑器中观察三角形网格可以在scene中选择Shaded Wireframe。

小结

可以看到，三角形数和网格面积是一对“trade-off”。

网格三角形数和顶点数成正比，影响的是GPU的几何运算量。网格所占面积影响的是GPU的片元计算量。

而对于现代对于移动处理平台，对顶点操作的代价要显著小于对片元操作的代价。尤其是处理半透明图片的重叠时，需要反复对同一个像素位置进行渲染，产生overdraw问题。

SR用更复杂的顶点运算为代价，剔除了大量透明区域，减少了overdraw，换取了更少的片元处理，节省了GPU带宽。而且，变化的SR不会像CR那样引起整个canvas去rebuild。本人认为，在显示不需要使用布局功能的2D物体时，可优先考虑用SR而不是通通放到Canvas下做成UI，这样既可以减轻overdraw、也能防止潜在的过量rebuild。

补充

上面提到了SR的网格是自动生成的。其实，Unity自带的SR网格生成算法并不好，更好的算法见这里。

另外，渲染3D物体用的是MeshRenderer（简称MR），它和SR的区别在哪里呢？MR可以接受光照并且投射阴影。而SR不能原生支持这一点（ https://forum.unity3d.com/threads/why-cant-sprites-gameobjects-cast-shadows.215461/ ）。

渲染层级（TODO）

我们说的渲染层级高，是指它盖在其他物体的上面，也就是最后被渲染（颜色混合）的那个。

渲染的层级控制本身也是分层的。其从高到低分为几个层次： （1）相机的layer和depth （2）画布的layer和order （3）物体的hierachy关系。

越高的层次，控制力就越大。下面，我们具体说明每个层次的使用。

相机层级

上图的红框中，CullingMask可以决定该相机能看到什么Layer的物体（Layer在Inspector窗口的右上角设置，可以自定义）。

Depth越高的相机，其视野内能看到的所有物体的渲染层级都更高（无视其他低层次的规则）

至于ViewPort Rect，可以实现同一个屏幕内显示多个相机视野的功能，通过设置起始点和宽高，可以实现类似监控台多个监视器的效果。下面贴一张图做例子。

画布层级

物体层级

父子parent在下面 兄弟sibling

渲染流程

这里重点说CPU的部分。

（一）rebatch

什么是rebatch

将mesh转化为渲染指令的过程叫做rebatch，也叫batch build。Unity中，主要是由canvas相关组件完成rebath，大致步骤是：

geometry -> canvas renderer -> meshes -> canvas -> rendering command -> unity graphic pipeline。

rebatch何时触发

当一个canvas中包含的mesh发生改变时就触发，例如SetActive、transform的改变、 颜色改变、文本内容改变等等。注意，这些变化影响的范围是以一个个canvas为界限的，即其他canvas、子canvas内的变化与当前canvas无关（后面会说到，这也是用多个canvas或子canvas能减少rebatch和rebuild的原因）。

若canavs内含有需要rebatch的物体，则该canvas会被标记为dirty，供后续流程使用。

rebatch很慢吗

虽然rebatch这一步是多线程的，但不必要的rebatch，会给后续步骤带来很大负担。rebatch本身对计算力的消耗体现在：对meshes按照深度和重叠情况排序、共享材质的检测等。

（二）rebuild

什么是rebuild

布局和网格被重新计算的过程叫做rebuild。Unity中，是指c#中Graphic组件的重新计算（可以理解为rebatch的后续）。大致步骤是：每一帧都会触发WillRenderCanvases事件，然后由CanvasUpdateRegistry响应并执行PerformUpdate。

PerformUpdate分三步：

1. Dirty Layout components rebuild ,有一个根据Hierachy排序过程

2. Masks Clipping component

3. Dirty Graphic components rebuild, 不需要排序

rebuild很慢吗

Unity官方没说用的是多线程还是单线程处理。不过可以肯定的是，因为Layout components需要排序，所以要尽量少用Layout components，而用rectranform的锚点来布局。

（三）drawcall

什么是drawcall

CPU和GPU之间的通信内容主要有两类：数据和命令。其中，命令又分为两种： （1）设置渲染状态（2）drawcall。

渲染状态主要包含所用shader、材质（包含纹理、uv信息、光照等）。

这里补充一点：Image组件绑定的材质不要设置为none，否则unity会采用默认的材质。该材质的shader过于复杂，会降低性能。没啥需求就选成sprite-default。

drawcall的确切含义是：在渲染的第一阶段，CPU准备好数据和渲染状态后，真正向GPU发送的一次渲染请求：开始渲染一个或一批图元。

为什么drawcall太高不好

drawcall太高，意味着有频繁地改变渲染状态，这是很慢的操作（相对于GPU执行其内部的渲染流水线来说）。当存在两个相同渲染状态、仅仅是顶点数据不同的图元时，我们应当尽量将其一起渲染，这样就减少了一次drawcall。而GPU的空闲时间也会减少，最终完成渲染整个画面需要的总时间就会减少，帧数才能提高。

如果场景中drawcall太高，那么得从两个方面入手：检查hierachy的合理性；使用图集。具体方法这里后面有文章会专门介绍。

但要记住一点，虽然通常我们都在尽量降低drawcall，但并不是越低越好。所以不要一味追求低drawcall而牺牲了其他方面的性能。

（四）fillRate

这个是显卡里面的概念，这里单独拎出来，是因为overdraw导致的fillRate过大问题通常是移动设备GPU渲染的瓶颈（而不是顶点数太多）。关于这块的优化会单独抽一篇文章去说，这里给出fillrate的公式。

fillRate = 像素数 x overdraw x shader复杂度

另外，fillrate的概念可细分为pixel fillrate和texture fillrate。

pixel fillrate

显卡每秒可渲染到屏幕上的像素点数量。有点像带宽的概念。在片元着色性能成为显卡性能评估标准之前，像素填充率一直是最准确的标准之一。

texture fillrate

显卡每秒可渲染到屏幕上的纹理化了的像素点数量。摘一段wiki：

To render a 3D scene, textures are mapped over the top of polygon meshes. This is called texture mapping and is accomplished by texture mapping units (TMUs) on the videocard. Texture fill rate is a measure of the speed with which a particular card can perform texture mapping.

优化技巧举例

这里是指写几个简单明了的技巧，UGUI还有诸多方面的全面优化参见后文。

（一）隐藏UI的正确方法

如果用setactive（false），会导致所在canvas的VBO数据失效。所以再次setactive（true）的时候，会导致整个canvas去rebuild和rebatch，从而对CPU造成负担。

推荐方法：多使用sub-Canvas（注意不仅要添加Canvas组件，还有Graphic Raycaster组件），隐藏目标采用将对应的CanvasRenderer.enabled = false。

但注意挂在上面的脚本还是在运行的，而且虽然看不见了，还是能被Graphic Raycast检测到。如果这样会对逻辑行为造成影响，那么应该自己实现一个manager去管理CanvasRenderer.enabled 下的脚本行为。

参考资料

（二）降低overdraw的技巧

首先观察当前场景的overdraw：unity编辑器中scene视图中选择OverDraw（默认是shaderd），越亮的区域，overdraw越高。

对于降低overdraw，有这么几种办法： （1）全屏遮挡的情况，则为被遮挡的canvas添加CanvasGroup组件，然后在被挡住时将其alpha值设为0，就不会传给GPU渲染了。Canvas Group还有一些其他设置，意味着该节点以及所有的子节点都可以统一地更改一些行为。

Blocks Raycasts是一个很有用的设置，取消勾选，则意味着该canvas里面的UI都不会接收点击等事件了。

Ignore Parent Group如果勾选，则表明该canvas无视上层CanvasGroup的设置。

（2）非全屏遮挡，这就要从美术资源上想办法。