本文目录
转载请标明出处:http://www.cnblogs.com/zblade/
一、概要
在了解unity的资源管理方式之后,接下来细谈一下Unity的资源是如何从磁盘中加载到运行时的内存中,以及又是如何被卸载的。这部分较为繁琐,可能会写较多的过程。
二、脚本资源的加载和卸载
在unity中的脚本资源,大体可以分为C++编译的引擎dll文件,c#编译的dll文件,lua脚本文件(基于lua热更的方式下)。
2.1 dll文件的加载和卸载
在工程的Library/ScriptAssemblies文件夹下,会有当前工程非引擎相关的dll文件列表:
在游戏启动的时候,会执行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:
可以理解为依赖的外部assetbundle,这儿并不是依赖的bundle的名字,而是类似的cab-guidstring的形式,可见unity内部对于bundle的相互依赖处理,是基于这样一套的命名来进行管理的。
2) object map:
当前bundle包含的object的信息map:
3) bundle头文件: AssetBundle
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的使用和管理,属于新的分类内容,在后续再细谈。