如何读懂UWA性能报告?—NGUI篇

如何读懂UWA性能报告?—NGUI篇

前不久我们针对UWA报告中UGUI模块做过简介,不过鉴于依然有大量的开发商在用NGUI,UWA对其性能效率也提供了检测与分析。当然不同的UI实现机制,其对应的测评标准也各有不同,本期我们就来讲解如何查看NGUI相关的数据。

本系列为Unity开发者通读版,力求人人能读懂,建议阅读时间5分钟。
纸上得来终觉浅,绝知此事要躬行,www.uwa4d.com等你来体验。


抛砖引例

有别于之前家喻户晓的畅销大作,这次我们拿一个普通小清晰RPG游戏作为案例。在我们测试过的大量项目中,该游戏是少见的,以UI性能上位的。虽然这仅仅是第一次测试的数据,但是其在CPU耗时、堆内存分配上的表现都是甚如人意,瑕不掩瑜。
0.png

在UWA的报告中打开UI模块性能界面,大家就能看到如上图UI相关的详细参数。包括:CPU峰值、CPU均值、堆内存分配总值、堆内存分配均值。这里的CPU峰值取自以下4个UI函数的耗时总和。堆内存分配总值指测试过程中,这4个UI性能函数分配的堆内存之和。

UICamera.Update()
该函数通常在点击时出现开销。因此,当该函数的CPU开销较高时,通常都是因为调用了其他的较为耗时的函数引起。

UIRect.Update()
该函数通常在需要更新锚点位置时出现开销。因此,当该函数的CPU开销持续较高时,通常是因为当前场景中有较多的UI元素绑定了OnUpdate模式的锚点。

UIPanel.LateUpdate()
该函数为NGUI最主要的CPU开销,包含了对所有UI界面包括其下UI元素的状态更新、网格重建、DrawCall合并等操作。大量的UI变动或者不合理的UIPanel布局都有可能导致该函数出现较高的峰值。

UIRect.Start()
该函数主要涉及到UI元素的初始化操作,通常在UI界面被实例化时出现并产生一定的CPU开销。

报告往下看,是各个函数的具体CPU和堆内存开销。如果你对这些数据代表的数字是一脸懵逼的状态,不清楚是偏高了还是偏低了,请先打开右边的分析与建议。
如下图,红框内分别给出了四个函数的CPU占用详情,包括主体范围是多少,过高或过低。一般来说,我们建议堆内存总值控制在30MB内,如果可以,尽量再往20MB的极限靠靠。
请输入图片描述

在此,我们不妨点击某一帧,在底部查看该帧的CPU耗时。

请输入图片描述
上图中显示,在第5500帧时CPU的耗时为5.4ms,若要溯本求源,我们可以再去CPU耗时详情中定位是哪个函数引起的CPU开销。

请输入图片描述

如上图,我们看到这些耗时分别为:
UICamera.Update(): 1.2 ms
UIRect.Update(): 0.2 ms
UIPanel.LateUpdate(): 4.0 ms
UIRect.Start(): 0.0 ms (由于四舍五入)

通过这些具体的性能函数,以及这些函数的意义我们就可以大致做一个判断了。接下来就需要各位程序大大结合自己的UI设计具体问题具体分析了。由于此文的目的是为了帮助大家理解UWA性能优化报告,因而并不会大篇幅讲解NGUI性能优化的细则,下文先给一些比较通用的建议,可谓优化中的黄金法则!


优化支招

1、 尽可能将静态UI元素和频繁变化的动态UI元素分开,存放于不同的Panel下。同时,对于不同频率的动态元素也建议存放于不同的Panel中。

2、对于UI元素,OnEnable和OnDisable都会进行较多的操作,因此即使不涉及到资源的加载,依然会有较大的CPU开销,因此,对于切换非常频繁的UI界面,我们建议更高效的做法是:
(1)改变UI的位置(以UIPanel为单位)来实现UI的隐藏和显示,因为是位置移动,所以并不产生多余的CPU消耗,同时又可以节省Enable和Disable的CPU开销。
(2) 通过设置相机的Culling mask 来实现 UI 界面的隐藏和显示,同样避免Enable/Disable操作。该做法可能会一定程度地提高内存的开销(UIDrawCall中存储的Mesh),因此可以根据UI切换的频率来决定是否要进行优化。

3、UI资源进行详细检测,查看其分辨率、格式等是否足够精简和优化。

今天的分享就到这里,下一期我们会继续讲解UWA测评报告中的内存模块,感谢各位开发者的关注。

  • 吴盛滨 发表在 2016年09月02日 回复

    原来的项目一直用NGUI,新项目开坑想尝试下UGUI,想知道在性能方面,UGUI和NGUI哪一个比较好?

    • admin 发表在 2016年09月02日 回复

      ugui更好