186-6908-0178
186-6908-0178
篇章：02-原理篇 · 基础 阅读时间：约 40 分钟 前置知识：了解 Unity 基本资源加载方式
AssetBundle（简称 AB 包）是 Unity 资源管理的基石。理解它的底层原理，是掌握后续所有资源管理方案（包括 Addressables 和 YooAsset）的前提。本章将深入剖析 AssetBundle 的内部结构、打包机制、加载流程和内存管理原理，结合 Unity 官方文档和实际项目经验，全面解析 AB 包的工作原理。
AssetBundle 是 Unity 提供的一种将资源打包成自定义格式文件的机制。通过 AssetBundle，开发者可以将资源从游戏安装包中分离出来，实现按需加载、热更新、资源共享等功能。Unity 从 5.2 版本开始正式支持 AssetBundle，此后不断完善相关功能。
AssetBundle 的核心价值在于它将资源与代码分离，使得资源可以在游戏运行时动态加载和卸载。这种机制对于大型游戏项目尤为重要，因为大型游戏通常包含数百 GB 的资源，无法全部打包在安装包中。通过 AssetBundle，开发者可以将资源分成多个小包，根据游戏进度按需加载，从而有效控制安装包大小和运行时内存占用。
一个 AssetBundle 文件在磁盘上的结构可以分为以下几个部分，理解这些结构对于优化加载性能和内存管理至关重要：
python代码解读复制代码AssetBundle 文件结构 ├── 文件头（File Header） │ ├── 签名标识
（Signature）：标识文件类型和版本 │ ├── 文件版本（Version）：AssetBundle 格式版本 │ ├──
压缩方式（Compression）：LZMA / LZ4 / 无压缩 │ ├── 文件大小（File Size）：整个文件的字节数 │
└── 序列化版本（Serialized Version）：Unity 序列化格式版本 ├── 资源数据块（Asset Data Blocks） │
├── Asset 1 数据：资源原始数据 + 序列化信息 │ │ ├── 资源类型标识（Type ID） │ │
├── 资源数据长度 │ │ └── 资源二进制数据 │ ├── Asset 2 数据 │ └──
... ├── 依赖信息（Dependency Information） │ ├── 依赖 Bundle 数量 │ ├── 依赖
Bundle 名称列表 │ └── 依赖 Bundle 的 CRC 校验值 ├── 资源清单（Asset Manifest） │
├── 资源数量 │ ├── 资源名称列表 │ ├── 资源偏移量（Offset） │ ├──
资源大小（Size） │ └── 资源类型信息（Type Information） └── 类型树（Type Tree）
├── 类型数量 └── 类型定义列表
文件头详解：文件头是 AssetBundle 的第一个部分，包含文件的元数据。签名标识用于验证文件是否为有效的 AssetBundle 文件，其值为 UnityFS。文件版本标识了 AssetBundle 的格式版本，不同版本的 Unity 可能使用不同的格式版本。压缩方式决定了资源数据的压缩算法，文件大小记录了整个文件的字节数，序列化版本标识了 Unity 序列化格式的修订版本。
资源数据块详解：资源数据块是 AssetBundle 的核心部分，存储了所有资源的实际数据。每个资源的数据块包含资源的原始二进制数据和 Unity 序列化信息。Unity 使用自定义的序列化格式来存储资源数据，这种格式支持跨平台的数据交换。序列化信息包含了资源的类型、属性值、引用关系等。
依赖信息详解：依赖信息记录了当前 Bundle 所依赖的其他 Bundle 列表。每个依赖项都包含 Bundle 名称和 CRC 校验值，用于在加载时验证依赖 Bundle 的完整性。CRC 校验值用于确保依赖 Bundle 没有被篡改或损坏。
资源清单详解：资源清单是 AssetBundle 的索引部分，记录了 Bundle 中所有资源的名称、偏移量、大小和类型信息。通过资源清单，Unity 可以快速定位和加载指定的资源，而不需要遍历整个文件。
类型树详解：类型树记录了 Bundle 中所有资源的类型定义。类型树用于在反序列化时正确解析资源数据，确保资源对象能够被正确重建。类型树包含了每个资源类型的字段信息，包括字段名称、字段类型、字段偏移量等。
AssetBundle 支持三种压缩方式，每种方式在体积和加载速度之间有不同的权衡：
压缩方式
压缩率
解压速度
适用场景
特点
LZMA | 60-80% | 慢（1-3秒/MB） | 网络传输、首次下载 | 压缩率最高，解压慢 |
LZ4 | 40-60% | 极快（0.1秒/MB） | 运行时加载、本地存储 | 解压速度极快，压缩率适中 |
LZ4HC | 50-70% | 快（0.5秒/MB） | 平衡场景 | LZ4 的高压缩率变体 |
无压缩 | 0% | 最快（直接读取） | 首包资源、性能敏感场景 | 无压缩，加载最快 |
LZMA 压缩原理：LZMA（Lempel-Ziv-Markov chain Algorithm）是一种基于字典的压缩算法。它通过查找数据中的重复模式来压缩数据，压缩率非常高，但解压速度较慢。LZMA 适合用于网络传输场景，因为较小的文件体积可以减少下载时间。在 AssetBundle 中，LZMA 压缩的数据在首次加载时需要解压到内存中，这个过程可能需要数百毫秒。
LZMA 算法的核心思想是查找数据中的重复字符串，并用较短的引用代替。它使用一个称为"字典"的数据结构来存储已经处理过的数据，当遇到重复字符串时，就用字典中的引用代替。LZMA 的压缩率之所以高，是因为它使用了更长的字典和更复杂的编码算法。
LZ4 压缩原理：LZ4 是一种快速压缩算法，它在压缩率和解压速度之间取得了良好的平衡。LZ4 的解压速度极快，几乎可以与无压缩的数据相媲美，因此非常适合运行时加载场景。LZ4 使用滑动窗口算法来查找重复数据块，解压时只需要线性扫描数据。
LZ4 算法的核心思想是查找数据中的重复数据块，并用较短的引用代替。与 LZMA 不同，LZ4 使用了更小的字典和更简单的编码算法，因此压缩率较低，但解压速度极快。LZ4 的解压速度可以达到每秒数百 MB，几乎可以与无压缩的数据相媲美。
LZ4HC 压缩原理：LZ4HC（LZ4 High Compression）是 LZ4 的高压缩率变体，它在保持较解压速度的同时，提供了比标准 LZ4 更高的压缩率。LZ4HC 适合用于需要平衡压缩率和解压速度的场景。
LZ4HC 算法的核心思想是在 LZ4 的基础上，使用更长的字典和更复杂的编码算法，从而提高压缩率。LZ4HC 的压缩率比标准 LZ4 高约 10-20%，但压缩速度较慢，解压速度与标准 LZ4 相当。
Unity 使用自定义的序列化格式来存储资源数据。序列化是将对象的状态转换为可以存储或传输的格式的过程。Unity 的序列化机制支持以下特性：
跨平台兼容：序列化数据可以在不同平台之间交换，因为序列化格式是平台无关的
类型安全：序列化过程中保留资源的类型信息，确保反序列化时能够正确重建对象
引用管理：自动处理对象之间的引用关系，确保引用指向正确的对象
增量更新：支持部分序列化和增量更新，减少序列化数据的大小
Unity 的序列化格式包含以下关键信息：
类型标识：每个资源类型的唯一标识符
属性值：资源的属性值，如位置、旋转、缩放等
引用列表：资源引用的其他资源的索引
嵌套对象：嵌套对象的序列化数据
Unity 的序列化格式采用二进制编码，相比 JSON 或 XML 等文本格式，二进制格式具有更小的体积和更快的解析速度。Unity 的序列化格式支持以下数据类型：
基本类型：int、float、bool、string 等
复合类型：Array、List、Dictionary 等
引用类型：Object、Component、GameObject 等
自定义类型：用户自定义的 Serializable 类
AssetBundle 的打包过程可以分为以下几个步骤：
资源选择：选择需要打包的资源文件
依赖分析：分析资源之间的依赖关系
数据序列化：将资源数据序列化为二进制格式
压缩处理：根据配置的压缩算法对数据进行压缩
文件组装：将序列化数据和元数据组装成 AssetBundle 文件
清单生成：生成资源清单和依赖信息
依赖分析是 AssetBundle 打包的核心环节。Unity 在打包时会递归地分析资源之间的依赖关系，确保所有依赖的资源都被正确打包。
依赖分析流程：
csharp代码解读复制代码// Unity 内部的依赖分析伪代码 public class DependencyAnalyzer {
public List<string> AnalyzeDependencies(string assetPath) { var dependencies =
new List<string>(); var visited = new HashSet<string>();
AnalyzeAsset(assetPath, dependencies, visited); return dependencies;
} private void AnalyzeAsset(string assetPath, List<string> dependencies,
HashSet<string> visited) { if (visited.Contains(assetPath))
return; visited.Add(assetPath);
// 获取资源的直接依赖
var directDeps = GetDirectDependencies(assetPath);
foreach (var dep in directDeps) {
// 递归分析依赖的依赖
AnalyzeAsset(dep, dependencies, visited); }
dependencies.Add(assetPath); }
private List<string> GetDirectDependencies(string assetPath)
{ // 使用 Unity 的 AssetDatabase API 获取依赖
return AssetDatabase.GetDependencies(assetPath); } }
依赖分析的关键点：
递归分析：依赖分析是递归进行的，确保所有层级的依赖都被找到
去重处理：使用 HashSet 避免重复分析同一个资源
循环依赖检测：Unity 会检测循环依赖并抛出错误
外部依赖处理：对于不在当前 Bundle 中的依赖，需要单独处理
依赖图示例：
less代码解读复制代码Bundle A: [Prefab1, Texture1] Bundle B: [Prefab2, Texture1, Material1] Bundle C:
[Prefab3, Material1] 依赖关系： Prefab1 -> Texture1 Prefab2 -> Texture1, Material1 Prefab3 ->
Material1 Material1 -> Texture1 共享资源：Texture1（被 A、B 引用）、Material1（被 B、C 引用）
AssetBundle 支持多种打包策略，每种策略在资源组织和管理上有不同的特点：
打包策略
描述
优点
缺点
单独打包 | 每个资源单独打包成一个 AB 文件 | 粒度细，更新灵活 | AB 文件数量多，管理复杂 |
目录打包 | 同一目录下的资源打包成一个 AB 文件 | 粒度适中，管理简单 | 更新不够灵活 |
类型打包 | 同一类型的资源打包成一个 AB 文件 | 便于类型管理 | 可能导致资源冗余 |
场景打包 | 每个场景单独打包 | 场景加载方便 | 场景依赖的资源需要额外处理 |
打包策略选择建议：
按模块分包：每个功能模块一个 Bundle，适合大型项目，模块间耦合度低
按类型分包：所有纹理一个 Bundle，所有音频一个 Bundle，适合小型项目，资源类型少
按场景分包：每个场景的资源一个 Bundle，适合关卡制游戏
按更新频率分包：频繁更新的资源单独分包，适合需要频繁热更新的项目
共享资源提取：共享资源单独打包，避免重复，适合大型项目，资源复用率高
AssetBundle 的加载过程可以分为以下几个步骤：
加载 Bundle 文件：从磁盘或网络加载 AssetBundle 文件
依赖加载：加载 Bundle 所依赖的其他 Bundle
资源加载：从 Bundle 中加载指定的资源
资源实例化：将加载的资源实例化为游戏对象
Unity 提供了多种加载 AssetBundle 的 API：
csharp代码解读复制代码// 方式一：从文件加载 AssetBundleCreateRequest request =
AssetBundle.LoadFromMemoryAsync(fileData); yield return request; AssetBundle bundle =
request.assetBundle; // 方式二：从 URL 加载 AssetBundleCreateRequest request = AssetBundle.
LoadFromMemoryAsync(fileData); yield return request; AssetBundle bundle = request.assetBundle;
// 方式三：从缓存加载 AssetBundleCreateRequest request = AssetBundle.LoadFromMemoryAsync(fileData);
yield return request; AssetBundle bundle = request.assetBundle; // 加载资源 GameObject prefab =
bundle.LoadAsset<GameObject>("MyPrefab"); // 实例化资源 GameObject instance = Instantiate(prefab);
API 详解：
AssetBundle.LoadFromMemoryAsync：从内存中异步加载 AssetBundle
AssetBundle.LoadFromStreamAsync：从流中异步加载 AssetBundle
AssetBundle.LoadAsset<T>：从 Bundle 中加载指定类型的资源
AssetBundle.LoadAllAssets<T>：从 Bundle 中加载所有指定类型的资源
AssetBundle.Unload：卸载 Bundle，释放内存
加载 API 的最佳实践：
使用异步加载：避免阻塞主线程，提升用户体验
检查加载结果：每次加载后检查是否成功，避免空引用异常
及时卸载：在合适的时机卸载不再使用的 Bundle 和资源
使用引用计数：通过引用计数管理 Bundle 的生命周期
AssetBundle 的依赖加载是自动进行的。当加载一个 Bundle 时，Unity 会自动检查并加载其依赖的 Bundle。
依赖加载流程：
加载 Bundle：调用 AssetBundle.LoadFromFile 或 AssetBundle.CreateFromMemory 加载 Bundle
检查依赖：Unity 读取 Bundle 的依赖信息
加载依赖：递归加载所有依赖的 Bundle
加载完成：所有依赖加载完成后，Bundle 可以正常加载资源
依赖加载的注意事项：
依赖 Bundle 必须在被依赖 Bundle 之前加载
如果依赖 Bundle 不存在，加载会失败
可以通过 AssetBundle.LoadAssetWithSubAssets 加载资源及其子资源
依赖加载的常见问题：
依赖 Bundle 加载失败：原因通常是依赖 Bundle 没有被正确加载或路径不正确。解决方案是确保依赖 Bundle 在依赖 Bundle 之前加载，并检查 Bundle 路径是否正确。
循环依赖：原因通常是资源之间存在循环依赖关系。解决方案是检查资源依赖关系，打破循环依赖。
依赖 Bundle 版本不匹配：原因通常是依赖 Bundle 的版本与当前 Bundle 的版本不匹配。解决方案是确保所有 Bundle 使用相同的版本号。
AssetBundle 在内存中的布局可以分为以下几个部分：
Bundle 元数据：Bundle 的文件头、资源清单、类型树等元数据
资源数据：所有资源的序列化数据
资源对象：反序列化后生成的 Unity 资源对象
实例对象：通过 Instantiate 生成的游戏对象实例
内存布局示意图：
css代码解读复制代码内存布局 ├── Bundle 元数据 │ ├── 文件头 │ ├── 资源清单 │
└── 类型树 ├── 资源数据 │ ├── 纹理数据 │ ├── 模型数据 │
└── 音频数据 ├── 资源对象 │ ├── Texture2D 对象 │ ├── Mesh 对象 │
└── AudioClip 对象 └── 实例对象 ├── GameObject 实例 ├── Transform 组件
└── Renderer 组件
AssetBundle 的内存管理需要关注以下几个方面：
Bundle 卸载：
csharp代码解读复制代码// 卸载 Bundle，释放内存 // forceUnloadAll: true 表示强制卸载所有资源，即
使有引用 bundle.Unload(forceUnloadAll: false);
资源卸载：
csharp代码解读复制代码// 卸载资源对象 Resources.UnloadAsset(prefab); // 卸载所有未使用的资源
Resources.UnloadUnusedAssets();
内存管理的关键点：
引用计数：Unity 内部使用引用计数来管理资源的生命周期
卸载时机：需要在合适的时机卸载不再使用的 Bundle 和资源
内存泄漏：需要避免资源泄漏，确保不再使用的资源被正确卸载
内存峰值：需要控制内存峰值，避免 OOM（Out of Memory）
引用计数机制详解：
Unity 内部使用引用计数来管理 AssetBundle 的内存。每次调用 AssetBundle.LoadFromFile() 或 UnityWebRequestAssetBundle.GetAssetBundle() 时，引用计数加 1。每次调用 AssetBundle.Unload() 时，引用计数减 1。当引用计数为 0 时，Bundle 才会被真正卸载。
引用计数机制的注意事项：
引用计数不会自动减少：如果 Bundle 中的资源被其他对象引用，引用计数不会自动减少
需要手动管理引用：开发者需要手动管理资源的引用，确保在合适的时机卸载资源
使用 Profiler 监控：使用 Unity Profiler 监控引用计数，及时发现内存泄漏
资源共享：
csharp代码解读复制代码// 多个 Bundle 共享同一个资源 // 通过确保依赖关系正确，避免资源重复加载
资源池：
csharp代码解读复制代码// 使用对象池管理频繁创建和销毁的资源 public class ResourcePool<T> where T :
Object { private Queue<T> _pool = new Queue<T>(); public T Get() {
if (_pool.Count > 0) return _pool.Dequeue(); return null; }
public void Put(T obj) { _pool.Enqueue(obj); } }
纹理压缩：
csharp代码解读复制代码// 使用合适的纹理压缩格式 // Android: ASTC, ETC2 // iOS: ASTC, PVRTC // PC:
DXT, BC // WebGL: ETC2
纹理压缩的最佳实践：
根据平台选择压缩格式：不同平台支持不同的纹理压缩格式，需要根据目标平台选择合适的压缩格式
根据资源类型选择压缩格式：不同资源类型适合不同的压缩格式，如纹理适合使用 ASTC，UI 适合使用 PVRTC
根据资源大小选择压缩格式：大纹理适合使用高压缩率的压缩格式，小纹理适合使用低压缩率的压缩格式
问题一：依赖 Bundle 加载失败
原因：依赖 Bundle 没有被正确加载或路径不正确。
解决方案：确保依赖 Bundle 在依赖 Bundle 之前加载，并检查 Bundle 路径是否正确。
问题二：内存泄漏
原因：Bundle 或资源没有被正确卸载。
解决方案：使用 AssetBundle.Unload(false) 卸载 Bundle，使用 Resources.UnloadUnusedAssets() 卸载未使用的
资源。
问题三：资源加载慢
原因：Bundle 文件过大或压缩方式不合适。
解决方案：使用 LZ4 压缩，拆分大 Bundle，使用异步加载。
问题四：循环依赖
原因：资源之间存在循环依赖关系。
解决方案：检查资源依赖关系，打破循环依赖。
使用 Unity Profiler：
Unity Profiler 可以实时监控内存使用情况、加载时间等性能指标。
使用 AssetBundle Browser：
AssetBundle Browser 是 Unity 官方提供的 AssetBundle 管理工具，可以查看 Bundle 的依赖关系、资源列表等信息。
使用自定义日志：
在加载和卸载 Bundle 时记录日志，帮助定位问题。
AssetBundle 是 Unity 资源管理的基石，理解它的内部结构、打包机制、加载流程和内存管理原理，对于开发高性能的游戏至关重要。本章详细解析了 AssetBundle 的工作原理，为后续学习 Addressables 和 YooAsset 打下了坚实的基础。
在实际项目中，建议：
合理选择压缩方式：根据场景选择合适的压缩方式
优化依赖关系：避免循环依赖，减少依赖层级
及时卸载资源：在合适的时机卸载不再使用的资源
监控内存使用：使用 Profiler 等工具监控内存使用情况
使用异步加载：避免阻塞主线程，提升用户体验
通过深入理解 AssetBundle 的原理，我们可以更好地利用 Unity 的资源管理功能，开发出性能更优、体验更好的游戏。
作者：SmalBox
链接：https://juejin.cn/post/7685944952622907443
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
