细谈unity资源加载和卸载

转载请标明出处:http://www.cnblogs.com/zblade/

一、概要

在了解unity的资源管理方式之后,接下来细谈一下Unity的资源是如何从磁盘中加载到运行时的内存中,以及又是如何被卸载的。这部分较为繁琐,可能会写较多的过程。

二、脚本资源的加载和卸载

在unity中的脚本资源,大体可以分为C++编译的引擎dll文件,c#编译的dll文件,lua脚本文件(基于lua热更的方式下)。

2.1 dll文件的加载和卸载

在工程的Library/ScriptAssemblies文件夹下,会有当前工程非引擎相关的dll文件列表:

细谈unity资源加载和卸载

在游戏启动的时候,会执行Assembly.Load的操作,将这些dll文件加载进进程中(editor类相关的dll不会被加载)。

能够加载,自然也能在运行时被卸载,所以目前一种热更新方案ILRuntime就是对dll文件进行加载,热更新,卸载,加载最新的dll这样的方式进行操作。这种热更新方式主要是针对Assembly-CSharp.dll/Assembly-CSharp-firstpass.dll进行操作。
如果不是主动进行卸载,那么这些被加载的dll文件,在游戏进程中,是不会被卸载释放的,只有在游戏进程结束的时候,才会被系统从内存中卸载出去。

2.2 lua文件的加载和卸载

lua由于脚本文件的属性,可以被当做类文本文件进行热更新,同时在游戏启动的时候才开启一个Lua虚拟机,在Lua虚拟机中才执行lua文件的require相关操作。
这类文件的加载,其实质就是将这部分代码读入到lua虚拟机的全局缓存中,而所谓的卸载,就是将这部分缓存置为nil,和上面的dll文件的加载和卸载含义有一些差异。

三、非脚本资源的加载和卸载

非脚本资源,才是整个游戏进程中需要处理的主要部分,会伴随整个游戏进程,直到游戏进程结束。
个人对unity对资源的加载过程的理解,其本质就是一个反序列化的过程。

3.1 Serialization and Instance

unity在序列化的时候,对于每个组件,也是单独逐个的执行序列化的操作的,其序列化信息的关键信息是文件本身的fileID, 以及依赖文件的fileID 和guid.
对应的,在unity的Instance操作中,unity会为该GameObject创建一个唯一的InstanceID, 在进程内部会缓存这样一个InstanceID <-> gameobject的映射关系表,同时 fileID/GUID/LocalID 会对应的映射到该文件的源文件存储位置。这个InstanceID具有唯一性,当InstanceID创建完成后,如果object没有被load,则会触发unity执行一次资源的load,基于fileID/Guid/local id来执行object的加载。
实际的游戏运行中,并不会直接依赖fileID/GUID来执行文件的映射,而是会将这两个ID转换成一个新的ID,所以在实际运行的游戏中是看不到fileID/GUID相关文件的。

3.2 InstanceID的创建和失效

在游戏启动的时候,会将启动场景以及Resources目录下的资源逐个创建对应的InstanceID, 放入到缓存中,这部分InstanceID的创建耗时会随着Resources目录包含资源的增多而增大,所以尽量减小这部分资源的数目。
在游戏启动完成后,后续按需加载的Object,都会对应的创建InstanceID, 在卸载该资源的时候,会对应使这个映射关系失效,后续重新加载该object的时候,是会被重新创建对应的InstanceID, 先前创建的InstanceID是不会被重新定位到新加载的Object的。

3.3 AssetBundle中文件的加载

现在在Unity中主要的资源管理是基于AssetBundle的管理,那么运行时,是如何从bundle中加载出想要的Object的?

3.3.1 Bundle文件的组成

在Unity中,bundle会被分为两种大类,场景Bundle和非场景Bundle,利用unity自带的WebExtract 和 Binary2Text两个工具,是可以解压bundle为文本文件的。
场景Bundle在使用WebExtract解压后,会得到两类文件:

  • BuildPlayer-sceneName: 场景序列化文件,也就是hierarchy序列化的结果
  • BuildPlayer-sceneName.sharedasset: 场景依赖的文件

普通bundle在使用WebExtract解压后,会得到两类文件:

  • CAB-GuidString: 该二进制文件为该bundle的序列化文件,以及可能包含的具体Object文件
  • CAB-GuidString.resS:如果包含这个文件,则上面的文件目前是不能转换成txt文件的

以转换成功的bundle的序列化文件为参照,可以分析主要包含以下几个部分:

1) External References:

细谈unity资源加载和卸载

可以理解为依赖的外部assetbundle,这儿并不是依赖的bundle的名字,而是类似的cab-guidstring的形式,可见unity内部对于bundle的相互依赖处理,是基于这样一套的命名来进行管理的。

2) object map:

当前bundle包含的object的信息map:

细谈unity资源加载和卸载

3) bundle头文件: AssetBundle

细谈unity资源加载和卸载

4) bundle包含的object的详细序列化信息

3.3.2 Bundle文件的加载过程

分析完bundle的组成后,接下来分析从bundle中加载Object的过程,这儿以LZ4的压缩为标准,基于AssetBundle.LoadFromFile(Async)做为接口。 在加载Object的时候,会首先触发加载该object所在的bundle,如果该bundle有依赖bundle,那么需要先加载该bundle的依赖bundle,Unity并不会自动加载依赖bundle.

unity在加载bundle的时候,会先加载该bundle的序列化文件,也就是前面说到的External References/Object map/bundle头文件,然后基于得到序列化信息,进一步从bundle的object序列化信息中加载对应的object。

如果该object有多个依赖的资源,unity会在内部自动从该bundle或者依赖bundle中将依赖资源加载出来,然后执行资源的装载,最终返回一份实例到内存中,完成InstanceID 和 gameobject的映射。

3.3.3 Bundle文件中对script的加载

如果bundle中的object上有对应的script,那么在构建Bundle的时候,会为这个script构建一份特殊的资源:MonoScript,对应的存入到bundle中,monoscript这种资源,并没有包含实际的运行时的代码,而是存储这个脚本的assembly name, namespace name and class name,在装配该Object的时候,由于dll已经提前装载,所以会自动的索引到装载的assembly/namespace/class name脚本,然后装配到该object上。

3.4 资源的卸载

在不考虑资源计数管理的情况下,当资源的引用为空的时候,是可以执行资源的卸载的。对于资源的卸载,分为Resources资源和bundle资源:

3.4.1 Resources资源

1)可以调用Resources.UnloadAsset接口来卸载资源,使用该接口后,下次再加载该Object,会重新建立旧InstanceID和该Object的映射关系

2) 在执行场景切换的时候,如果选择 non-additively mode,这时候会自动的触发Resources.UnloadUnusedAsset

3.4.2 Bundle资源

bundle的卸载,有AssetBundle.Unload(true)/Unload(false)两种:

1)Unload(true): 将bundle从内存中卸载,同时将从bundle中加载的所有资源都卸载掉

2) Unload(false): 将bundle从内存中卸载,从bundle中已经加载的资源会被保留,如果再重新加载该bundle,对应的不会重新构建bundle和资源的映射关系,以前加载的资源就容易造成内存泄露。

目前推荐自己计数管理,只调用Unload(true)

四、Resources的使用

Unity的官方文档:

4.1. Best Practices for the Resources System

Don't use it. several reasons:

1) 使用resources使得精细化细粒度的内存管理更困难

2) 不恰当的使用Resources目录会增大游戏的启动时间以及build时间
而且随着Resources目录中文件的增加,对其中资源的管理会越来越困难

3) Resources目录无法根据平台定制资源内容(除非在build的时候重新拷贝指定的资源到Resource目录)

4) Resources目录无法提供热更新

4.2. Proper uses of the Resources system

在某些情况下,Resources目录还是可以使用:

1) rapidly prototype开发阶段

2) generally required throughout a project's lifetime

3) Not memory-intensive

4) Not prone to patching, or does not vary across platforms or devices

5) Used for minimal bootstrapping 某些和平台无关的配置文件,不占用较大内存,可以放入到Resources目录中

4.3. Serialization of Resources

在build的时候,Resources目录下的Assets/Objects会被序列化到一个序列化文件中。在这个文件中,包含了元数据以及索引信息,类似于AssetBundle。

索引信息其实就是一个序列化的查找树,用来定位资源名字到资源的file guid和local ID, 同时用于查找这个资源本身。

在大部分的平台上,查找树是BST, 其构建的时间复杂度为O(nlog(n)), 构建的时间会随着n的增大而增大(资源数越多构建时间越久)

在游戏启动的时候,这个BST树构建的过程是无法跳过的,如果Resources下的资源数目超过10,000,在低端手机上其占用的启动时间会达到几秒。而事实上这些资源索引并不是全部需要预先加载的,这会降低游戏的性能。

五、总结

简要的阐述了整个资源加载和卸载的流程,对于AssetBundle的使用和管理,属于新的分类内容,在后续再细谈。

上一篇:shell MAC 地址 校验


下一篇:Spring Boot从入门到精通(九)整合Spring Data JPA应用框架