Unity GUI(uGUI)使用心得与性能总结 - 简书
Unity GUI(uGUI)使用心得与性能总结
背景和目的
小哈接触Unity3D也有一段时间了，项目组在UI解决方案的选型一直是用的原生的uGUI，因此本人也是使用了一段时间的uGUI，在uGUI的使用方面积累了一些自己的经验，在此进行一个记录与总结。
本文接下来将会对uGUI的Runtime性能进行着重讨论，其它的因素也很多而且很重要，但是一篇文章讲清楚一件事就好了，文后会提供uGUI的最佳实践与一些使用技巧，不想看全文的建议直接到最下面看杰伦，啊，不对，是结论。
影响uGUI性能的因素与检查工具
游戏中的UI与其它游戏中的元素本质上是一样的，相对来说的不同点在于，UI通常是由2D的图片组合而成，会包含较多的透明元素与渐变元素，而且一般来说会显示在屏幕的最顶层。
因此，从共同点上说，UI的Runtime性能消耗也可以划分为CPU消耗、GPU消耗与内存消耗。其中对于每一部分的具体的消耗以及优化，有诸多大神在网络上发表过文章，比如。但是，总有一个大家都绕不开的点，那就是Drawcall，Drawcall数量直接影响了游戏的帧率，解决了Drawcall问题，应该算是解决了80%的问题，所以接下来就着重针对uGUI的特性讲一讲UI系统的Drawcall。
Unity 5.0在Drawcall查看方面有一个非常有用的工具，Frame Debugger，通过[Window-&Frame Debugger]打开。
Frame Debugger(Only in Unity5.0+)
使用该工具时，游戏会暂停，然后Unity会将当前正在执行的一帧的内容缓存下来，其中所有Drawcall你都可以进行前进与后退操作，从而能够从Drawcall级别分析开销。所以没有升级5.0的小伙伴赶紧升级啊。
此外，在用FD看UI性能时，有一个小窍门就是新开一个空的Scene，然后将你的UI Prefab拖到该空场景中，此时就不会受场景中其它物体的影响而只显示UI的Drawcall了。
uGUI性能优化
讲了那么多，开始进入正题。在降低Drawcall方面，一个非常重要的概念就是Batch，因为一次Drawcall相当于CPU与GPU进行一次沟通的成本，如果CPU能一次多打包一些信息给GPU，那么Drawcall数量自然就下来了，这个打包传输信息给GPU的过程就叫做Batch，批处理。那么什么情况下这些信息可以打包呢？从uGUI的角度，如果你的UI中组件的材质与纹理均相同，这几个组件就可以被Batch。在Image组件中，材质对应Source Image，纹理则对应Material；在Text组件中材质对应Font，纹理也是Material。以上对应大部分情况适用，在少部分特殊shader下会失效（待深入研究）。
Common UI Components
原理是这样，但是实际用起来还需要一些技巧，遵循Unity的一些渲染次序的规则，才能真正的实现性能优化。以下就一一进行讨论。
上面有提到Source Image图集，所谓的图集，就是将好多张零碎的2D小图片通过Unity自带的Sprite Packer或第三方的Texture Packer合并到一张大图，这样做有几大好处，
图片尺寸为2的次幂时，GPU处理起来会快很多，小图自己是做不到每张图都是2的次幂的，但打成一张大图就可以（浪费一点也无所谓）；
CPU在传送资源信息给GPU时，只需要传一张大图就可以了，因为GPU可以在这张图中的不同区域进行采样，然后拼出对应的界面。注意，这就是为什么需要用同一个Source Image图集的原因，是Batch的关键，因为一个Drawcall就把所有原材料传过去了，GPU你画去吧。
但是显然把所有图片打成一张图集是不合理的，因为这张图可能非常大，所以就要按照一定规则将图片进行分类。在分类思路上，我们希望做到Drawcall尽可能少，同时资源量也尽可能少（多些重用），但这两者某种程度上是互斥的，所以折衷一下，可以遵循以下思路：
设计UI时要考虑重用性，如一些边框、按钮等，这些作为共享资源，放在1~3张大图集中，称为重用图集；
其它非重用UI按照功能模块进行划分，每个模块使用1~2张图集，为功能图集；
对于一些UI，如果同时用到功能图集与重用图集，但是其功能图集剩下的“空位”较多，则可以考虑将用到的重用图集中的元素单独拎出来，合入功能图集中，从而做到让UI只依赖于功能图集。也就是通过一定的冗余，来达到性能的提升。
P.S. 如果你用Unity自带的Sprite Packer去打包图集，那么你可能要在运行模式下才能看到效果。
Unity GUI层级合并规则与批次生成规则
uGUI的层叠顺序是按照Hierarchy中的顺序从上往下进行的，也就是越靠上的组件，就会被画在越底部。所以UI就是这样一层一层地叠上去画出来的。当然这样一个一个地画效率肯定是不能接受的，所以要合并，要Batch，Unity自身就提供了一个算法去决定哪些层应该合并到一起，并以什么样的顺序进行绘制。所有相邻层的可Batch的UI元素将会在一个Drawcall完成。接下来就来讨论一下Unity的层级合并与计算算法。
Unity的UI渲染顺序的确定有2个步骤，第一步计算每个UI元素的层级号；第二步合并相同层级号中可以Batch的元素作为一个批次，并对批次进行排序；
先从直观的角度来解释计算层级号的算法：如果有一个UI元素，它所占的屏幕范围内（通常是矩形），如果没有任何UI在它的底下，那么它的层级号就是0（最底下）；如果有一个UI在其底下且该UI可以和它Batch，那它的层级号与底下的UI层级一样；如果有一个UI在其底下但是无法与它Batch，那它的层级号为底下的UI的层级+1；如果有多个UI都在其下面，那么按前两种方式遍历计算所有的层级号，其中最大的那个作为自己的层级号。
这里也给一下伪代码，假设所有UI元素（抛弃层级关系）都按从上往下的顺序被装在一个list中，那么每个UI元素对应的层级号计算可以参考以下：
function CalLayer(List UIEleLst)
if(UIEleLst.Count == 0 )
//Initial the first UI Element as layer 0
UIEleLst[0].layer = 0;
for(i = 1 ~ UIEleLst.Count){
var IsCollideWithElements =
//Compare with all elements beneath
for(j = i-1 ~ 0){
//If Element-i collide with Element-j
if(UIEleLst[i].Rect.CollideWith(UIEleLst[j].Rect)){
IsCollideWithElements =
//If Element-i can be batched with Element-j, same layer as Element-j
if(UIEleLst[i].QualifyToBatchWith(UIEleLst[j])){
UIEleLst[i].layer = UIEleLst[j].
//Or else the layer is larger
UIEleLst[i].layer = UIEleLst[j].layer + 1;
//If not collide with any elements beneath, set layer to 0
if(!IsCollideWithElements)
UIEleLst[i].layer = 0;
有了层级号之后，就要合并批次了，此时，Unity会将每一层的所有元素进行一个排序（按照材质、纹理等信息），合并掉可以Batch的元素成为一个批次，目前已知的排序规则是，Text组件会排在Image组件之前渲染，而同一类组件的情况下排序规则未知（好像并没什么规则）。经过以上排序，就可以得到一个有序的批次序列了。这时，Unity会再做一个优化，即如果相邻间的两个批次正好可以Batch的话就会进行Batch。举个栗子，一个层级为0的ImageA，一个层级为1的ImageB（2个Image可Batch）和一个层级为0的TextC，Unity排序后的批次为TextC-&ImageA-&ImageB，后两个批次可以合并，所以是2个Drawcall。再举个栗子，一个层级为0的TextD，一个层级为1的TextE（2个Text可Batch）和一个层级为0的ImageF，Unity排序后的批次为TextD-&ImageF-&TextE，这时就需要3个Drawcall了！（是不是有点晕，再回顾下黑体字）
以下的伪代码有些偷懒，实在懒得写排序、合并之类的，一长串也不好读，几个步骤列一下，其它诸位看上面那段文字脑补下吧...
function MergeBatch(List UIEleLst)
//Order the UI Elements by their layers and batch-keys,
//batch-key is a combination of its component type,
//texture and material info
UIEleLst.OrderBy(
(uiElement)=&{return this.layer & uiElement.layer
|| this.BatchKey() & uiElement.BatchKey()}
//Merge the UI Elements with same layer and batch-key as a batch
var BatchLst = UIEleLst.MergeSameElementsAsBatch();
//Make adjacent batches with same batch-key merged
BatchLst.MergeAdjacentBatches();
return BatchL
根据以上规则，就可以得出一些“摆UI”的技巧：
有相同材质和纹理的UI元素是可以Batch的，可以Batch的UI上下叠在一块不会影响性能，但是如果不能Batch的UI元素叠在一块，就会增加Drawcall开销。
要注意UI元素间的层叠关系，建议用“T”工具查看其矩形大小，因为有些图片透明，但是却叠在其它UI上面了，然后又无法Batch的话，就会无故多许多Drawcall；
UI中出现最多的就是Image与Text组件，当Text叠在Image上面（如Button)，然后Text上又叠了一个图片时，就会至少多2个Drawcall，可以考虑将字体直接印在下面的图片上；
有些情况可以考虑人为增加层级从而减少Drawcall，比如一个Text的层级为0，另一个可Batch的Text叠在一个图片A上，层级为1，那此时2个Text因为层级不同会安排2个Drawcall，但如果在第一个Text下放一个透明的图片（与图片A可Batch），那两个Text的层级就一致了，Drawcall就可以减少一个。
Mask对于uGUI性能来说是噩梦一般的存在，因为很可能因为这个东西，导致Drawcall数量成倍增长。
Mask实现的具体原理是一个Drawcall来创建Stencil mask(来做像素剔除)，然后画所有子UI，再在最后一个Drawcall移掉Stencil mask。这头尾两个Drawcall无法跟其他UI操作进行Batch，所以表面上看加个Mask就会多2个Drawcall，但是，因为Mask这种类似“汉堡包式”的渲染顺序，所有Mask的子节点与其他UI其实已经处在两个世界了，上面提到的层级合并规则只能分别作用于这两个世界了，所以很多原本可以合并的UI就无法合并了。
所以，在使用uGUI时，有一些建议：
应该尽量避免使用Mask，其实Mask的功能有些时候可以变通实现，比如设计一个边框，让这个边框叠在最上面，底下的UI移动时，就会被这个边框遮住；
如果要使用Mask时，需要评估下Mask会带来的性能损耗，并尽量将其降到最低。比如Mask内的UI是动态生成的话（比如List组件），那么需要注意UI之间是否有重叠的现象。
uGUI的性能其实涉及到的方面很多，这里列出来的只是目前能想到的，因为个人能力有限，可能出些纰漏。对于文中的一些建议，这里整理一下得出一些最佳实践：
设计UI时要考虑重用性，如一些边框、按钮等，这些作为共享资源，放在1~3张大图集中，称为重用图集；
其它非重用UI按照功能模块进行划分，每个模块使用1~2张图集，为功能图集；
对于一些UI，如果同时用到功能图集与重用图集，但是其功能图集剩下的“空位”较多，则可以考虑将用到的重用图集中的元素单独拎出来，合入功能图集中，从而做到让UI只依赖于功能图集。也就是通过一定的冗余，来达到性能的提升。
有相同材质和纹理的UI元素是可以Batch的，可以Batch的UI上下叠在一块不会影响性能，但是如果不能Batch的UI元素叠在一块，就会增加Drawcall开销。
要注意UI元素间的层叠关系，建议用“T”工具查看其矩形大小，因为有些图片透明，但是却叠在其它UI上面了，然后又无法Batch的话，就会无故多许多Drawcall；
UI中出现最多的就是Image与Text组件，当Text叠在Image上面（如Button)，然后Text上又叠了一个图片时，就会至少多2个Drawcall，可以考虑将字体直接印在下面的图片上；
有些情况可以考虑人为增加层级从而减少Drawcall，比如一个Text的层级为0，另一个可Batch的Text叠在一个图片A上，层级为1，那此时2个Text因为层级不同会安排2个Drawcall，但如果在第一个Text下放一个透明的图片（与图片A可Batch），那两个Text的层级就一致了，Drawcall就可以减少一个。
应该尽量避免使用Mask，其实Mask的功能有些时候可以变通实现，比如设计一个边框，让这个边框叠在最上面，底下的UI移动时，就会被这个边框遮住；
如果要使用Mask时，需要评估下Mask会带来的性能损耗，并尽量将其降到最低。比如Mask内的UI是动态生成的话（像List组件），那么需要注意生成的UI之间是否有重叠的现象；
有空好好看下Unity GUI层级合并规则与批次生成规则这一节。【uGUI】Rect Mask 怎么用呢？【unity3d吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：76,239贴子：
【uGUI】Rect Mask 怎么用呢？收藏
可以让一个画布只显示一部分吗？
0元预约！「忠于体验 打磨颜值」魅蓝 6即将火热上市！
15:30 ，秒处有image mask的用法介绍
登录百度帐号推荐应用阅读(25178)
Unity终于在即将到来的4.6版本内集成了所见即所得的UI解决方案。事实上从近几个版本开始，Unity就在为这套系统做技术扩展，以保证最终能实现较理想的UI系统。本文试图通过初步的介绍和试用，让读者对这套系统有大体的了解，以便更进一步评估这套UI系统好不好用，适合用在什么项目。为了避免坑挖太深，更进一步的试用和评估我将在《》中进行论述。为论述方便，下文将这套New UI System简称为uGUI，并且以X-UI指代现有第三方UI插件。
（测试只针对Unity 4.6.0 beta 10，正式版可能会有所出入。目前Unity没提供文档，本人半桶水，欢迎群众在微博或Issues里吐槽！）
二、Rect Transform
Rect Transform继承自Transform，是uGUI相比X-UI最显著的区别[]。当你为Empty GameObject加入一个UI Component时，Transform会自动转换为Rect Transform。Rect Transform尽量整合了X-UI常见的anchor(相对父物体的锚点),&pivot(中点),&stretch(拉伸)等属性。值得一提的是，这里的anchor是Rect而非Vector2，因为它不仅用于偏移，而且用于缩放。点击Rect Transform上的准心图标，还能在弹出的Anchor Presets面板中对其进行快速设置。
这个面板还是不够直观，我们可以把它看成一张表，上面四个图标用于设置列，左边四个图标用于设置行，也可以直接点击里面的16个图标同时设置行和列。强大的地方是，按住shift时能同时设置pivot，这时能发现控件虽然不动但position已经在改变。如果按住alt，则设置anchor的同时设置position。如果shift和alt同时按住，那么你就能同时设置anchor, pivot和position。这个操作方式比起X-UI，真的高明很多，对多分辨率适配很有帮助。
除此之外，Rect Transform还提供了Blueprint和Lock Rect选项，前者用于对旋转过的元素进行定位，后者据说明是能在设置anchor时保持位置不变，暂时没搞明白。
uGUI可以直接在Hierarchy面板中上下拖拽来对渲染进行排序(支持程序控制)，越上面的UI会越先被渲染，相比X-UI的global depth排序，这样的拖拽设计很讨好用户。同时在结构上则和ex2D采用的local depth类似，这样GO只和同级其它GO进行排序，开发组件会很方便。需要注意的是，这里排序只是相对UI而言，其它3D物体还是按原先的次序渲染，并且UI总是渲染在3D物体上面。这就导致你不能像用ex2D那样直接将粒子系统插入到两个UI之间。
这种无需填写depth值的排序方式，容易导致没有手工做sprite packing的free版用户遇到draw call增加。因为所有物体的depth都是自动设置的，Unity保证了每个物体的depth都是唯一的。这时假设你有一个格子控件，每个控件用到了两个Sprite，但你并没有把Sprite都拼到同一张贴图上。于是你每复制一个新的格子出来，draw call就会增加2个，因为Unity会以格子为单位依次绘制。pro用户由于有sprite packing机制，不用担心这个问题。（这种情况在ex2D里，是以默认提供"unordered"的渲染方式来解决的，这也是NGUI的默认做法。在这种情况下ex2D会优先以相同depth的相同Sprite为单位绘制，因此不论有多少个格子，draw call都是2个。除非你就是希望以格子为单位进行渲染[]，那么你可以在ex2D里设置渲染方式为"ordered"，或者在NGUI里给每个格子设置不同的depth。
uGUI自带了以上控件，其中Image用于显示Sprite，Raw Image用于显示Texture，Image Mask和Rect Mask用于clipping。所有控件都是MonoBehaviour，可以直接从Inspector里拖到其它GameObject上。
uGUI用Image控件显示图片，图片就是一个Sprite，这意味着Pro用户不用再制作atlas了，相比X-UI是个大进步，Free用户一样可以手动做Packing。Image提供了Simple,&Sliced,&Tiled,&Filled四种效果，和X-UI保持一致。
4.2 Button
uGUI里，Button控件由两个GameObject组成，一个包含Image, Button等Component，一个包含Text等Component。这样设计很组件化，唯一的问题是当用户想修改Button时，容易不小心选中Label或其它实体。
Button Component主要执行Transition和事件两个操作。
Transition可选择改变颜色、更换贴图或自定义动画，使用起来简单方便，也能利用动画定义更丰富的表现。我会再写一篇文章演示Button的Transition。
事件也是所见即所得的，在OnClick里面可以添加多个命令，命令可以选择对应的目标、操作和参数。用法简单，有需要也可以换程序控制。
目标可以是任意Object，例如其它GameObject或者Project里的Asset
操作可以是需要设置的参数或调用的方法
参数分成Dynamic和Static，Dynamic能将控件的参数单向绑定到目标参数，Static则将目标参数设置成预设值。按钮没有Dynamic参数，Toggle, Slider等控件才有。
5.1 Event Trigger
uGUI控件往往只提供一个自带事件，要响应更多基本事件的话，需要添加Event Trigger组件。Event Trigger包含以下事件：
PointerEnter, PointerExit, PointerDown, PointerUp, PointerClick
Move, Drag, Drop, Scroll
KeyDown, KeyUp, Select, Deselect
可以在Event Trigger中Add多个事件，每个事件都可以添加多个命令，用法和控件自带事件一致。
5.2 Graphic Raycaster
每个Canvas都有一个Graphic Raycaster，用于获取用户选中的uGUI控件。多个Canvas之间通过设置Graphic Raycaster的priority来设置事件响应的先后次序。当Canvas采用World Space或Camera Space时，Graphic Raycaster的Block选项可以用来设置遮挡目标。
5.3 Event System
创建uGUI控件后，Unity会同时创建一个[]叫EventSystem的GameObject，用于控制各类事件。可以看到Unity自带了两个Input Module，一个用于响应标准输入，一个用于响应触摸操作。Input Module封装了对Input模块的调用，根据用户操作触发各Event Trigger。理论上我们可以编写自己的Input Module，用来封装各种外部设备的输入，只要加入Event System所在的GameObject就行。
Event System组件则统一管理多个Input Module和各种Raycaster。它每一帧调用多个Input Module处理用户操作，也负责调用多个Raycaster用于获取用户点击的uGUI控件以及2D和3D物体。
2D渲染分两大类，一类是单纯的Sprite绘制，用于渲染场景、角色、粒子等，另一类是UI绘制。Unity将这两类需求划分成了SpriteRenderer和uGUI两部分，前者由Transform&+&SpriteRenderer实现，后者由Rect Transform&+&CanvasRenderer&+&UI控件&+&Canvas[]实现，这样的两套相对独立的机制比起X-UI的UI控件继承自SpriteRenderer更为合理。因为在2D游戏里SpriteRenderer只需要关心最基本的面片渲染，注重效率，而UI注重各类变换、对齐、操作、动画，还常常需要Resize VBO。如果SpriteRenderer在设计上需要兼顾UI，就会像X-UI那样设计得太过复杂，在用户体验和性能上都很不好。
这里我们探讨一下uGUI的渲染机制，当我们渲染多个使用相同Sprite的控件时，并没发生dynamic batching，但是drawcall也没有上升。这就说明Unity在内部使用了专门的一套batching机制，把多个控件的VBO事先合并成了一个。也就是说CanvasRenderer不负责实际渲染，而是由Canvas批量渲染多个CanvasRenderer，这和部分X-UI采用的做法一致。这样单独batch的设计有可能使得性能比SpriteRenderer好，也可能导致性能更差。性能会更好的情况在ex2D里已经证实了，主要原因是这样能更好的平衡CPU和GPU负载，并且能做到更优化的batching算法。性能更差的情况，在去年旧版的NGUI测试时也遇到了，根本原因还是优化不到位导致的（不是贬低，不同工具的取舍和面向市场都不同）。而Unity的 SpriteRenderer在手机上的渲染跑分是和ex2D持平的，CanvasRenderer又比SpriteRenderer快[]，因此uGUI的性能不用担心。由于目前没有Mac版本，我会在正式版发布后进行一次手机跑分测试。
uGUI功能完善，操作简洁，很接地气。可以说uGUI是相对X-UI的全面升级，整体架构更为严谨，实现更为清晰。依托4.5的Module Manager，uGUI以Package的形式提供，也能获得快速的升级[]。作为ex2D v2.0开发者之一，我很看好它将来的发展，uGUI将在大多数场合取代X-UI。
初步感受：
RectTransform
Event/单向数据绑定
直接在Hierarchy中排序
Pro用户可用Sprite的动态拼图，无需手工拼图
7.3 小遗憾
Anchor Presets面板还不够直观。
用户想修改Button时，很容易修改到Label。
当Hierarchy面板内的目标节点展开子节点后，无法将其它节点直接拖动到目标的正下方。
7.4 小问题
Input组件对方向键的支持有问题。
Game View dock到主窗口后，top定位有误，把toolbar的高度也算进去了。
我们在其它平台上开发类 Entity-Component框架时，讨论过Unity为什么不在底层对transform做特殊处理，以避免插件作者手工缓存transform来优化query transform引起的开销，甚至是将transform直接整合进GameObject。原因是现在的transform是3D的，将来完全可能推出 2D Transform。所以Unity在之前的版本里一直保留着transform的独立性。
我不能完全肯定一定是Canvas，但通过Canvas和CanvasRenderer的接口来看，这个可能性很大。
基于更好的平衡CPU和GPU负载 + 更优化的batching算法，以Unity的实力CanvasRenderer超越SpriteRenderer问题不大。而且如果性能不会提升，uGUI只要像2D Toolkit那样给每个控件直接添加MeshRenderer，也就是说uGUI直接用已有的SpriteRenderer就好，不太可能加入新的CanvasRenderer性能反而更慢。
Unity允许多个Event System同时存在，但同一时刻只有一个能够生效。
uGUI的控件、Event等模块以包的形式提供，位于程序目录下的%UNITY%\Editor\Data\UnityExtensions\Unity\GUISystem\4.6.0，Unity 提供了两个运行时版本的DLL，分别用于创作和发布。区别主要是发布版不含一些Editor中才用得到的代码。由于DLL没办法通过预编译符号来进行条件编译，因此Unity使用这种方式进行权衡，用户发布时无需手工切换DLL版本，满足了闭源，又兼顾了执行效率。这样就甩开了第三方插件几条街，很多插件在这个问题上不是牺牲性能就是无奈开源。
有时还是会需要以格子为单位渲染，例如当格子之间需要重合，这种需求在UI里不常见。
阅读排行榜ui的Mask和RectMask2d有什么区别？【unity3d吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：76,239贴子：
ui的Mask和RectMask2d有什么区别？收藏
我做ui的时候，有时间用Mask不能遮挡，而RecAsk2d就可以没看出什么区别。。。求答
登录百度帐号推荐应用