03-02-架构篇-Editor打包系统架构
本章将深入解析 YooAsset 的 Editor 端系统架构。Editor 端是 YooAsset 的构建层，负责资源收集、依赖分析、资源打包和清单生成等核心功能。理解 Editor 端架构是掌握 YooAsset 构建流程的关键。
Editor 端系统架构
篇章：03-架构篇
阅读时间：约 40 分钟
前置知识：了解整体架构设计
一、引言
本章将深入解析 YooAsset 的 Editor 端系统架构。Editor 端是 YooAsset 的构建层，负责资源收集、依赖分析、资源打包和清单生成等核心功能。理解 Editor 端架构是掌握 YooAsset 构建流程的关键。
YooAsset 的 Editor 端采用了 Collector → BuildMap → Builder → Manifest 的流水线设计，每个环节职责清晰，相互协作。本章将详细解析每个环节的设计和实现。
二、AssetBundleCollector 架构
2.1 Collector 的概念
AssetBundleCollector 是 YooAsset 的资源收集器，负责根据用户的配置收集需要打包的资源。它是整个构建流程的起点，决定了哪些资源会被纳入构建流程。
Collector 的定义：
Collector 是一个抽象类，定义了资源收集的基本接口。具体的收集器继承自 Collector，实现具体的收集逻辑。
Collector 的作用：
- 资源收集：扫描指定路径，根据过滤规则收集需要打包的资源
- 资源分类：根据 Collector 类型对资源进行分类（主资源、静态资源、依赖资源）
- 寻址配置：配置资源的寻址方式（String Address、GUID Address、Label Address）
- 打包配置：配置资源的打包规则（Pack Rule）和过滤规则（Filter Rule）
Collector 的属性：
public abstract class Collector
{
public string CollectPath; // 收集路径
public string CollectorName; // 收集器名称
public ECollectorType CollectorType; // 收集器类型
public IPackRule PackRule; // 打包规则
public IFilterRule FilterRule; // 过滤规则
public EAddressRule AddressRule; // 寻址规则
public List<string> AssetTags; // 资源标签
public string UserData; // 用户自定义数据
}
2.2 Package、Group、Collector 层级
YooAsset 采用 Package → Group → Collector 的三级层级结构：
Package / Group / Collector 层级结构
├── Package（资源包）
│ ├── PackageName：包名
│ ├── PackageVersion：版本
│ ├── PackageManifest：清单
│ └── Group 列表
├── Group（分组）
│ ├── GroupName：分组名
│ ├── GroupDesc：分组描述
│ ├── PackRule：打包规则
│ └── Collector 列表
└── Collector（收集器）
├── CollectPath：收集路径
├── CollectorType：收集器类型
├── PackRule：打包规则
└── FilterRule：过滤规则
Package 详解：
Package 是 YooAsset 资源管理的最高层级，代表一个完整的资源包。每个 Package 有自己的名称、版本和清单（Manifest），可以独立打包、更新和加载。
Package 的特点：
- 独立性：每个 Package 独立管理自己的资源
- 可配置性：Package 的配置可以独立修改
- 可热更性：Package 可以独立进行热更新
Group 详解：
Group 是 Package 下的分组，将相关的 Collector 组织在一起。Group 用于对资源进行逻辑分组，便于管理。
Group 的特点：
- 逻辑分组：将相关的资源收集器组织在一起
- 统一打包：Group 内的资源可以统一打包
- 依赖管理：Group 之间的依赖关系便于管理
Collector 详解：
Collector 是最细粒度的资源收集器，定义了具体的资源收集路径和规则。每个 Collector 对应一个或多个资源的收集。
层级关系：
一个 Package 可以包含多个 Group，一个 Group 可以包含多个 Collector。这种三级层级结构提供了灵活的资源组织方式。
2.3 Collector 的工作原理
Collector 的工作流程如下：
- 路径指定：指定需要收集的资源路径（文件夹或单个文件）
- 资源扫描：扫描指定路径下的所有资源
- 过滤处理：根据过滤规则排除不需要的资源
- 规则应用：根据打包规则和寻址规则处理资源
- 结果输出：输出收集到的资源列表
路径指定详解：
CollectPath 是 Collector 的资源收集路径，可以是文件夹路径或单个文件路径。例如 Assets/UI、Assets/Characters/Hero.prefab。
资源扫描详解：
资源扫描会递归扫描 CollectPath 下的所有资源，包括子目录中的资源。扫描会识别资源的类型、依赖关系等信息。
过滤处理详解：
过滤处理根据 FilterRule 排除不需要的资源。常见的过滤规则包括按路径过滤、按类型过滤、按标签过滤等。
规则应用详解：
规则应用根据 PackRule 和 AddressRule 处理资源。PackRule 决定资源的打包方式，AddressRule 决定资源的寻址方式。
结果输出详解：
Collector 最终输出一个资源列表，包括每个资源的路径、类型、依赖关系、Bundle 分配等信息。
2.4 Collector 的寻址模式
YooAsset 支持三种寻址模式：
| 寻址模式 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| String Address | 通过字符串地址寻址，如 "ui/login" | 易读、易记 | 可能冲突 |
| GUID Address | 通过资源 GUID 寻址 | 唯一、不冲突 | 不可读 |
| Label Address | 通过标签寻址 | 批量访问 | 需要额外配置 |
String Address 详解：
String Address 是最常用的寻址模式，通过资源的相对路径或自定义字符串作为地址。例如 ui/login、characters/hero。
GUID Address 详解：
GUID Address 通过资源的 GUID 作为地址。GUID 是 Unity 为每个资源生成的唯一标识符，使用 GUID 作为地址可以避免地址冲突。
Label Address 详解：
Label Address 通过标签（Tag）寻址。开发者可以为资源打标签，然后通过标签批量访问资源。例如 ui、character。
混合寻址详解：
YooAsset 支持混合寻址模式，可以同时使用多种寻址方式。开发者可以根据需要灵活选择寻址方式。
三、BuildMap 架构
3.1 BuildMap 的概念
BuildMap 是 YooAsset 的构建映射，记录了资源到 Bundle 的映射关系以及 Bundle 之间的依赖关系。它是资源打包的蓝图。
BuildMap 的定义：
BuildMap 是一个数据结构，包含了所有 Bundle 的信息、每个 Bundle 包含的资源、Bundle 之间的依赖关系等。
BuildMap 的作用：
- 打包依据：BuildMap 是资源打包的依据，Builder 根据 BuildMap 执行打包
- 依赖管理：BuildMap 记录了 Bundle 之间的依赖关系
- 优化建议：BuildMap 可以检测资源冗余、循环依赖等问题
BuildMap 的生成：
BuildMap 是由 Collector 输出的结果经过分析处理后生成的。它整合了所有 Collector 的收集结果，并进行了依赖分析。
3.2 BuildMap 的工作流程
BuildMap 的工作流程如下：
- 收集所有 Collector 输出：从所有 Collector 收集资源信息
- 分析资源到 Bundle 的分配：根据 Pack Rule 决定每个资源属于哪个 Bundle
- 分析资源依赖关系：分析资源之间的依赖关系
- 提取共享资源：识别被多个 Bundle 共享的资源
- 检测循环依赖：检测依赖图中是否存在循环依赖
- 生成最终 BuildMap：整合所有信息生成最终的 BuildMap
3.3 BuildMap 的数据结构
BuildMap 包含以下数据结构：
BuildMap 数据结构
├── Bundle 列表
│ ├── Bundle 名称
│ ├── Bundle 包含的资源
│ └── Bundle 依赖的其他 Bundle
├── 资源映射
│ ├── 资源地址
│ ├── 资源类型
│ └── 资源所属 Bundle
└── 依赖图
├── 节点：Bundle 和资源
└── 边：依赖关系
Bundle 列表详解：
Bundle 列表记录了所有 Bundle 的信息，包括每个 Bundle 的名称、包含的资源、依赖的其他 Bundle 等。
资源映射详解：
资源映射记录了资源到 Bundle 的映射关系。通过资源映射，可以快速找到某个资源属于哪个 Bundle。
依赖图详解：
依赖图记录了 Bundle 之间和资源之间的依赖关系。通过依赖图，可以分析资源的依赖关系，检测循环依赖。
3.4 BuildMap 的错误检测
BuildMap 可以检测以下类型的错误：
冗余检测：
冗余检测会检测是否存在重复打包的资源。如果一个资源被多个 Bundle 包含，BuildMap 会发出警告。
依赖警报：
依赖警报会检测资源之间的依赖关系是否合理。如果存在异常的依赖关系，BuildMap 会发出警告。
优化建议：
BuildMap 可以根据分析结果给出优化建议，例如建议将某些资源合并打包、建议拆分过大的 Bundle 等。
四、Builder 架构
4.1 Builder 的概念
Builder 是 YooAsset 的构建器，负责执行实际的打包操作。它是 BuildMap 和 AssetBundle 之间的桥梁。
Builder 的定义：
Builder 是一个抽象类，定义了构建的基本接口。具体的构建器继承自 Builder，实现具体的构建逻辑。
Builder 的作用：
- 执行打包：根据 BuildMap 执行实际的 AssetBundle 打包操作
- 支持多种管线：支持内置构建管线和 SBP 构建管线
- 生成构建报告：生成详细的构建报告
Builder 的属性：
public abstract class Builder
{
public BuildParameters BuildParameters; // 构建参数
public IBuildPipeline BuildPipeline; // 构建管线
public BuildReport Report; // 构建报告
}
4.2 内置构建管线
YooAsset 的内置构建管线是基于 Unity 内置的 AssetBundle 构建 API 实现的。
内置构建管线的定义：
内置构建管线是 YooAsset 默认提供的构建管线，使用 Unity 内置的 AssetBundle 构建 API。
内置构建管线的流程：
- 获取 BuildMap
- 调用 Unity 内置的 AssetBundle 构建 API
- 生成 AssetBundle 文件
- 生成构建报告
内置构建管线的优点：
- 简单：使用 Unity 内置 API，实现简单
- 稳定：经过 Unity 官方验证，稳定性高
- 兼容性好：兼容所有 Unity 支持的平台
内置构建管线的缺点：
- 性能有限：不支持并行构建，构建速度有限
- 自定义能力有限：受限于 Unity 内置 API 的能力
4.3 SBP 构建管线
SBP（Scriptable Build Pipeline）是 Unity 提供的高级构建管线。
SBP 构建管线的定义：
SBP 构建管线是基于 Unity 的 Scriptable Build Pipeline 实现的，提供了更强大的构建能力。
SBP 构建管线的流程：
- 获取 BuildMap
- 调用 SBP API 执行构建
- 生成 AssetBundle 文件
- 生成构建报告
SBP 构建管线的优点：
- 性能强：支持并行构建，构建速度快
- 自定义能力强：支持自定义构建任务
- 支持增量构建：原生支持增量构建
SBP 构建管线的缺点：
- 需要安装 SBP 包：需要单独安装 Scriptable Build Pipeline 包
- 配置复杂：配置相对复杂
4.4 任务系统设计
YooAsset 的构建采用了任务系统设计：
任务系统设计
├── 任务节点：构建流程中的每个操作是一个任务节点
├── 任务依赖：任务节点之间可以定义依赖关系
├── 任务执行：根据依赖关系执行任务
└── 任务回调：任务完成后的回调通知
任务节点详解：
任务节点是构建流程中的基本单位，每个任务节点代表一个具体的操作，如"收集资源"、"分析依赖"、"打包资源"等。
任务依赖详解：
任务节点之间可以定义依赖关系，例如"打包资源"任务依赖于"收集资源"和"分析依赖"任务。
任务执行详解：
任务执行器会根据任务依赖关系，按照正确的顺序执行任务。支持并行执行独立的任务。
任务回调详解：
任务完成后会触发回调通知，可以用于更新进度、显示日志等。
五、增量构建
5.1 增量构建的概念
增量构建是只重新打包发生变化的资源，而不是重新打包所有资源。
增量构建的定义：
增量构建是指在上一次构建的基础上，只重新打包发生变化的资源，未变化的资源直接复用上一次的构建结果。
增量构建的优势：
- 大幅减少构建时间：只需处理变化的资源
- 减少资源冗余：未变化的资源直接复用
- 提高开发效率：开发者可以更快地完成构建
增量构建的前提：
增量构建的前提是能够准确检测资源的变化。YooAsset 通过对比前后两次构建的 BuildMap 来检测资源变化。
5.2 增量构建的实现
增量构建的实现步骤如下：
- 对比当前 BuildMap 和上次 BuildMap
- 找出变化的 Bundle
- 只重新打包变化的 Bundle
- 复用未变化的 Bundle，不重新构建
- 生成新的 Manifest
BuildMap 对比详解：
BuildMap 对比是增量构建的核心。通过对比两个 BuildMap，可以准确识别变化的 Bundle 和未变化的 Bundle。
变化检测详解：
变化检测会检查每个 Bundle 的内容是否发生变化。如果 Bundle 内的资源发生变化，或者 Bundle 的依赖关系发生变化，则认为该 Bundle 发生了变化。
复用策略详解：
未变化的 Bundle 会被直接复用，不会重新构建。这可以显著减少构建时间和构建产物的大小。
5.3 增量构建的局限性
增量构建存在以下局限性：
资源类型变化：
当资源类型发生变化时（如从 Texture 改为 Sprite），需要重新打包。
依赖关系变化：
当资源的依赖关系发生变化时，需要重新打包相关的 Bundle。
配置变化：
当构建配置发生变化时（如压缩算法、加密方式），需要重新打包。
六、构建配置
6.1 压缩配置
YooAsset 支持多种压缩算法：
压缩配置
├── 压缩算法选择：LZMA、LZ4、不压缩
├── 压缩权衡：压缩率 vs 压缩/解压速度
└── 多 Bundle 配置：不同 Bundle 使用不同压缩方式
压缩算法选择：
YooAsset 支持 LZMA、LZ4、不压缩三种压缩方式。LZMA 压缩率高但解压慢，适合网络传输；LZ4 压缩率适中但解压快，适合运行时加载；不压缩最快但体积大，适合首包资源。
压缩权衡：
压缩需要在压缩率、压缩速度、解压速度之间权衡。开发者需要根据项目需求选择合适的压缩方式。
多 Bundle 配置：
YooAsset 支持为不同的 Bundle 配置不同的压缩方式，可以根据 Bundle 的特点选择合适的压缩方式。
6.2 加密配置
YooAsset 支持多种加密方式：
加密配置
├── 加密算法选择：AES、XOR
├── 加密粒度：整体 Bundle 加密 vs 单个资源加密
└── 加密密钥：管理加密密钥的存储位置
加密算法选择：
YooAsset 支持 AES 和 XOR 两种加密算法。AES 安全性高但性能开销大，XOR 性能好但安全性低。
加密粒度：
加密粒度可以是整体 Bundle 加密或单个资源加密。整体 Bundle 加密实现简单，单个资源加密更灵活。
加密密钥：
加密密钥需要妥善管理。YooAsset 支持通过 IDecryptionServices 接口自定义密钥管理方式。
6.3 平台配置
YooAsset 支持多平台构建：
平台配置
├── 目标平台选择：iOS、Android、Windows、WebGL 等
├── 平台特定配置：不同平台的优化设置
└── 多平台构建：一次构建多平台
目标平台选择：
YooAsset 支持 iOS、Android、Windows、WebGL 等所有 Unity 支持的平台。开发者可以根据需要选择目标平台。
平台特定配置：
不同平台可能有不同的优化设置。例如，移动端通常需要更小的资源体积，PC 端可以接受更大的资源体积。
多平台构建：
YooAsset 支持一次构建多平台，可以同时为多个平台生成构建产物。
七、总结
本章深入解析了 YooAsset Editor 端的系统架构，包括：
- AssetBundleCollector：资源收集器，负责资源的收集和分类
- BuildMap：构建映射，记录资源到 Bundle 的映射关系
- Builder：构建器，执行实际的打包操作
- 增量构建：只重新打包变化的资源，提高构建效率
- 构建配置：压缩、加密、平台等配置
理解 Editor 端架构是掌握 YooAsset 构建流程的关键。通过灵活运用这些架构设计，可以实现高效、灵活的资源打包。
上一篇：整体架构设计
下一篇：Runtime 端系统架构
浙公网安备 33010602011771号