(转)Unity 之 UGUI 小总结
转自：http://www.jianshu.com/p/5b6f5022662e
开发过程中对UGUI的一个小总结。
首先从原画师拿到效果图，美术切图，拿到碎图后打成大图。
我们先来说一下图：RGBA8888：每一个通道占8位。大图：1024*1024。高端 机：2048*2048。
我们通常从美工那里拿来碎图，歪歪使用的一个工具texturepacker 把碎图打成大图，导出成 .tpsheet .png格式。其次我们要做的是，在Unity3d中导入插件texture import(此插件会自动把大图打成图集).然后把大图导入U3D。
在UI优化中较为明显而众所周知的就是降低DrawCall(注释：DrawCall CPU向GPU发送的一次渲染指令)。而降低DrawCall我们会采用静态合批和动态合批。（注释：合批必须同类型 Mesh 同材质。）DrawCall的标准 RGP 类 小于 150。
然而，工作中我们优化大概分为UI层级计算，UI重建和多层级渲染。接下来我们来说一下：
UI层级 计算 ：
1，计算层级：
1,如果有一个UI元素，它所占的屏幕范围内（通常是矩形），如果没有任何UI在它的底下，那么它的层级号就是0（最底下）；
2,如果有一个UI在其底下且该UI可以和它Batch，那它的层级号与底下的UI层级一样；
3,如果有一个UI在其底下但是无法与它Batch，那它的层级号为底下的UI的层级+1；
4,如果有多个UI都在其下面，那么按前两种方式遍历计算所有的层级号，其中最大的那个作为自己的层级号。
合并批次原则;
同层级{同材质球，}
{0 : { image , image, text }}
1,Unity会将每一层的所有元素进行一个排序（按照材质、纹理等信息），合并掉可以Batch的元素成为一个批次
2,Text组件会排在Image组件之前渲染。
3,，Unity会再做一个优化，即如果相邻间的两个批次正好可以Batch的话就会进行Batch（这么处理，可以合成一个批次，如下：）
{0 : { text image }}textàimage
{1 : { text ,image }}
0: textàimage 1: textàimage
下面我们来看一个列子，这样会更加的清晰：
一个层级为0的ImageA，一个层级为1的ImageB（2个Image可Batch）和一个层级为0的TextC，
textCàimageAàimageB
一个层级为0的TextD，一个层级为1的TextE（2个Text可Batch）和一个层级为0的ImageF，
0 : textD –>imageFà1 : textEàimage h 3：
0 : textD –>imageFà1 : textEàimage h
总结:
1,有相同材质和纹理的UI元素是可以Batch的，可以Batch的UI上下叠在一块不会影响性能，但是如果不能Batch的UI元素叠在一块，就会增加Drawcall开销
2,尽量让同一个材质球上的东西 放在同一级上
3,有些情况可以考虑人为增加层级从而减少Drawcall，比如一个Text的层级为0，另一个可Batch的Text叠在一个图片A上，层级为1，那此时2个Text因为层级不同会安排2个Drawcall，但如果在第一个Text下放一个透明的图片（与图片A可Batch），那两个Text的层级就一致了，Drawcall就可以减少一个。
Text0 –》Imageàtext 1
4,应该尽量避免使用Mask，其实Mask的功能有些时候可以变通实现，比如设计一个边框，让这个边框叠在最上面，底下的UI移动时，就会被这个边框遮住；
5, z值 保持为0
UI重建：
1，动静分离：
经常发生变动的ui单独放在一个Canvase
2，删除不必要的元素。
3，CanvasRender.setDisable .
4，Text的Best Fit选项.
5,Canvas的Pixel Perfect选项
6,使用缓存池来保存ScrollView中的Item,对于移出或移进View外的的元素，不要调用disable或enable,而是把它们放到缓存池里或从缓存池中取出复用。
7, 除了rebuild过程之外，UGUI的touch处理消耗也可能会成为性能热点。因为UGUI在默认情况下会对所有可见的Graphic组件调用raycast。对于不需要接收touch事件的grahic，一定要禁用raycast。对于unity5以上的可以关闭graphic的Raycast Target而对于unity4.6，可以给不需要接收touch的UI元素加上canvasgroup组件。
多层级渲染：
1,canvasRender .setdisable()
2,只挂载button替代 空的image
3，不要使用空的Image,在Unity中，RayCast使用Graphi作为基本元素来检测touch,在笔者参与的项目中，很多同学使用空的image并将alpha设置为0来接收touch事件，这样会产生不必要的overdraw。通过如下类NoDrawingRayCast来接收事件可以避免不必要的overdraw。
3. public class NoDrawingRayCast : Graphic
4. {
5. public override void SetMaterialDirty()
6. {
7. }
8. public override void SetVerticesDirty()
9. {
10. }
11. protected override void OnFillVBO(List vbo)
12. {
13. vbo.Cslear();
14. }
}
性能检测工具：
1profile
常见问题：
Q1：我在UGUI里更改了Image的Color属性，那么Canvas是否会重建？我只想借用它的Color做Animation里的变化量。
如果修改的是Image组件上的Color属性，其原理是修改顶点色，因此是会引起网格的Rebuild的（即Canvas.BuildBatch操作，同时也会有Canvas.SendWillRenderCanvases的开销）。而通过修改顶点色来实现UI元素变色的好处在于，修改顶点色可以保证其材质不变，因此不会产生额外的Draw Call。
Q2：Unity自带的UI Shader处理颜色时，改_Color属性不会触发顶点重建吗?
在UI的默认Shader中存在一个Tint Color的变量，正常情况下，该值为常数(1,1,1)，且并不会被修改。如果是用脚本访问Image的Material，并修改其上的Tint Color属性时，对UI元素产生的网格信息并没有影响，因此就不会引起网格的Rebuild。但这样做因为修改了材质，所以会增加一个Draw Call。
Q：动静分离或者多Canvas带来性能提升的理论基础是什么呢？如果静态部分不变动，整个Canvas就不刷新了？
在UGUI中，网格的更新或重建（为了尽可能合并UI部分的DrawCall）是以Canvas为单位的，且只在其中的UI元素发生变动（位置、颜色等）时才会进行。因此，将动态UI元素与静态UI元素分离后，可以将动态UI元素的变化所引起的网格更新或重建所涉及到的范围变小，从而降低一定的开销。而静态UI元素所在的Canvas则不会出现网格更新和重建的开销。
Q：UWA建议“尽可能将静态UI元素和频繁变化的动态UI元素分开，存放于不同的Panel下。同时，对于不同频率的动态元素也建议存放于不同的Panel中。”那么请问，如果把特效放在Panel里面，需要把特效拆到动态的里面吗？
通常特效是指粒子系统，而粒子系统的渲染和UI是独立的，仅能通过Render Order来改变两者的渲染顺序，而粒子系统的变化并不会引起UI部分的重建，因此特效的放置并没有特殊的要求。
Q：多人同屏的时候，人物移动会使得头顶上的名字Mesh重组，从而导致较为严重的卡顿，请问一下是否有优化的办法？
如果是用UGUI开发的，当头顶文字数量较多时，确实很容易引起性能问题，可以考虑从以下几点入手进行优化：
1.尽可能避免使用UI/Effect，特别是Outline，会使得文本的Mesh增加4倍，导致UI重建开销明显增大；
2.拆分Canvas，将屏幕中所有的头顶文字进行分组，放在不同的Canvas下，一方面可以降低更新的频率（如果分组中没有文字移动，该组就不会重建），另一方面可以减小重建时涉及到的Mesh大小（重建是以Canvas为单位进行的）；
3.降低移动中的文字的更新频率，可以考虑在文字移动的距离超过一个阈值时才真正进行位移，从而可以从概率上降低Canvas更新的频率。
三、界面切换
Q1：游戏中出现UI界面重叠，该怎么处理较好？比如当前有一个全屏显示的UI界面，点其中一个按钮会再起一个全屏界面，并把第一个UI界面盖住。我现在的做法是把被覆盖的界面SetActive(False)，但发现后续SetActive(True)的时候会有GC.Alloc产生。这种情况下，希望既降低Batches又降低GC Alloc的话，有什么推荐的方案吗？
可以尝试通过添加一个Layer如OutUI， 且在Camera的Culling Mask中将其取消勾选（即不渲染该Layer）。从而在UI界面切换时，直接通过修改Canvas的Layer来实现“隐藏”。但需要注意事件的屏蔽，禁用动态的UI元素等等。
这种做法的优点在于切换时基本没有开销，也不会产生多余的Draw Call，但缺点在于“隐藏时”依然还会有一定的持续开销（通常不太大），而其对应的Mesh也会始终存在于内存中（通常也不太大）。
以上的方式可供参考，而性能影响依旧是需要视具体情况而定。
Q2：通过移动位置来隐藏UI界面，会使得被隐藏的UIPanel继续执行更新（LateUpdate有持续开销），那么如果打开的界面比较多，CPU的持续开销是否就会超过一次SetActive所带来的开销？
这确实是需要注意的，通过移动的方式“隐藏”的UI界面只适用于几个切换频率最高的界面，另外，如果“隐藏”的界面持续开销较高，可以考虑只把一部分Disable，这个可能就需要具体看界面的复杂度了。一般来说在没有UI元素变化的情况下，持续的Update开销是不太明显的。
Q3：如图，我们在UI打开或者移动到某处的时候经常会观测到CPU上的冲激，经过进一步观察发现是因为Instantiate产生了大量的GC。想请问下Instantiate是否应该产生GC呢？我们能否通过资源制作上的调整来避免这样的GC呢？如下图，因为一次性产生若干MB的GC在直观感受上还是很可观的。
准确的说这些GC Alloc并不是由Instantiate直接引起的，而是因为被实例化出来的组件会进行OnEnable操作，而在OnEnable操作中产生了GC，比如以上图中的函数为例：
上图中的Text.OnEnable是在实例化一个UI界面时，UI中的文本（即Text组件）进行了OnEnable操作，其中主要是初始化文本网格的信息（每个文字所在的网格顶点，UV，顶点色等等属性），而这些信息都是储存在数组中（即堆内存中），所以文本越多，堆内存开销越大。但这是不可避免的，只能尽量减少出现次数。
因此，我们不建议通过Instantiate/Destroy来处理切换频繁的UI界面，而是通过SetActive(true/false)，甚至是直接移动UI的方式，以避免反复地造成堆内存开销。
四、加载相关
Q1：UGUI的图集操作中我们有这么一个问题，加载完一张图集后，使用这个方式获取其中一张图的信息：assetBundle.Load (subFile, typeof (Sprite)) as Sprite;这样会复制出一个新贴图（图集中的子图），不知道有什么办法可以不用复制新的子图，而是直接使用图集资源 。
经过测试，这确实是Unity在4.x版本中的一个缺陷，理论上这张“新贴图（图集中的子图）”是不需要的，并不应该加载。 因此，我们建议通过以下方法来绕过该问题：
在assetBundle.Load (subFile, typeof (Sprite)) as Sprite;之后，调用
Texture2D t = assetBundle.Load (subFile, typeof (Texture2D)) as Texture2D;
Resources.UnloadAsset(t);
从而卸载这部分多余的内存。
Q2：加载UI预制的时候，如果把特效放到预制里，会导致加载非常耗时。怎么优化这个加载时间呢？
UI和特效（粒子系统）的加载开销在多数项目中都占据较高的CPU耗时。UI界面的实例化和加载耗时主要由以下几个方面构成：
纹理资源加载耗时
UI界面加载的主要耗时开销，因为在其资源加载过程中，时常伴有大量较大分辨率的Atlas纹理加载，我们在之前的Unity加载模块深度分析之纹理篇有详细讲解。对此，我们建议研发团队在美术质量允许
1,1024*768 1024*1024
2, 640*480 512*512
作者：歪歪小花鹿
链接：http://www.jianshu.com/p/5b6f5022662e
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
