UGUI性能优化之Canvas

UGUI性能优化之Canvas

前言，觉得好的同学别忘了给个好评哦，另外，如果有什么疑问的，欢迎随时提问~~

自从Unity问世以来，UI一直都存在比较大的问题，自带的OnGUI不能所见即所得，制作过程比较麻烦。于是出现了很多第三方的优秀的UI插件，比如很多项目里面用到的NGUI，或者后来出的FairyGUI。Unity官方在4.x时代开始推出了自己的新UI系统，名为UGUI。由于是官方出品，所以选择使用的人也比较多。

阿赵我也是基于信任官方出品的心理，在最近的两个项目里面都使用UGUI进行开发。UGUI是一个比较完整的所见即所得式的UI系统， 不过说实在的，我个人感觉它的成熟度还是差了点，有很多需要注意的地方，不然就会产生很多性能上的问题，比如DrawCall问题和运行时的效率问题。我就曾经在项目中遇到了，UGUI用的不好，它产生的消耗比3D场景内的地图和角色消耗还高的情况。老实说，我用UGUI也用的不好，这里也只是分享一点经验，这次主要讲一下UI重绘的消耗和图集的一些问题。

要了解UGUI的一些坑，首先要明白它是基于什么原理来运作的。

首先，UGUI还是基于网格模型渲染的。一个矩形，实际上还是由4个顶点组成的一个mesh显示出来的，和正常的mesh模型渲染一样，它使用了材质球和贴图。我们平常看不到这些元素，是因为渲染UI用的Mesh网格是在运行中才生成的，它默认使用了Untiy内置的一个默认的材质球，然后使用我们指定的UI图片作为贴图。

打开一个Image来看看，可以看出Material是空的，那是因为它有默认的材质球。然后Unity也允许你再指定一个Material来渲染。值得注意的是，这个材质球如果你是直接挂在UI的Image上面，那么如果你在运行时修改Material，将会改到的是Share的原始Material。所以最好的做法是在代码里面生成一个材质球的复制实例，然后再赋给Image使用。

明白了单个UI元件的渲染原理之后，接下来需要说说渲染合并的问题。既然一个Image就是一个Mesh，然后上面有单独的贴图显示。那么是不是就代表着，我一个界面里有有100个UI元件，那么就会产生100个Mesh，产生100个DrawCall呢？

从原理上的确是会这样，但实际运行的时候，并没有产生这样的结果。这里Unity引入了一个Canvas（画布）的概念。在默认创建的UGUI根节点上面，你可以看到这个Canvas

它定义了一些东西，比如当前画布的渲染模式、排序情况。

然后当你往这个Canvas里面添加其他UI元件的时候，这些元件实际上就是被这个Canvas统和在一起了。比如，同一个Canvas里面有100个Image，Canvas将会把100个单独的Mesh合并成一个大的ShareMesh，用于渲染。如果刚好这100个Image都是使用了相同的图片或者是同一个图集里面的图片，那么由于使用的Mesh只有一个（ShareMesh），材质球都是同一个（内置的默认材质球），贴图也是同一张，所以得到的结果就是，DrawCall只有一个。

这实际上就是UGUI最基本的优化思路了。合并ShareMesh、合并图集，减少DrawCall。但在实际项目的操作中，会遇到很多问题。

就拿ShareMesh来说，我们可以把场景的静态合并拿来对比一下。这个ShareMesh和场景合并成CombinedMesh是一样的，把很多小模型合成一个大模型。但可以想象，场景的模型合并是静态的，也就是说它是摆在那里不会动的。大部分情况下，UI也是不会动的，在这种情况下，合并ShareMesh没有太大的问题。但还是会有很多会动的时候。比如说，Arpg很喜欢在角色头顶上显示角色名字，名字会跟随着角色移动。再比如，聊天里面不停的刷各种文字聊天信息，或者你需要一个图标从左边飞到右边的动画，或者你的血量条需要动态变化长度之类，等等。这些情况下，由于单个显示元素的Mesh 形状发生变化（文字的改变实际上也是改变了Mesh形状），如果原来这些UI元素就是和其他所有UI元素合并同一个ShareMesh的，那么问题就来了，假如你UI元素非常多，产生了一个2M的ShareMesh（这是一个比较极端的例子，实际上一般的ShareMesh都是几百K，出现这么大的ShareMesh本身就需要注意了），由于一个小顶点发生了改变，导致2M的整体ShareMesh也需要重新的生成顶点信息，并且整个ShareMesh重新渲染，这明显是得不偿失的。你会发现在UI动画的过程中，整个游戏都在卡。卡的是cpu方面的实时合并网格顶点，和渲染那边的整个大Mesh重新绘制。

那么怎么解决这个问题呢？思路也像场景模型和角色模型的关系一样。首先要知道的是，在根节点下面挂了Canvas之后，还是可以在子节点上面继续的挂Canvas的。这样，从理论上说，Unity会找到最小单位的Canvas作合并。既然大部分的UI是不会动的，那么我们可以做一些分层，把不会动的元素放在同一层，然后会动的元素，根据动的频率和类型，分别在他们的子节点上面挂上Canvas。这样就可以在保证大部分UI元素能合并渲染的基础上，减少整体重绘的范围。

听完上面的一些关于Canvas的说法之后，你是不是有种想法，那么那些会动的东西要不挂多几层Canvas，让它控制得更细腻？当初我也是这样想的。不过后来发现这样做很有问题。Canvas存在一个重绘的问题。如果你把一个Canvas的节点SetActive为false之后，再在它身上做改变坐标之类的操作，再把Canvas节点SetActive为true，这时候Canvas渲染的还是之前的画面，并没有把改变的东西渲染到。在这个时候，要么Canvas里面的元素稍微变化，让它被动的触发重绘，要么调用ForceUpdate的API让Canvas主动重绘。但这样的操作如果在Canvas嵌套了很多层之后，是很难去控制的，也不可能每次都强制主动重绘Canvas，毕竟很多时候是没必要这样做的。最重要的一点是，编写UI框架的时候，不应该要以后写业务逻辑的人去关心业务上导致UI显示发生改变后，再去做些什么样的潜规则才能正常显示出来。所以我建议Canvas也不要分得太多，特别不要嵌套得太多层次，导致失去控制了。
————————————————
版权声明：本文为CSDN博主「liweizhao」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/liweizhao/article/details/81974604