Unity性能优化系列—加载与资源管理

Unity性能优化系列—加载与资源管理

我们曾在四年前对于Unity的主流模块的性能优化知识点逐一做过讲解,俗称“小白版”。随着这几年引擎本身、硬件设备、制作标准等等的升级,UWA也不断更新优化规则和方法并持续输出给广大开发者。作为"升级版"的性能优化手册,【Unity性能优化系列】将力图以浅显易懂的表达,让更多开发者受用。本期就将分享加载与资源管理相关的知识点。

经常会有一些团队询问:为什么我的游戏加载这么缓慢呢,能否做到像***游戏一样秒切场景呢?游戏发烫又是什么原因呢?为了防止大家辛苦做出来的游戏在真机上卡成翔或者秒变暖手宝,我们要充分利用好UWA报告中的加载模块和资源管理模块,下文我们将来逐步分析。

一、加载模块中的关注项

这里我们先来科普一些加载相关的关注指标。下图是Overview报告中的加载模块的页签,我们看到左边有这么几项重要参数指标:

1、Loading.UpdatePreloading
这是Unity引擎最主要的加载函数。该项一般在切换场景时或异步加载资源时开销较大。一般来说,加载资源越多越复杂,则其Load.UpdatePreloading的耗时也越大。

该函数优化前,建议先定位其耗时占用瓶颈。通过报告的CPU调用堆栈即可查看该函数在运行过程中的详细堆栈走势,对函数的耗时分配一目了然,从而有的放矢的进行优化。

2、Resources.UnloadUnusedAssets
该函数指卸载未使用的资源,开销主要取决于场景中的Assets和Object的数量,数量越多,则耗时越高。在性能优化时,除了耗时峰值之外,我们还需关注该函数的调用次数。

一般情况下,场景切换过程中, 引擎会自动调用一次,UWA建议在10~15分钟的时候手动调用一次。

同时,研发团队可尝试在游戏运行时,通过Resources.UnloadAsset来去除已经确定不再使用的某一资源,该API对于去除单一资源的效率很高,同时也可以降低Resources.UnloadUnusedAssets统一处理时的压力。

下图为报告中加载相关函数的堆栈信息,在堆栈中GarbageCollectAssetsProfile是由于调用了Resources.UnloadAssetsUnused导致的,如果此项占用过高,则需要关注是否主动调用Resrouces.UnloadUnusedAssets过于频繁。

3、GC.Collect
GC调用频率主要受堆内存影响,当函数的堆内存分配量越多、越频繁,GC就会越快到来。所以当我们的GC.Collect函数的调用频率较为频繁(如下图所示),特别是随着游戏运行时间增加,越来越频繁时,就需要我们留意是否存在高分配、频繁分配堆内存的函数操作了,这部分就可以借助GOT Online的Mono模式排查是否有Mono分配过快或过高的现象。

4、Instantiate

这里统计的是资源实例化的耗时,当项目的资源越复杂、实例化数量越多,卡顿感就越明显,但这部分往往是被大家容易忽略的,那UWA是如何处理好这部分的问题呢?下文我们将结合UWA真人真机测试报告中【资源管理】模块来进行具体讲解。


二、资源管理

这里的资源管理讲的是资源的调用频率、耗时等策略,因为影响加载体验的无非两个角度:加载的频率和每加载一次的耗时。在真人真机测试的报告中,我们可以看到【资源管理】标签后,包含以下检测项:

这么多功能,我们要关注哪些细节呢?说下几个核心点:

1、关注耗时较高的加载
无论是AssetBundle还是资源加载,耗时较高的都需要重点关注。这里我们打开一个资源加载的页签,可以看到下方是整个运行过程中的资源调用详情,最后一栏是耗时。

在资源具体信息中,勾选某个资源,就可以看到它在运行过程中的调用细节。对应上面的截图,我们可以进一步排查下这个AssetBundle加载是否需要那么多耗时。

2、短期时间内调用次数密集的重点关注
无论是AssetBundle还是资源加载,都要关注加载的频率。通常对于频繁加载的对象,我们可以通过建立缓存池的方法,先加载一次后将其加入缓存,后续就无须进行加载了。

如下图中,这些频繁加载的AssetBundle,可能原来有每次5ms或者50ms的耗时,后面可直接为0

这里再提下,我们也需要留意一帧内相同资源被多次加载的问题。
如下图,这一帧里调用5次,这个是不对的。

3、留意不存在资源

在资源加载的列表中,有的项目会出现【不存在】资源的情况,说明这些资源都是由于不在指定路径下导致加载失败的资源。一般情况下,这类资源是伴随着版本迭代,进行删除/迁移后,没有修改/注释对应的代码导致的。

加载这些【不存在】资源仅导致了一小部分CPU开销,但更重要是,排查这些【不存在】可以避免逻辑上的问题导致闪退和卡死等现象。

4、频繁实例化/Destroy
操作次数较高或耗时较高的资源。频繁的Instantiate会造成一定的堆内存分配,从而会加快系统调用GC的频率。更重要的是,频繁的实例化会造成CPU耗时产生一定的峰值,导致游戏的流畅性受到影响,所以这部分也是我们需要关注的。

对于这种频繁实例化的资源,通过缓存池复用实例化次数过多的GameObject,进而减少GameObject实例化的耗时。

5、Activate和Deactivate
这个排查方式与实例化是类似的,主要关注调用频率和耗时。

对比Activate和Deactivate的调用次数,因为如两者相差过大,说明存在无用的Activate/Deactivate操作。

例如,某个资源的Activate操作次数非常多(如下图中的Gold_2和Gold_4),为什么次数那么高?是否有必要呢?我们可复制该资源名称,在Deactivate资源列表中进行搜索查看是否确实需要这么多次状态的激活。

Gold_2的Deactivate

Gold_4的Deactivate

这说明相差的1万多次的Deactivate操作都是无意义的。

对于以上这种资源,我们可以通过在C#端创建一个特例缓存,记录这个对象的Active的状态(True or False),在调用SetActive之前,先判断一下当前的状态是否已经是想要切换到的状态,如果不是才调用。这是因为SetActive的操作是会从C#走到C++层的,所以我们在C#进行状态判断可以减少这种跨语言的操作,从而避免不必要的耗时。

6、AssetBunde驻留优化
之所以关注这个参数,是因为它影响了项目运行过程中的内存占用,要知道Unity内存一部分是由AssetBundle驻留导致的Serializedfile相关的,一般来说我们建议控制的AssetBundle资源数量在1000以下。考虑到这个指标和项目本身的复杂度有关,所以大家需要自身做些实验,好权衡CPU和内存之间的天平。

资源的加载可以使用缓存池的方式来进行优化,AssetBundle的加载也是类似的。对于同一个AssetBundle进行频繁的加载通常是不合理的(如下图所示),对于频繁加载卸载的AssetBundle,建议将其加入缓存,常驻于内存中。


三、Shader.Parse/CreateGPUProgram

Shader资源如果解析加载策略不当,也会造成CPU开销较大。由于Shader的内存占用很小,但是加载的耗时又比较高,所以我们建议在理想情况下是在项目开始运行时就把所有的Shader资源全部加载完成,然后缓存。

1、Shader.Parse

该函数的耗时主要是由于Shader的加载和解析,通常是由于Shader的重复加载导致的,在优化时要看一下具体的Shader加载情况,具体可以从以下三点着手:

(1)避免使用Standard,使用其他Shader代替Standard Shader。注意排查是否因为模型导入而导致Standard Shader被加载进入AssetBundle中;

(2)解决Shader冗余问题,这部分可以结合Shader的内存走势查看,如下图所示。

如果大家的Shader资源并不是缓存在内存中的,切出场景时则会释放Shader,切入场景会加载Shader,导致了大量的重复开销。解决这个问题,只需要把Shader进行剥离,通过依赖关系将其做成单独的AB,然后加载后就缓存住不卸载,那么后续就不需要再对此Shader进行加载了。

(3)减少Shader的Keyword。
研发团队可以参考下面的资料:
《一种Shader变体收集和打包编译优化的思路》
https://answer.uwa4d.com/question/5da86670e84db43d6efbda72

2、Shader.CreateGPUProgram

该API的CPU占用是Shader第一次渲染时创建GPU程序的耗时,其耗时与渲染Shader的复杂程度相关。对此,建议研发团队将Shader通过ShaderVariantCollection进行加载,并在加载后并Warmup,从而避免Shader在游戏运行时产生Shader.CreateGPUProgram的耗时。

以上就是加载在优化时需要关注的一些问题,如何操作还需要大家结合项目实际情况,同时结合UWA的线上测评服务可以快速地帮助大家定位到性能瓶颈。