大家好,又见面了,我是你们的朋友全栈君。
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账号...