一 AssetBundle加载基础
通过AssetBundle加载资源，分为两步，第一步是获取AssetBundle对象，第二步是通过该对象加载需要的资源。而第一步又分为两种方式，下文中将结合常用的API进行详细地描述。
第一步，获取AssetBundle对象的常用API
加载方式一，先获取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对象。
加载方式二，直接获取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。
前者的优势
● 后续的Load操作在内存中进行，相比后者的IO操作开销更小；
● 不形成缓存文件，而后者则需要额外的磁盘空间存放缓存；
● 能通过WWW.texture，WWW.bytes，WWW.audioClip等接口直接加载外部资源，而后者只能用于加载AssetBundle；
前者的劣势
● 每次加载都涉及到解压操作，而后者在第二次加载时就省去了解压的开销；
● 在内存中会有较大的WebStream，而后者在内存中只有通常较小的SerializedFile。（此项为一般情况，但并不绝对，对于序列化信息较多的Prefab，很可能出现SerializedFile比WebStream更大的情况）
二 AssetBundle加载进阶
内存分析
[图片上传中...(image-3502b2-1614150957598-0)]
分布图，在左侧则列出了每一类内存的产生所涉及到的加载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以外，资源文件可以通过三种方式来卸载：
通过 Resources.UnloadAsset卸载指定的资源，CPU开销小；
通过Resources.UnloadUnusedAssets一次性卸载所有未被引用的资源，CPU开销大；
通过AssetBundle.Unload(true)在卸载AssetBundle对象时，将加载出来的资源一起卸载。
而对于Prefab，目前仅能通过DestroyImmediate来卸载，且卸载后，必须重新加载AssetBundle才能重新加载该Prefab。由于内存开销较小，通常不建议进行针对性地卸载。
● WWW对象：调用对象的Dispose函数或将其置为null即可；
● WebStream：在卸载WWW对象以及对应的AssetBundle对象后，这部分内存即会被引擎自动卸载；
● SerializedFile：卸载AssetBundle后，这部分内存会被引擎自动卸载；
● AssetBundle对象：AssetBundle的卸载有两种方式：
通过AssetBundle.Unload(false)，卸载AssetBundle对象时保留内存中已加载的资源；
通过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）。
- 游戏进行的情况下，则需要避免使用同步操作引起卡顿，因此可以考虑使用new WWW配合AssetBundle.LoadAsync来进行平滑的资源加载，但需要注意的是，对于Shader、较大的Texture等资源，其初始化操作通常很耗时，容易引起卡顿，因此建议将这类资源在加载场景时进行预加载。
● 只在Bundle需要加密的情况下，考虑使用CreateFromMemory，因为该接口加载速度较慢。
● 尽量避免在游戏进行中调用Resources.UnloadUnusedAssets()，因为该接口开销较大，容易引起卡顿，可尝试使用Resources.Unload(obj)来逐个进行卸载，以保证游戏的流畅度。
