你应该知道的AssetBundle管理机制
- 作者:admin
- /
- 时间:2016年02月23日
- /
- 浏览:63690 次
- /
- 分类:厚积薄发
接上期AssetBundle打包的讲解,我们今天为大家继续探秘AssetBundle,从管理机制的角度出发,谈谈其资源加载和卸载的原理。
AssetBundle加载基础
通过AssetBundle加载资源,分为两步,第一步是获取AssetBundle对象,第二步是通过该对象加载需要的资源。而第一步又分为两种方式,下文中将结合常用的API进行详细地描述。
一、获取AssetBundle对象的常用API
(1)先获取WWW对象,再通过WWW.assetBundle获取AssetBundle对象:
- public WWW(string url);
加载Bundle文件并获取WWW对象,完成后会在内存中创建较大的WebStream(解压后的内容,通常为原Bundle文件的4~5倍大小,纹理资源比例可能更大),因此后续的AssetBundle.Load可以直接在内存中进行。
- public static WWW LoadFromCacheOrDownload(string url, int version, uint crc = 0);
加载Bundle文件并获取WWW对象,同时将解压形式的Bundle内容存入磁盘中作为缓存(如果该Bundle已在缓存中,则省去这一步),完成后只会在内存中创建较小的SerializedFile,而后续的AssetBundle.Load需要通过IO从磁盘中的缓存获取。- public AssetBundle assetBundle;
通过之前两个接口获取WWW对象后,即可通过WWW.assetBundle获取AssetBundle对象。
(2) 直接获取AssetBundle:
- public static AssetBundle CreateFromFile(string path);
通过未压缩的Bundle文件,同步创建AssetBundle对象,这是最快的创建方式。创建完成后只会在内存中创建较小的SerializedFile,而后续的AssetBundle.Load需要通过IO从磁盘中获取。- public static AssetBundleCreateRequest CreateFromMemory(byte[] binary);
通过Bundle的二进制数据,异步创建AssetBundle对象。完成后会在内存中创建较大的WebStream。调用时,Bundle的解压是异步进行的,因此对于未压缩的Bundle文件,该接口与CreateFromMemoryImmediate等价。- public static AssetBundle CreateFromMemoryImmediate(byte[] binary);
该接口是CreateFromMemory的同步版本。
- 注:5.3下分别改名为LoadFromFile,LoadFromMemory,LoadFromMemoryAsync并增加了LoadFromFileAsync,且机制也有一定的变化,可详见Unity官方文档。
二、从AssetBundle加载资源的常用API
- public Object Load(string name, Type type);
通过给定的名字和资源类型,加载资源。加载时会自动加载其依赖的资源,即Load一个Prefab时,会自动Load其引用的Texture资源。- public Object[] LoadAll(Type type);
一次性加载Bundle中给定资源类型的所有资源。- public AssetBundleRequest LoadAsync(string name, Type type);
该接口是Load的异步版本。
- 注:5.x下分别改名为LoadAsset,LoadAllAssets,LoadAssetAsync,并增加了LoadAllAssetsAsync。
AssetBundle加载进阶
一、接口对比:new WWW与WWW.LoadFromCacheOrDownload
(1)前者的优势
- 后续的Load操作在内存中进行,相比后者的IO操作开销更小;
- 不形成缓存文件,而后者则需要额外的磁盘空间存放缓存;
- 能通过WWW.texture,WWW.bytes,WWW.audioClip等接口直接加载外部资源,而后者只能用于加载AssetBundle
(2)前者的劣势
- 每次加载都涉及到解压操作,而后者在第二次加载时就省去了解压的开销;
- 在内存中会有较大的WebStream,而后者在内存中只有通常较小的SerializedFile。(此项为一般情况,但并不绝对,对于序列化信息较多的Prefab,很可能出现SerializedFile比WebStream更大的情况)
二、内存分析
在管理AssetBundle时,了解其加载过程中对内存的影响意义重大。在上图中,我们在中间列出了AssetBundle加载资源后,内存中各类物件的分布图,在左侧则列出了每一类内存的产生所涉及到的加载API:
- WWW对象:在第一步的方式1中产生,内存开销小;
- WebStream:在使用new WWW或CreateFromMemory时产生,内存开销通常较大;
- SerializedFile:在第一步中两种方式都会产生,内存开销通常较小;
- AssetBundle对象:在第一步中两种方式都会产生,内存开销小;
- 资源(包括Prefab):在第二步中通过Load产生,根据资源类型,内存开销各有大小;
- 场景物件(GameObject):在第二步中通过Instantiate产生,内存开销通常较小。
在后续的章节中,我们还将针对该图中各类内存物件分析其卸载的方式,从而避免内存残留甚至泄露。
三、注意点
- CreateFromFile只能适用于未压缩的AssetBundle,而Android系统下StreamingAssets是在压缩目录(.jar)中,因此需要先将未压缩的AssetBundle放到SD卡中才能对其使用CreateFromFile。
Application.streamingAsstsPath = "jar:file://" + Application.dataPath+"!/assets/";- iOS系统有256个开启文件的上限,因此,内存中通过CreateFromFile或WWW.LoadFromCacheOrDownload加载的AssetBundle对象也会低于该值,在较新的版本中,如果LoadFromCacheOrDownload超过上限,则会自动改为new WWW的形式加载,而较早的版本中则会加载失败。
- CreateFromFile和WWW.LoadFromCacheOrDownload的调用会增加RersistentManager.Remapper的大小,而PersistentManager负责维护资源的持久化存储,Remapper保存的是加载到内存的资源HeapID与源数据FileID的映射关系,它是一个Memory Pool,其行为类似Mono堆内存,只增不减,因此需要对这两个接口的使用做合理的规划。
- 对于存在依赖关系的Bundle包,在加载时主要注意顺序。举例来说,假设CanvasA在BundleA中,所依赖的AtlasB在BundleB中,为了确保资源正确引用,那么最晚创建BundleB的AssetBundle对象的时间点是在实例化CanvasA之前。即,创建BundleA的AssetBundle对象时、Load(“CanvasA”)时,BundleB的AssetBundle对象都可以不在内存中。
- 根据经验,建议AssetBundle文件的大小不超过1MB,因为在普遍情况下Bundle的加载时间与其大小并非呈线性关系,过大的Bundle可能引起较大的加载开销。
- 由于WWW对象的加载是异步的,因此逐个加载容易出现下图中CPU空闲的情况(选中帧处Vsync占了大部分),此时建议适当地同时加载多个对象,以增加CPU的使用率,同时加快加载的完成。
AssetBundle卸载
前文提到了通过AssetBundle加载资源时的内存分配情况,下面,我们结合常用的API来介绍如何将已分配的内存进行卸载,最终达到清空所有相关内存的目的。
一、内存分析
在上图中的右侧,我们列出了各种内存物件的卸载方式:
- 场景物件(GameObject):这类物件可通过Destroy函数进行卸载;
- 资源(包括Prefab):除了Prefab以外,资源文件可以通过三种方式来卸载:
1) 通过Resources.UnloadAsset卸载指定的资源,CPU开销小;
2)通过Resources.UnloadUnusedAssets一次性卸载所有未被引用的资源,CPU开销大;
3)通过AssetBundle.Unload(true)在卸载AssetBundle对象时,将加载出来的资源一起卸载。
而对于Prefab,目前仅能通过DestroyImmediate来卸载,且卸载后,必须重新加载AssetBundle才能重新加载该Prefab。由于内存开销较小,通常不建议进行针对性地卸载。- WWW对象:调用对象的Dispose函数或将其置为null即可;
- WebStream:在卸载WWW对象以及对应的AssetBundle对象后,这部分内存即会被引擎自动卸载;
- SerializedFile:卸载AssetBundle后,这部分内存会被引擎自动卸载;
- AssetBundle对象:AssetBundle的卸载有两种方式:
1)通过AssetBundle.Unload(false),卸载AssetBundle对象时保留内存中已加载的资源;
2)通过AssetBundle.Unload(true),卸载AssetBundle对象时卸载内存中已加载的资源,由于该方法容易引起资源引用丢失,因此并不建议经常使用;
二、注意点
在通过AssetBundle.Unload(false)卸载AssetBundle对象后,如果重新创建该对象并加载之前加载过的资源到内存时,会出现冗余,即两份相同的资源。
被脚本的静态变量引用的资源,在调用Resources.UnloadUnusedAssets时,并不会被卸载,在Profiler中能够看到其引用情况。
UWA推荐方案
通过以上的讲解,相信您对AssetBundle的加载和卸载已经有了明确的了解。下面,我们将简单地做一下API选择上的推荐:
- 对于需要常驻内存的Bundle文件来说,优先考虑减小内存占用,因此对于存放非Prefab资源(特别是纹理)的Bundle文件,可以考虑使用WWW.LoadFromCacheOrDownload或AssetBundle.CreateFromFile加载,从而避免WebStream常驻内存;而对于存放较多Prefab资源的Bundle,则考虑使用new WWW加载,因为这类Bundle用WWW.LoadFromCacheOrDownload加载时产生的SerializedFile可能会比new WWW产生的WebStream更大。
- 对于加载完后即卸载的Bundle文件,则分两种情况:优先考虑速度(加载场景时)和优先考虑流畅度(游戏进行时)。
1)加载场景的情况下,需要注意的是避免WWW对象的逐个加载导致的CPU空闲,可以考虑使用加载速度较快的WWW.LoadFromCacheOrDownload或AssetBundle.CreateFromFile,但需要避免后续大量地进行Load资源的操作,引起IO开销(可以尝试直接LoadAll)。
2) 游戏进行的情况下,则需要避免使用同步操作引起卡顿,因此可以考虑使用new WWW配合AssetBundle.LoadAsync来进行平滑的资源加载,但需要注意的是,对于Shader、较大的Texture等资源,其初始化操作通常很耗时,容易引起卡顿,因此建议将这类资源在加载场景时进行预加载。- 只在Bundle需要加密的情况下,考虑使用CreateFromMemory,因为该接口加载速度较慢。
- 尽量避免在游戏进行中调用Resources.UnloadUnusedAssets(),因为该接口开销较大,容易引起卡顿,可尝试使用Resources.Unload(obj)来逐个进行卸载,以保证游戏的流畅度。
需要说明的是,以上内存管理较适合于Unity 5.3之前的版本。Unity引擎在5.3中对AssetBundle的内存占用进行一定的调整,目前我们也在进一步的学习和研究中。
以上即为我们这次为您带来的AssetBundle管理机制,希望对您的项目研发有所帮助。我们会在后续技术文章通过大量的案例来进一步解释AssetBundle的管理机制,敬请关注。
[...]这是很可能出现的。unload(false)卸载AssetBundle并不会销毁其加载的资源 ,是必须对其调用Resources.UnloadAsset,或者调用Resources.UnloadUnusedAssets才行。关于AssetBundle加载的详细解释可以参考我们之前的文章:你应该知道的AssetBundle管理机制。[...]
[...]这是很可能出现的。unload(false)卸载AssetBundle并不会销毁其加载的资源 ,是必须对其调用Resources.UnloadAsset,或者调用Resources.UnloadUnusedAssets才行。关于AssetBundle加载的详细解释可以参考我们之前的文章:你应该知道的AssetBundle管理机制。[...]
写的真心不错,不过2017之后有些变化,导致不太适用了,如果能在此基础上加上管理,例如bundle引用计数和池子的概念就更好了
5.3之后这些有变化吗
如果能做一些demo在git上就更棒了
1
可以评论了
1