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)


相关推荐

  • 蓝鲸bk-sops源码学习二:流程组件注册实现原理「建议收藏」

    蓝鲸bk-sops源码学习二:流程组件注册实现原理「建议收藏」研究背景自己的项目都是python3.6开发。想使用蓝鲸的流程系统,真是千难万难。魔改路上真是一路坎坷。由于BK-SOPS需要结合蓝鲸的一整套服务才能够运行,所以单独把标准运维的流程系统抽出来然后融合进自己的系统。看看蓝鲸标准运维的功能多元接入支持:标准运维对接了蓝鲸通知、作业平台、配置平台等服务,作为官方标准插件库提供服务,还支持用户自定义接入企业内部系统,定制开发标准插件。可视化流…

  • Tomcat命令

    Tomcat命令

  • DAVINCI DM365-DM368开发攻略——开发环境搭建(DVSDK4.02) 适用于DM3730[通俗易懂]

    DAVINCI DM365-DM368开发攻略——开发环境搭建(DVSDK4.02) 适用于DM3730[通俗易懂]DAVINCIDM365-DM368开发攻略——开发环境搭建(DVSDK4.02)标签:开发环境 搭建 dvsdk DM368 DM365原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://zjbintsystem.blog.51cto.com/964211/621435第一节、 技术开发环

  • hashmap遍历取值_java map遍历

    hashmap遍历取值_java map遍历HashMap遍历取值

  • 用python图像处理_python图像处理库

    用python图像处理_python图像处理库第1章图像处理入门1.1什么是图像处理及图像处理的应用1.1.1什么是图像以及图像是如何存储的1.1.2什么是图像处理1.1.3图像处理的应用1.2图像处理流程1.3在Python中安装不同的图像处理库1.3.1安装pip1.3.2在Python中安装图像处理库1.3.3安装Anaconda发行版1.3.4安装Jupyter笔记本1.4使用Pytho…

  • redis客户端连接工具连接docker里面redis_gbase客户端连接工具

    redis客户端连接工具连接docker里面redis_gbase客户端连接工具Redis客户端连接工具AnotherRedisDesktopManagermac想用到brew的话,地址:https://www.jianshu.com/p/b7b789a2ed2cAnotherRedisDesktopManager为redis可视化工具,真的巨好用呀!!!原文地址:https://blog.csdn.net/huizhou_achao/article/details/108467792下载及安装教程地址:https://github.com/qishibo/An

发表回复

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

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