unityUI优化笔记

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的效果

---