unityUI优化笔记

unityUI优化笔记,第1张

unityUI笔记

前言:

       这只是一个自己在处理unityUI batches的时候的笔记,仅仅有参考价值,如果有异议或者错误的地方可以指出。所有的测试都是用unity自带的spriteatlas进行图集测试,并且使用的是同一个canvas。

UI节点的Z轴影响

       Unity在进行和批处理时,如果有一个列表是ABCDE,其中的C的z轴不为0,那么就会打断后面的DE的合批,打断规则我这边也测试了,一般来讲分两种情况。

1在C后面的节点全是和C同一图集上时,Cz轴不为零是不会阻止后面的元素和之前的元素进行合批。

2在C后面的节点存在至少一个不是C图集时,如果C的图集和前面的AB的其中一个是同一图集那么C会和其合在一起C后面的节点会重新计算。如果C和前面的AB不属于同一图集,那么C会单独计算然后C后面的元素再次进行合批。

所以我们一般在开发的时候需检查UI的Z轴值,甚至会写一个工具脚本进行预制件的Z轴值的检查和强制更改。

UI父节点存在mask组件的影响

       我们在做UI的时候不免会有用到mask的组件,比如一些特殊的切图表现,还有就是我们常常用到的scrollview。这边我们常常用到的有两种mask:

[if !supportLists]1    [endif]Image组件+ mask组件,也是unity自带的scrollview所用的用法。这种的做法的优点呢,我只想到一个就是可以自定义遮罩的范围。缺点呢也很明显就是会阻断mask内和外的合批。因为这种做法是不可避免的,而且会多增加两层的drawcall,所以能尽量少用就少用。

[if !supportLists]2    [endif]使用rectmask2D,同样缺点是会阻断mask内和外的合批,还有就是固定的长方形的遮罩虽然有偏移值,但仅限四边模糊。优点呢就是比上一个组合少了两个drawcall。

UI与之间重合影响

       在两个分别为两张图集的时候,会出现重合或者不重合的情况。如果所有都不重合,那么出去Z轴和mask和canvas的影响基本可以确是可以同一图集的合批的。如果是出现重合,那么就会出现阻断合批的情况。拿AB两张图集进行举例:

[if !supportLists]1    [endif]如果是A1+B+A2这个样式的B盖在A1上,A2盖在B上那么就会有3个drawcall,如果A2没有盖住B,那么也不会阻断只有两个Drawcall。

[if !supportLists]2    [endif]如果是A1+B1+B2+A2的样式,如果不同图集的都有重合那么就是4个drawcall,

如果同一图集的两个只和另外一图集的其中一张有重合,那么就只有3个drawcal,同样四张不同图集的完全没有重合则只有2个drawcall。

[if !supportLists]3    [endif]有的切的时候因为有阴影的存在或者是模糊效果,的边缘存在透明度很高的部分,这部分虽然肉眼观看是透明的,但是也算是两张有重合。

UI中text的影响

       Text字体大家都知道其实也是一个大大的图集,其规则和image的重合原理基本相似,唯一不同的是其组件的范围的空白区域重合是不会影响,能影响到的只有字体附近的一些区域。需要注意的是一般都是用自己制作的字体包,这样可控。字体包的数量尽量控制在一个,这样也少了图集很多重合的麻烦。
UI图集整理

[if !supportLists]1    [endif]尽量按照每个界面一张图集的方式,进行图集整理。

[if !supportLists]2    [endif]公用部分的,如果是的大小没有那么的大,则可以放在界面图集这边。如果放在界面图集会使原图集变大,则不放。

[if !supportLists]3    [endif]背景图尽量只有一张的这种结构,辅助背景图,装饰,能不要则不要,能合在同一张背景图最好。

[if !supportLists]4    [endif]不规则图形的会占用大量的空白区域,所以慎用。

[if !supportLists]5    [endif]纯色填充图用22纯白图代替,透明度为0的统一用22透明图代替。

[if !supportLists]6    [endif]进度条或者一些背景,按钮可以做成九宫格的尽量做成九宫格。

[if !supportLists]7    [endif]模糊,高光,渐变,这些很难做成九宫格的,可以尽量的控制好体积。

[if !supportLists]8    [endif]如果图集纵向或者横向因为某一个过长或者过宽,可以考虑对这张分成两份或者三份的方式切,最后拼凑,能在原有的的宽度和长度下放得下,则至少减少了一半的体积。

[if !supportLists]9    [endif]的空白区域过大,可以考虑切成两部分或者多部分进行拼凑。

[if !supportLists]10  [endif]字如果不是艺术字尽量使用我们的字体包,这样多语言也会少一部分资源。

综上

       在做UI的时候一些背景图能做成一张,尽量做成一张。能再同一层级放所有的,文字,则最好再统一层级。交叉重合地方能不用则不用,尽量保证UI界面干净清晰。Mask相关的结构能尽量少用就少用。图集能放得下的放在一张,放不下的分好类,每个界面的多数元素尽量在同一图集上。

给警告框添加一个子UISprite,让该UISprite的深度小于警告框,然后给其添加BoxCollider组件并使其大小覆盖整个屏幕,调整其透明度为0即可。
原理就是所有的按钮交互都是通过像机射线与BoxCollider组件来触发的,只需要用一个透明的物体用BoxCollider来遮罩住后面的物体就可以锁定按钮交互的层级

这没什么好法吧,只能是修改boxcolider的范围足够大,就是每一帧都在colider范围内。再就是在某一帧(超出的那一帧),获取boxcolider组件的size,给它重新赋一个合适值,不过我感觉没有必要,还是把colider调大一点,你可以看一下2D的游戏,一般都是这么做的

控件是UGUI内置的,控件上面因因包含不同的组件而不同。

关于按钮的事件统一管理方法

小练习:写个小框架滑动菜单

在实际使用UGUI开发的过程中发现一个UGUI的BUG:当Content下的子物体增加时,ScrollBar下的Handle滑条大小没有实时根据发生Content下的子物体数量发生变化。(在Hierarchy面板中右键创建UI->ScrollView,在子物体中找到Content,需要按行列布置的游戏物体都作为Content的子物体挂在Content下)(以开发垂直的ScrollView为例)在查找问题的过程中发现:我的这个项目里Content的高小于遮罩层Viewport的的高,致使ScrollBar滑条的size一直为1的状态。调整Content的高使高大于遮罩层Viewport的的高后又发现如下问题:在编辑模式下ScrollBar滑条的size只根据Content与遮罩层Viewport的大小比例进行了调整,而不是根据Content的子物体数量进行变换,致使了在Content下添加的子物体的总高大于Content设置的高时下拉滑条并不能全部显示的问题,并且在游戏运行时ScrollBar的Size又重新变回1了,无论怎么调整参数都无济于事。于是自己写了一个脚本,根据Content下的子物体的个数来控制Content的宽高(原理是修改RectTransform的sizedelta)

通道遮罩 ColorMask可以让我们制定渲染结果的输出通道,而不是通常情况下的RGBA这4个通道全部写入。可选参数是 RGBA 的任意组合以及 0, 这将意味着不会写入到任何通道,可以用来单独做一次Z测试,而不将结果写入颜色通道

实现如图效果,前面的cube改为DepthMask的shader,实现在前面的cube透明,但是仍然挡住了后面cube的效果


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/13341140.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-18
下一篇 2023-07-18

发表评论

登录后才能评论

评论列表(0条)

保存