Unity3D :关于UGUI的网格重建、动静分离[通俗易懂]

Unity3D :关于UGUI的网格重建、动静分离[通俗易懂]前言:无论是网上的攻略还是以前的经验来说,都说UGUI需要进行动静分离。也就是说同一个界面下的UI,可活动的元素放在一个Canvas下,不可活动的元素放在另一个Canvas下。虽然两个Canvas打断了合批,但是却减少了网格的重建时间,总体上是有优化的。究其原因,是因为在同一个Canvas下的某个元素发生变化时,同一Canvas下的所有元素都会进行网格重建(ReBatch)。而静态的元素在…

大家好,又见面了,我是你们的朋友全栈君。

1、 前言:

        无论是网上的攻略还是以前的经验来说,都说UGUI需要进行动静分离。也就是说同一个界面下的UI,可活动的元素放在一个Canvas下,不可活动的元素放在另一个Canvas下。虽然两个Canvas打断了合批,但是却减少了网格的重建时间,总体上是有优化的。

        究其原因,是因为在同一个Canvas下的某个元素发生变化时,同一Canvas下的所有元素都会进行网格重建(ReBatch)。而静态的元素在逻辑上是不需要重建的,因为他们都没变过,所以需要分开。

        但是我在实际进行测试的时候(5.6.6)却发现在Profile中没有体现:

        创建了200个图片,其中100个在活动,另外100个静止。无论是怎么划分Canvas,其Rebuild次数始终为200(每一个Image的重建需要调用2次Rebuild)。简单地说,你动静分离也好,不分离也好,都是变化几个元素重建几次,而且从CPU时间来看也没有任何区别。那是不是说动静分离没什么用了?反正分不分都一样。

2、 正文:

        后来在网上咨询了各路大佬,最终了解到了其中的原因。下面谈谈我自己的理解(可能有误,知道大概意思就好)。

        参考:

        《Fill-rate, Canvases and input》:https://unity3d.com/cn/learn/tutorials/topics/best-practices/fill-rate-canvases-and-input?playlist=30089&tdsourcetag=s_pcqq_aiomsg

         Making the UI Backend Faster》:Making the UI Backend Faster | Unity Blog

        《关于Unity中的UGUI优化,你可能遇到这些问题》:关于Unity中的UGUI优化,你可能遇到这些问题 – UWA Blog

2.1、网格重建的过程:

        UGUI的网格重建分为两部分:一部分是是重新计算画布内的各个元素的顶点,并进行合并。第二部分是将整理好后的网格、贴图等数据拿去渲染。

        显然,无论是否进行动静分离,第二部分的消耗都是不变的,无非是占用几个DrawCall而已。所以动静分离的优化在于第一部分。

        UGUI在显示UI元素的时候,其实是为每一个UI元素(例如图片)建立一个网格,并且设置UV和颜色值等。对于使用同一个图集的元素,还会对其网格进行合并,从而使得这一批元素只占用1个DrawCall就可以渲染出来。从原理上讲,这部分的消耗也是必不可少的。在Unity中,这部分的工作在 Canvas.BuildBatch 中体现。

        但是在之前的Unity(5.2 以前)都还能在Profile里面看到 Canvas.BuildBatch这个方法的性能消耗。然而这之后的Unity便不能看到他的消耗,只能看到他的一个几乎不耗时的工作分配(JobAlloc.Grow),至少在5.6.6是这样的。

        那么,Unity对这个操作是做了怎样的优化呢?

2.2、5.2以后对Canvas.BuildBatch做的优化

        在5.2之后对 Canvas.BuildBatch 流程做了优化,一部分是算法的优化,另一部分是流程的优化。

        算法不讨论。流程方面,在CPU超过一个核心的情况下,Unity将Canvas.BuildBatch流程放在在主线程之外,使用多线程进行计算。由于不再占用主线程的时间,因此BuildBatch的消耗就可以忽略不计了。由于在另外的线程里面,所以只要那个线程没有超负荷,我们在主线程看到的Profile怎么看都不会有差。

        根据文章 《Fill-rate, Canvases and input》的介绍来看,反正是没有必要建立那么多的Canvas,几个画布就OK了:

        In Unity 5.2, the batching code was substantially rewritten, and is considerably more performant compared to Unity 4.6, 5.0 and 5.1. Further, on devices with more than 1 core, the Unity UI system will move most of the processing to worker threads. In general, Unity 5.2 reduces the need for aggressively splitting a UI into dozens of Sub-canvases. Many UIs on mobile devices can now be made performant with as few as two or three Canvases.

        综上可知:Unity将 Canvas.BuildBatch 的过程,也就是网格重建的过程放在了子线程中,从而减少了主线程的压力。但是这部分的工作量却是依旧存在的,只是官方建议我们没必要使用多个Canvas。我猜测是因为优化后的网格重建的消耗 小于 DrawCall 的消耗,所以以优化DrawCall为主。

2.3、Canvas仍可用于Text和Image的分离

        虽然动静分离的意义不大了,但是Text和Image的分离的意义还是很大的。经测试,多个Text和多个Image分处于两个独立的节点,在绘制是并不一定是先绘制完Image,再绘制Text。具体情况比较复杂,可能是先绘制一两个Image,然后一两个Text,然后继续绘制。他的合批计算比较复杂,从经验来看大概是类似“一层一层堆积”的感觉。先是最底一层的控件在窗口内进行平铺,铺满后算一层,有多少批次算多少。然后再往上铺一层,再算一次合批。

        所以Text和Image穿插,会导致可以在同一层合批的图片/文本被分隔在了不同的“层”,导致合批中断。

        最为方便的操作方式是将Image和Text各自的父节点各挂载一个Canvas,这样就能实现强制分组。至少在Canvas下的同一字体的Text就一定是在一批中了。

3、 总结:

        新版的Unity(5.2+)将 Canvas.BuildBatch 放在了其他线程进行操作,而现在的手机一般都是多核(骁龙650就是6核了),电脑也是,所以动静分离的优化不会对帧率造成影响。过多的Canvas反而会打断合批,增加DrawCall,其实也是需要取舍的。不过即便在别的线程里面操作,也是要进行运算的,运算多一些CPU发热手机就会降频,这也是很麻烦的事情。

        只能说动静分离之类的操作在新的版本下没有那么有必要,但是也不是没有没有用,有点鸡肋。

        不过在测试的时候,如果使用了上千个变化的UI元素和上千个不变的元素进行测试,还是能发现动静分离的差别的。其实这个原因猜测是用于计算Canvas.BuildBatch的线程耗时已经超过了主线程,造成掉帧。不过在一般的游戏中,是不存在这么多UI元素的,所以也不用担心。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/142901.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号