Note: This section describes the creation of AssetBundles using the built-in BuildPipeline.BuildAssetBundles() API. A recommended, and more user friendly, alternative is to use the Addressables package.
In the documentation on the AssetBundle Workflow, we have a code sample which passes three arguments to the BuildPipeline.BuildAssetBundles function. Let’s dive a little deeper into what we’re actually saying.
_Assets/AssetBundles_:这是 AssetBundle 要输出到的目录。可以将其更改为所需的任何输出目录,只需确保在尝试构建之前文件夹实际存在。
可以指定几个具有各种效果的不同 BuildAssetBundleOptions
。请参阅关于 BuildAssetBundleOptions 的脚本 API 参考查看所有这些选项的表格。
虽然可以根据需求变化和需求出现而自由组合 BuildAssetBundleOptions
,但有三个特定的 BuildAssetBundleOptions
可以处理 AssetBundle 压缩:
BuildAssetBundleOptions.None
:此捆绑包选项使用 LZMA 格式压缩,这是一个压缩的 LZMA 序列化数据文件流。LZMA 压缩要求在使用捆绑包之前对整个捆绑包进行解压缩。此压缩使文件大小尽可能小,但由于需要解压缩,加载时间略长。值得注意的是,在使用此 BuildAssetBundleOptions 时,为了使用捆绑包中的任何资源,必须首先解压缩整个捆绑包。
解压缩捆绑包后,将使用 LZ4 压缩技术在磁盘上重新压缩捆绑包,这不需要在使用捆绑包中的资源之前解压缩整个捆绑包。最好在包含资源时使用,这样,使用捆绑包中的一个资源意味着将加载所有资源。这种捆绑包的一些用例是打包角色或场景的所有资源。
由于文件较小,建议仅从异地主机初次下载 AssetBundle 时才使用 LZMA 压缩。通过 UnityWebRequestAssetBundle 加载的 LZMA 压缩格式 Asset Bundle 会自动重新压缩为 LZ4 压缩格式并缓存在本地文件系统上。如果通过其他方式下载并存储捆绑包,则可以使用 AssetBundle.RecompressAssetBundleAsync API 对其进行重新压缩。
BuildAssetBundleOptions.UncompressedAssetBundle
:此捆绑包选项采用使数据完全未压缩的方式构建捆绑包。未压缩的缺点是文件下载大小增大。但是,下载后的加载时间会快得多。未压缩的 AssetBundles 是 16 字节对齐的。
BuildAssetBundleOptions.ChunkBasedCompression
:此捆绑包选项使用称为 LZ4 的压缩方法,因此压缩文件大小比 LZMA 更大,但不像 LZMA 那样需要解压缩整个包才能使用捆绑包。LZ4 使用基于块的算法,允许按段或“块”加载 AssetBundle。解压缩单个块即可使用包含的资源,即使 AssetBundle 的其他块未解压缩也不影响。
使用 ChunkBasedCompression
时的加载时间与未压缩捆绑包大致相当,额外的优势是减小了占用的磁盘大小。
BuildTarget.Standalone
:这里我们告诉构建管线,我们要将这些 AssetBundle 用于哪些目标平台。可以在关于 BuildTarget 的脚本 API 参考中找到可用显式构建目标的列表。但是,如果不想在构建目标中进行硬编码,请充分利用 EditorUserBuildSettings.activeBuildTarget
,它将自动找到当前设置的目标构建平台,并根据该目标构建 AssetBundle。
一旦正确设置构建脚本,最后便可以开始构建资源包了。如果是按照上面的脚本示例进行的操作,请单击 Assets > Build AssetBundles 以开始该过程。
Now that you’ve successfully built your AssetBundles, you may notice that your AssetBundles directory has more files than you might have originally expected. 2*(n+1) more files, to be exact. Let’s take a minute and go over exactly what the BuildPipeline.BuildAssetBundles
call yields.
对于在编辑器中指定的每个 AssetBundle,可以看到一个具有 AssetBundle 名称+“.manifest”的文件。
There will be an additional bundle and manifest that doesn’t share a name with any AssetBundle you created. It, instead, is named after the directory that it’s located in (where the AssetBundles were built to). This is the Manifest Bundle. This bundle contains the AssetBundleManifest object which will be useful for figuring out which bundle dependencies to load at runtime. To learn more about how to use this bundle and the manifest object, see documentation on Using AssetBundles Natively.
这是缺少 .manifest 扩展名的文件,其中包含在运行时为了加载资源而需要加载的内容。
AssetBundle 文件是一个存档,在内部包含多个文件。此存档的结构根据它是 AssetBundle 还是场景 AssetBundle 可能会略有不同。以下是普通 AssetBundle 的结构:
场景 AssetBundle 与普通 AssetBundle 的不同之处在于,它针对场景及其内容的串流加载进行了优化。
For every bundle generated, including the additional Manifest Bundle, an associated manifest file is generated. The manifest file has the extension .manifest and can be opened with any text editor. It contains information such as the cyclic redundancy check (CRC) data and dependency data for the bundle. The manifest files for normal AssetBundles will look something like this:
ManifestFileVersion: 0
CRC: 2422268106
Hashes:
AssetFileHash:
serializedVersion: 2
Hash: 8b6db55a2344f068cf8a9be0a662ba15
TypeTreeHash:
serializedVersion: 2
Hash: 37ad974993dbaa77485dd2a0c38f347a
HashAppended: 0
ClassTypes:
- Class: 91
Script: {instanceID: 0}
Assets:
Asset_0: Assets/Mecanim/StateMachine.controller
Dependencies: {}
其中显示了包含的资源、依赖项和其他信息。
A manifest file is also generated for the Manifest Bundle. It will look like this:
ManifestFileVersion: 0
AssetBundleManifest:
AssetBundleInfos:
Info_0:
Name: scene1assetbundle
Dependencies: {}
This file records how AssetBundles relate, and what their dependencies are. This is similar to the information recorded by the AssetBundleManifest object, inside the Manifest Bundle, and because it is a text file it is convenient for human readability and parsing by external tools.