背景和目的
小哈接触Unity3D也有一段时间了&＃xff0c;项目组在UI解决方案的选型一直是用的原生的uGUI&＃xff0c;因此本人也是使用了一段时间的uGUI&＃xff0c;在uGUI的使用方面积累了一些自己的经验&＃xff0c;在此进行一个记录与总结。
本文接下来将会对uGUI的Runtime性能进行着重讨论&＃xff0c;其它的因素也很多而且很重要&＃xff0c;但是一篇文章讲清楚一件事就好了&＃xff0c;文后会提供uGUI的最佳实践与一些使用技巧&＃xff0c;不想看全文的建议直接到最下面看杰伦&＃xff0c;啊&＃xff0c;不对&＃xff0c;是结论。
影响uGUI性能的因素与检查工具
游戏中的UI与其它游戏中的元素本质上是一样的&＃xff0c;相对来说的不同点在于&＃xff0c;UI通常是由2D的图片组合而成&＃xff0c;会包含较多的透明元素与渐变元素&＃xff0c;而且一般来说会显示在屏幕的最顶层。
因此&＃xff0c;从共同点上说&＃xff0c;UI的Runtime性能消耗也可以划分为CPU消耗、GPU消耗与内存消耗。其中对于每一部分的具体的消耗以及优化&＃xff0c;有诸多大神在网络上发表过文章&＃xff0c;比如深入浅出聊Unity3D项目优化&＃xff1a;从Draw Calls到GC。但是&＃xff0c;总有一个大家都绕不开的点&＃xff0c;那就是Drawcall&＃xff0c;Drawcall数量直接影响了游戏的帧率&＃xff0c;解决了Drawcall问题&＃xff0c;应该算是解决了80%的问题&＃xff0c;所以接下来就着重针对uGUI的特性讲一讲UI系统的Drawcall。
Unity 5.0在Drawcall查看方面有一个非常有用的工具&＃xff0c;Frame Debugger&＃xff0c;通过[Window->Frame Debugger]打开。
Frame Debugger(Only in Unity5.0&＃43;)
使用该工具时&＃xff0c;游戏会暂停&＃xff0c;然后Unity会将当前正在执行的一帧的内容缓存下来&＃xff0c;其中所有Drawcall你都可以进行前进与后退操作&＃xff0c;从而能够从Drawcall级别分析开销。所以没有升级5.0的小伙伴赶紧升级啊。
此外&＃xff0c;在用FD看UI性能时&＃xff0c;有一个小窍门就是新开一个空的Scene&＃xff0c;然后将你的UI Prefab拖到该空场景中&＃xff0c;此时就不会受场景中其它物体的影响而只显示UI的Drawcall了。
uGUI性能优化
讲了那么多&＃xff0c;开始进入正题。
在降低Drawcall方面&＃xff0c;一个非常重要的概念就是Batch&＃xff0c;因为一次Drawcall相当于CPU与GPU进行一次沟通的成本&＃xff0c;如果CPU能一次多打包一些信息给GPU&＃xff0c;那么Drawcall数量自然就下来了&＃xff0c;这个打包传输信息给GPU的过程就叫做Batch&＃xff0c;批处理。那么什么情况下这些信息可以打包呢&＃xff1f;从uGUI的角度&＃xff0c;如果你的UI中组件的材质与纹理均相同&＃xff0c;这几个组件就可以被Batch。在Image组件中&＃xff0c;材质对应Source Image&＃xff0c;纹理则对应Material&＃xff1b;在Text组件中材质对应Font&＃xff0c;纹理也是Material。以上对应大部分情况适用&＃xff0c;在少部分特殊shader下会失效&＃xff08;待深入研究&＃xff09;。
Common UI Components
原理是这样&＃xff0c;但是实际用起来还需要一些技巧&＃xff0c;遵循Unity的一些渲染次序的规则&＃xff0c;才能真正的实现性能优化。以下就一一进行讨论。
打包图集
上面有提到Source Image图集&＃xff0c;所谓的图集&＃xff0c;就是将好多张零碎的2D小图片通过Unity自带的Sprite Packer或第三方的Texture Packer合并到一张大图&＃xff0c;这样做有几大好处&＃xff0c;
- 图片尺寸为2的次幂时&＃xff0c;GPU处理起来会快很多&＃xff0c;小图自己是做不到每张图都是2的次幂的&＃xff0c;但打成一张大图就可以&＃xff08;浪费一点也无所谓&＃xff09;&＃xff1b;
- CPU在传送资源信息给GPU时&＃xff0c;只需要传一张大图就可以了&＃xff0c;因为GPU可以在这张图中的不同区域进行采样&＃xff0c;然后拼出对应的界面。注意&＃xff0c;这就是为什么需要用同一个Source Image图集的原因&＃xff0c;是Batch的关键&＃xff0c;因为一个Drawcall就把所有原材料传过去了&＃xff0c;GPU你画去吧。
但是显然把所有图片打成一张图集是不合理的&＃xff0c;因为这张图可能非常大&＃xff0c;所以就要按照一定规则将图片进行分类。在分类思路上&＃xff0c;我们希望做到Drawcall尽可能少&＃xff0c;同时资源量也尽可能少&＃xff08;多些重用&＃xff09;&＃xff0c;但这两者某种程度上是互斥的&＃xff0c;所以折衷一下&＃xff0c;可以遵循以下思路&＃xff1a;
- 设计UI时要考虑重用性&＃xff0c;如一些边框、按钮等&＃xff0c;这些作为共享资源&＃xff0c;放在1~3张大图集中&＃xff0c;称为重用图集&＃xff1b;
- 其它非重用UI按照功能模块进行划分&＃xff0c;每个模块使用1~2张图集&＃xff0c;为功能图集&＃xff1b;
- 对于一些UI&＃xff0c;如果同时用到功能图集与重用图集&＃xff0c;但是其功能图集剩下的“空位”较多&＃xff0c;则可以考虑将用到的重用图集中的元素单独拎出来&＃xff0c;合入功能图集中&＃xff0c;从而做到让UI只依赖于功能图集。也就是通过一定的冗余&＃xff0c;来达到性能的提升。
P.S. 如果你用Unity自带的Sprite Packer去打包图集&＃xff0c;那么你可能要在运行模式下才能看到效果。
Unity GUI层级合并规则与批次生成规则
uGUI的层叠顺序是按照Hierarchy中的顺序从上往下进行的&＃xff0c;也就是越靠上的组件&＃xff0c;就会被画在越底部。所以UI就是这样一层一层地叠上去画出来的。当然这样一个一个地画效率肯定是不能接受的&＃xff0c;所以要合并&＃xff0c;要Batch&＃xff0c;Unity自身就提供了一个算法去决定哪些层应该合并到一起&＃xff0c;并以什么样的顺序进行绘制。所有相邻层的可Batch的UI元素将会在一个Drawcall完成。接下来就来讨论一下Unity的层级合并与计算算法。
Unity的UI渲染顺序的确定有2个步骤&＃xff0c;第一步计算每个UI元素的层级号&＃xff1b;第二步合并相同层级号中可以Batch的元素作为一个批次&＃xff0c;并对批次进行排序&＃xff1b;
先从直观的角度来解释计算层级号的算法&＃xff1a;如果有一个UI元素&＃xff0c;它所占的屏幕范围内&＃xff08;通常是矩形&＃xff09;&＃xff0c;如果没有任何UI在它的底下&＃xff0c;那么它的层级号就是0&＃xff08;最底下&＃xff09;&＃xff1b;如果有一个UI在其底下且该UI可以和它Batch&＃xff0c;那它的层级号与底下的UI层级一样&＃xff1b;如果有一个UI在其底下但是无法与它Batch&＃xff0c;那它的层级号为底下的UI的层级&＃43;1&＃xff1b;如果有多个UI都在其下面&＃xff0c;那么按前两种方式遍历计算所有的层级号&＃xff0c;其中最大的那个作为自己的层级号。
这里也给一下伪代码&＃xff0c;假设所有UI元素&＃xff08;抛弃层级关系&＃xff09;都按从上往下的顺序被装在一个list中&＃xff0c;那么每个UI元素对应的层级号计算可以参考以下&＃xff1a;
function CalLayer(List
UIEleLst)
if(
UIEleLst.Count &＃61;&＃61;
0 )
return;
//Initial the first UI Element as layer 0 UIEleLst[
0]
.layer &＃61;
0;
for(i &＃61;
1 ~
UIEleLst.Count){ var IsCollideWithElements &＃61; false;
//Compare with all elements beneath for(j &＃61; i-
1 ~
0){
//If Element-i collide with Element-j if(
UIEleLst[i]
.Rect.CollideWith(
UIEleLst[j]
.Rect)){ IsCollideWithElements &＃61; true;
//If Element-i can be batched with Element-j, same layer as Element-j if(
UIEleLst[i]
.QualifyToBatchWith(
UIEleLst[j])){
UIEleLst[i]
.layer &＃61;
UIEleLst[j]
.layer; }
else{
//Or else the layer is larger UIEleLst[i]
.layer &＃61;
UIEleLst[j]
.layer &＃43;
1; } } }
//If not collide with any elements beneath, set layer to 0 if(!IsCollideWithElements) {
UIEleLst[i]
.layer &＃61;
0; } }
有了层级号之后&＃xff0c;就要合并批次了&＃xff0c;此时&＃xff0c;Unity会将每一层的所有元素进行一个排序&＃xff08;按照材质、纹理等信息&＃xff09;&＃xff0c;合并掉可以Batch的元素成为一个批次&＃xff0c;目前已知的排序规则是&＃xff0c;Text组件会排在Image组件之前渲染&＃xff0c;而同一类组件的情况下排序规则未知&＃xff08;好像并没什么规则&＃xff09;。经过以上排序&＃xff0c;就可以得到一个有序的批次序列了。这时&＃xff0c;Unity会再做一个优化&＃xff0c;即如果相邻间的两个批次正好可以Batch的话就会进行Batch。举个栗子&＃xff0c;一个层级为0的ImageA&＃xff0c;一个层级为1的ImageB&＃xff08;2个Image可Batch&＃xff09;和一个层级为0的TextC&＃xff0c;Unity排序后的批次为TextC->ImageA->ImageB&＃xff0c;后两个批次可以合并&＃xff0c;所以是2个Drawcall。再举个栗子&＃xff0c;一个层级为0的TextD&＃xff0c;一个层级为1的TextE&＃xff08;2个Text可Batch&＃xff09;和一个层级为0的ImageF&＃xff0c;Unity排序后的批次为TextD->ImageF->TextE&＃xff0c;这时就需要3个Drawcall了&＃xff01;&＃xff08;是不是有点晕&＃xff0c;再回顾下黑体字&＃xff09;
以下的伪代码有些偷懒&＃xff0c;实在懒得写排序、合并之类的&＃xff0c;一长串也不好读&＃xff0c;几个步骤列一下&＃xff0c;其它诸位看上面那段文字脑补下吧...
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)&＃61;>{
return this.layer > uiElement.layer ||
this.BatchKey() > uiElement.BatchKey()} );
//Merge the UI Elements with same layer and batch-key as a batch var BatchLst &＃61; UIEleLst.MergeSameElementsAsBatch();
//Make adjacent batches with same batch-key merged BatchLst.MergeAdjacentBatches();
return BatchLst;}
根据以上规则&＃xff0c;就可以得出一些“摆UI”的技巧&＃xff1a;
- 有相同材质和纹理的UI元素是可以Batch的&＃xff0c;可以Batch的UI上下叠在一块不会影响性能&＃xff0c;但是如果不能Batch的UI元素叠在一块&＃xff0c;就会增加Drawcall开销。
- 要注意UI元素间的层叠关系&＃xff0c;建议用“T”工具查看其矩形大小&＃xff0c;因为有些图片透明&＃xff0c;但是却叠在其它UI上面了&＃xff0c;然后又无法Batch的话&＃xff0c;就会无故多许多Drawcall&＃xff1b;
- UI中出现最多的就是Image与Text组件&＃xff0c;当Text叠在Image上面&＃xff08;如Button)&＃xff0c;然后Text上又叠了一个图片时&＃xff0c;就会至少多2个Drawcall&＃xff0c;可以考虑将字体直接印在下面的图片上&＃xff1b;
- 有些情况可以考虑人为增加层级从而减少Drawcall&＃xff0c;比如一个Text的层级为0&＃xff0c;另一个可Batch的Text叠在一个图片A上&＃xff0c;层级为1&＃xff0c;那此时2个Text因为层级不同会安排2个Drawcall&＃xff0c;但如果在第一个Text下放一个透明的图片&＃xff08;与图片A可Batch&＃xff09;&＃xff0c;那两个Text的层级就一致了&＃xff0c;Drawcall就可以减少一个。
少用Mask
Mask对于uGUI性能来说是噩梦一般的存在&＃xff0c;因为很可能因为这个东西&＃xff0c;导致Drawcall数量成倍增长。
Mask实现的具体原理是一个Drawcall来创建Stencil mask(来做像素剔除)&＃xff0c;然后画所有子UI&＃xff0c;再在最后一个Drawcall移掉Stencil mask。这头尾两个Drawcall无法跟其他UI操作进行Batch&＃xff0c;所以表面上看加个Mask就会多2个Drawcall&＃xff0c;但是&＃xff0c;因为Mask这种类似“汉堡包式”的渲染顺序&＃xff0c;所有Mask的子节点与其他UI其实已经处在两个世界了&＃xff0c;上面提到的层级合并规则只能分别作用于这两个世界了&＃xff0c;所以很多原本可以合并的UI就无法合并了。
所以&＃xff0c;在使用uGUI时&＃xff0c;有一些建议&＃xff1a;
- 应该尽量避免使用Mask&＃xff0c;其实Mask的功能有些时候可以变通实现&＃xff0c;比如设计一个边框&＃xff0c;让这个边框叠在最上面&＃xff0c;底下的UI移动时&＃xff0c;就会被这个边框遮住&＃xff1b;
- 如果要使用Mask时&＃xff0c;需要评估下Mask会带来的性能损耗&＃xff0c;并尽量将其降到最低。比如Mask内的UI是动态生成的话&＃xff08;比如List组件&＃xff09;&＃xff0c;那么需要注意UI之间是否有重叠的现象。
总结
uGUI的性能其实涉及到的方面很多&＃xff0c;这里列出来的只是目前能想到的&＃xff0c;因为个人能力有限&＃xff0c;可能出些纰漏。对于文中的一些建议&＃xff0c;这里整理一下得出一些最佳实践&＃xff1a;
- 设计UI时要考虑重用性&＃xff0c;如一些边框、按钮等&＃xff0c;这些作为共享资源&＃xff0c;放在1~3张大图集中&＃xff0c;称为重用图集&＃xff1b;
- 其它非重用UI按照功能模块进行划分&＃xff0c;每个模块使用1~2张图集&＃xff0c;为功能图集&＃xff1b;
- 对于一些UI&＃xff0c;如果同时用到功能图集与重用图集&＃xff0c;但是其功能图集剩下的“空位”较多&＃xff0c;则可以考虑将用到的重用图集中的元素单独拎出来&＃xff0c;合入功能图集中&＃xff0c;从而做到让UI只依赖于功能图集。也就是通过一定的冗余&＃xff0c;来达到性能的提升。
- 有相同材质和纹理的UI元素是可以Batch的&＃xff0c;可以Batch的UI上下叠在一块不会影响性能&＃xff0c;但是如果不能Batch的UI元素叠在一块&＃xff0c;就会增加Drawcall开销。
- 要注意UI元素间的层叠关系&＃xff0c;建议用“T”工具查看其矩形大小&＃xff0c;因为有些图片透明&＃xff0c;但是却叠在其它UI上面了&＃xff0c;然后又无法Batch的话&＃xff0c;就会无故多许多Drawcall&＃xff1b;
- UI中出现最多的就是Image与Text组件&＃xff0c;当Text叠在Image上面&＃xff08;如Button)&＃xff0c;然后Text上又叠了一个图片时&＃xff0c;就会至少多2个Drawcall&＃xff0c;可以考虑将字体直接印在下面的图片上&＃xff1b;
- 有些情况可以考虑人为增加层级从而减少Drawcall&＃xff0c;比如一个Text的层级为0&＃xff0c;另一个可Batch的Text叠在一个图片A上&＃xff0c;层级为1&＃xff0c;那此时2个Text因为层级不同会安排2个Drawcall&＃xff0c;但如果在第一个Text下放一个透明的图片&＃xff08;与图片A可Batch&＃xff09;&＃xff0c;那两个Text的层级就一致了&＃xff0c;Drawcall就可以减少一个。
- 应该尽量避免使用Mask&＃xff0c;其实Mask的功能有些时候可以变通实现&＃xff0c;比如设计一个边框&＃xff0c;让这个边框叠在最上面&＃xff0c;底下的UI移动时&＃xff0c;就会被这个边框遮住&＃xff1b;
- 如果要使用Mask时&＃xff0c;需要评估下Mask会带来的性能损耗&＃xff0c;并尽量将其降到最低。比如Mask内的UI是动态生成的话&＃xff08;像List组件&＃xff09;&＃xff0c;那么需要注意生成的UI之间是否有重叠的现象&＃xff1b;
- 有空好好看下Unity GUI层级合并规则与批次生成规则这一节。
京公网安备 11010802041100号