Unity

简单读读UGUI源码之绘制初探

Spread the love

 

在日常开发过程当中,类似于HUD或者是弹幕之类大量的体积小但是不断在移动的UI,在不断的重建的过程当中会产生大量的GC,导致游戏卡顿到不能玩。

今天就研究一下Unity中UGUI的绘制方法以及规则:

UGUI的源码地址(C#部分):

下载地址

 

利用底层API进行绘制


首先我们要搞清楚,到底UGUI是如何对UI进行绘制的。我们首先从最稀疏平常的Image开始。

 

Image源码尝试阅读

我们首先盯上的是Image,我们发现首先,其基类为MaskableGraphic,其他的接口我们先暂时不管,并且最终我们看到其最终的基类依旧是Monobehavior。

 

经过阅读,其实最主要的绘制部分其实不多,主要是对Graphic基类中几个成员对象的重写。

 

  • mainTexture属性 主要负责提供贴图
  • material属性 主要提供材质
  • OnPopulateMesh函数 主要提供顶点以及UV信息(也就是Mesh信息)

 

首先是mainTexture,我们发现就是简单从sprite中取出Texture而已,如果没有sprite则提供默认的白色贴图

然后是material属性,我们可以看到,也是非常简单,首先判断有没有材质,如果没有就提供默认材质。

最后就是比较重头的OnPopulateMesh,这个函数的主要作用就是用于构建Mesh。

在这之前我们可以先看看VertexHelper这一个类的作用。

打开VertexHelper的源码,我们可以很清楚看到,其实VertexHelper只是一个临时的容器,用于存放需要渲染的Mesh信息。

值得注意地是其中所用到的ListPool,性能高度敏感的代码块,需要大量的使用对象池,这是优化代码效率减少GC的好技巧,无论是网络模块还是底层的组件重用,对象池都是必不可少的!

那这个时候我们其实自己可以想到,我们的合批需要怎么做了,在我们使用UGUI的时候其实每一个Image都是使用了PopulateMesh来进行Mesh生成之后进行合批,我们其实可以将这一步直接放在这一个函数里面,由我们自己来重写就可以了,这样我们就不需要调用N次PopulateMesh之后进行合并,而只需要调用一次自己编写的PopulateMesh函数就可以了。

 

我们再看一看Graphic基类当中对该函数的编写:

 

上面图中我们可以看到,其仅仅是画了一个正方形的Mesh而已。

具体如何通过Vertex画Mesh其实和OpenGL中VAO EBO是一样的,就不再赘述了。

 

我们回过头来看Image当中的OnPopulateMesh:

我们会发现,当Sprite为空的时候画Image的方式就是Graphic,与我们平时的使用方式相同。

当Sprite不为空则会通过不同的sprite类型来进行绘画,实际上就是获取不同的UV,通过何种方式来将贴图绘制到Mesh上面。

 

我们这里就只看一下最简单的sprite绘制方法,我们会看到

其实也是画个矩形……

GetDrawingDimensions在获取Rect,而通过GetOuterUV来获得UV。

获得UV的时候主要是为了将Sprite中空白的地方进行裁切,主要是通过从Native层得到的padding来计算的,具体内部如何计算我们不得而知,但是我们拿到padding值就已经可以完全算出Sprite的实际大小了。

由于我们只是绘制Simple类型的sprite,所以对UV不需要进行比较复杂的计算,实际上在其他几种绘制方式之中,除了OuterUV还会用到InnerUV,详细算法也就得自己慢慢看了……

至此,我们已经大致明白了如何通过顶点来对UI进行绘制。是时候自己实践了。

 

自定义Graphic

我们建立一个新的类:MyGraphic

其中我们重写三个对象,也就是上面提到的:

 

  • mainTexture属性
  • material属性
  • OnPopulateMesh函数

 

 

因为自己很懒惰,所以直接将DrawingDimension函数拿过来用了。

获得了Rect以及UV之后我们就可以像普通的Image一样绘制出图片了,

当然我们也可以把其中一句AddTriangle删除,我们就可以发现,我们只绘制了一个三角面

 

UGUI底层绘制规则


接下去,我比较好奇的是,OnPopulateMesh到底是什么时候进行调用的,因为我们都知道,在UI当中消耗比较大的用于都是UI的重建操作,如果我们能够搞明白UI重建规律的话那我们应该可以大大避免UI重建的情况。

 

Graphic当汇总的DoMeshGeneration调用了OnPopulateMesh

我们可以看到,当RectTransform的尺寸为0的时候就不再调用OnPopulateMesh了,与以前总结出来的优化方案相同。

下面则是对Mesh进行调整并且通过VertexHelper将数据实装到Mesh当中最后将Mesh赋值给CanvasRenderer进行渲染,这下能理解为何所有显示组件都要带一个CanvasRenderer了吧。

 

UpdateGeometry调用到了DoMeshGeneration

除了Text在字体变换的时候会进行更新以外,入口都是统一的:Graphic中的Rebuild。

 

Rebuild实际上是实现了ICanvasElement的接口。

当顶点数据遭到修改,则立刻会进行重建,实际上我们只需要关心何时SetVerticesDirty会被修改就可以明白到底什么时候UI会进行重建。

不过在此之前,我们先看看Rebuild在何时会被调用。

查找引用,发现是在CanvasUpdateRegistry中的PerformUpdate中进行调用,这个PerformUpdate是挂载在Canvas.willRenderCanvases这个事件上的,也就是Canvas进行渲染之前便会进行调用。

 

SetVerticesDirty被调用的情况

我们回过头来看一看何处会修改SetVerticesDirty:

当调用了SetVerticesDirty则会修改该值并且添加到Canvas的重建列表当中。

 

调用该函数的地方就不少了,查找之后总共34处调用。

 

文字的以下属性进行变化都会进行Mesh重建,所以如果有大量需要经常变动的Text就要小心了。

同样的图片也有属性一旦改变就会引发改变,其中我们比较常用的可能就是尺寸了,例如CD、位置修改等等,都会造成重建。

RawImage中进行修改的时候也会产生重建

当蒙版进行修改的时候也会进行重建

采用Shadow的时候也会产生重建

了解到何处会对Mesh重建进行调用我们就可以尽可能减少重建消耗。

 

总结


例如弹幕或者是MMO中飘血文字都可以通过自己重写OnPopulateMesh来自己对Mesh进行合批而不需要通过Canvas对所有元素进行逐一的合批,提高效率。

时间不早了,在咖啡厅写了一些,看了一场电影,回家匆匆收笔,下次有时间再看看吧~

此文为过年时闲暇所作,有很多不严谨的地方,希望大家多多交流多多指正。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注