整体架构设计
篇章:03-架构篇
阅读时间:约 40 分钟
前置知识:了解 YooAsset 基础概念
一、引言
本章将深入解析 YooAsset 的整体架构设计,从全局视角理解 YooAsset 是如何组织代码、如何划分模块、如何协调各个子系统工作的。理解整体架构是深入学习 YooAsset 各模块的基础。
YooAsset 是一个功能强大且架构清晰的资源管理框架。它通过精心设计的模块划分、清晰的接口定义和灵活的配置系统,为 Unity 开发者提供了完整的资源管理解决方案。本章将从架构层面全面解析 YooAsset 的设计思想。
二、双层系统架构
2.1 Editor 层与 Runtime 层的分离
YooAsset 采用 Editor 层和 Runtime 层分离的架构设计,这是其最重要的架构特征之一。
Editor 层详解:
Editor 层是 YooAsset 的构建层,运行在 Unity 编辑器中。它负责资源的收集、分析、打包和清单生成。Editor 层只在编辑时运行,不会包含在最终的游戏安装包中。
Editor 层的主要职责包括:
- 资源收集:根据 Collector 配置收集需要打包的资源
- 依赖分析:分析资源之间的依赖关系,构建依赖图
- 资源打包:执行实际的 AssetBundle 打包操作
- 清单生成:生成资源清单(Manifest)文件
- 构建报告:生成构建报告,帮助开发者分析构建结果
Runtime 层详解:
Runtime 层是 YooAsset 的运行层,在游戏运行时工作。它负责资源的加载、管理、缓存和卸载。Runtime 层会被编译到游戏安装包中,是玩家实际使用的部分。
Runtime 层的主要职责包括:
- 资源加载:根据资源地址加载 AssetBundle 中的资源
- 资源管理:管理已加载资源的生命周期
- 引用计数:使用引用计数管理资源的引用关系
- 缓存管理:管理内存缓存和磁盘缓存
- 热更新:支持资源热更新和版本管理
分层架构的好处:
- 职责分离:构建逻辑和运行逻辑分离,各自专注于自己的领域
- 独立测试:可以独立测试 Editor 层和 Runtime 层
- 性能优化:Runtime 层可以针对运行时进行优化,减少不必要的代码
- 包体减小:Editor 层的代码不会包含在最终安装包中,减小包体
- 维护性强:修改构建逻辑不会影响运行时的稳定性
2.2 Editor 层核心模块
YooAsset 的 Editor 层由以下核心模块组成:
Editor 层模块架构
├── AssetBundleCollector(资源收集器)
│ ├── MainAssetCollector:主资源收集器
│ ├── StaticAssetCollector:静态资源收集器
│ └── DependAssetCollector:依赖资源收集器
├── BuildMap(构建映射)
│ ├── 资源依赖图
│ ├── Bundle 分配方案
│ └── 循环依赖检测
├── AssetBundleBuilder(构建器)
│ ├── BuiltinBuildPipeline(内置构建管线)
│ ├── ScriptableBuildPipeline(SBP 构建管线)
│ └── EditorSimulateBuildPipeline(编辑器模拟管线)
├── TaskCreateManifest(清单创建任务)
│ ├── PackageManifest 生成
│ └── 资源清单写入
└── ReportBuilder(报告生成器)
├── 构建报告
└── 依赖分析报告
AssetBundleCollector 详解:
AssetBundleCollector 是资源收集器,负责根据用户的配置收集需要打包的资源。它是整个构建流程的起点,决定了哪些资源会被纳入构建流程。
BuildMap 详解:
BuildMap 是构建映射,记录了资源到 Bundle 的映射关系以及 Bundle 之间的依赖关系。它是资源打包的蓝图。
AssetBundleBuilder 详解:
AssetBundleBuilder 是构建器,负责执行实际的打包操作。它支持多种构建管线,可以根据项目需求选择合适的构建方式。
TaskCreateManifest 详解:
TaskCreateManifest 是清单创建任务,负责生成 PackageManifest 文件。PackageManifest 包含了所有 Bundle 的信息,是 Runtime 层加载资源的依据。
2.3 Runtime 层核心模块
YooAsset 的 Runtime 层由以下核心模块组成:
Runtime 层模块架构
├── YooAssets(全局静态入口)
│ ├── Package 管理
│ └── 初始化流程
├── ResourcePackage(资源包)
│ ├── 资源加载入口
│ └── 资源生命周期管理
├── ResourceManager(资源管理器)
│ ├── Provider 管理
│ ├── 引用计数管理
│ └── 缓存管理
├── Provider(资源提供者)
│ ├── AssetProvider
│ ├── SceneProvider
│ └── ComponentProvider
├── FileSystem(文件系统)
│ ├── IFileSystem 接口
│ └── 内置文件系统实现
├── OperationSystem(异步操作系统)
│ ├── 异步操作调度
│ └── 时间片管理
└── Operation(异步操作)
├── AsyncOperationBase
└── 具体操作实现
YooAssets 详解:
YooAssets 是 YooAsset 的全局静态入口,提供了统一的 API 让开发者与 YooAsset 进行交互。它内部委托给各个 ResourcePackage 对象。
ResourcePackage 详解:
ResourcePackage 是资源包,封装了一组相关资源的加载、卸载和管理。每个 ResourcePackage 都有自己的 Manifest、文件系统和资源管理器。
ResourceManager 详解:
ResourceManager 是资源管理器,负责资源加载、缓存、引用计数等核心功能。它是 Runtime 层的核心模块。
Provider 详解:
Provider 是资源提供者,封装了资源加载的具体逻辑。不同类型的资源有不同的 Provider 实现。
FileSystem 详解:
FileSystem 是文件系统抽象,负责跨平台的文件访问。它提供了统一的接口,屏蔽了不同平台的差异。
OperationSystem 详解:
OperationSystem 是异步操作系统,负责异步操作的调度和管理。它支持优先级调度、时间片管理等高级特性。
三、核心模块协作关系
3.1 模块协作总览
YooAsset 的各个模块不是独立工作的,它们相互协作完成资源管理的全流程。
YooAsset 模块协作总览
├── 构建阶段(Editor)
│ ├── AssetBundleCollector → 收集资源
│ ├── BuildMap → 构建依赖图
│ ├── AssetBundleBuilder → 执行打包
│ └── TaskCreateManifest → 生成清单
├── 数据流转
│ ├── Editor 生成 Manifest 文件
│ └── Runtime 读取 Manifest 文件
└── 运行阶段(Runtime)
├── YooAssets → 全局入口
├── ResourcePackage → 资源包
├── ResourceManager → 资源管理
└── Provider → 资源加载
构建阶段详解:
构建阶段是 YooAsset 的 Editor 层执行的阶段,包括资源收集、依赖分析、资源打包和清单生成等步骤。
数据流转详解:
数据流转是 Editor 层和 Runtime 层之间的桥梁。Editor 层生成的 Manifest 文件会被 Runtime 层读取,作为资源加载的依据。
运行阶段详解:
运行阶段是 YooAsset 的 Runtime 层执行的阶段,包括资源加载、缓存管理、引用计数等步骤。
3.2 Editor 层模块协作
Editor 层的模块按以下流程协作:
- AssetBundleCollector 收集资源:根据用户的 Collector 配置,扫描指定路径,收集需要打包的资源
- BuildMap 构建依赖图:分析资源之间的依赖关系,构建依赖图,分配 Bundle
- AssetBundleBuilder 执行打包:根据 BuildMap 执行实际的 AssetBundle 打包操作
- TaskCreateManifest 生成清单:将构建结果生成 PackageManifest 文件
3.3 Runtime 层模块协作
Runtime 层的模块按以下流程协作:
- YooAssets 初始化:创建 YooAssets 实例,初始化全局环境
- ResourcePackage 初始化:创建 ResourcePackage,加载 Manifest 文件
- ResourceManager 初始化:初始化资源管理器,准备资源加载
- Provider 执行加载:根据请求创建对应的 Provider,执行资源加载
四、核心数据流
4.1 构建数据流
构建数据流描述了资源从收集到打包的完整过程:
构建数据流
资源 → Collector 收集 → BuildMap 构建 → Builder 打包 → Manifest 输出
资源收集阶段:
在资源收集阶段,AssetBundleCollector 扫描用户配置的路径,根据过滤规则收集需要打包的资源。
依赖分析阶段:
在依赖分析阶段,BuildMap 分析资源之间的依赖关系,构建依赖图,并检测循环依赖。
资源打包阶段:
在资源打包阶段,AssetBundleBuilder 根据 BuildMap 执行实际的 AssetBundle 打包操作,生成 Bundle 文件。
清单生成阶段:
在清单生成阶段,TaskCreateManifest 将构建结果生成 PackageManifest 文件,包括所有 Bundle 的信息、依赖关系等。
4.2 加载数据流
加载数据流描述了从资源地址到资源对象的完整过程:
加载数据流
Address → YooAssets 解析 → ResourcePackage 处理 → ResourceManager 处理 → Provider 处理 → 资源返回
地址解析阶段:
在地址解析阶段,YooAssets 接收用户的资源地址请求,并将其转发到对应的 ResourcePackage。
资源包处理阶段:
在资源包处理阶段,ResourcePackage 接收资源地址请求,并查询 Manifest 文件找到对应的 Bundle。
资源管理器处理阶段:
在资源管理器处理阶段,ResourceManager 根据资源地址和 Bundle 信息,创建对应的 Provider。
资源提供者处理阶段:
在资源提供者处理阶段,Provider 执行实际的资源加载操作,从 FileSystem 读取数据并加载资源。
资源返回阶段:
在资源返回阶段,资源对象被返回给调用者,调用者可以使用该资源对象。
4.3 热更新数据流
热更新数据流描述了从版本检查到资源加载的完整过程:
热更新数据流
启动 → 请求 Manifest → 版本对比 → 下载补丁 → 安装资源 → 切换版本
版本检查阶段:
在版本检查阶段,客户端向服务器请求最新的 Manifest 文件,并与本地 Manifest 进行对比。
差异下载阶段:
在差异下载阶段,客户端根据 Manifest 的差异信息,从服务器下载需要更新的资源。
资源安装阶段:
在资源安装阶段,客户端将下载的资源安装到本地,并更新本地的版本信息。
版本切换阶段:
在版本切换阶段,客户端使用最新版本加载资源,完成热更新。
4.4 数据流的关键节点
YooAsset 数据流中有三个关键节点:
Manifest 节点:
Manifest 是 Editor 层和 Runtime 层之间的桥梁。它记录了所有 Bundle 的信息,是 Runtime 层加载资源的依据。
Address 节点:
Address 是 Runtime 层资源定位的核心。通过 Address,开发者可以加载任何资源,而不需要关心资源的位置。
Operation 节点:
Operation 是异步操作的核心抽象。所有异步操作都通过 Operation 进行管理,支持进度查询、回调通知等功能。
五、架构设计原则
5.1 非侵入性
YooAsset 的设计遵循非侵入性原则:
- 不修改 Unity 源码:YooAsset 通过扩展和包装的方式实现功能,不修改 Unity 的源码
- 不改变项目结构:YooAsset 可以无缝集成到现有项目中,不需要改变项目结构
- 即插即用:YooAsset 可以方便地集成和移除
非侵入性的实现方式:
YooAsset 通过定义清晰的接口(如 IFileSystem、IDecryptionServices 等)实现非侵入性。开发者可以实现这些接口来扩展功能,而不需要修改 YooAsset 的源码。
5.2 分层架构
YooAsset 的设计遵循分层架构原则:
- Editor 层和 Runtime 层分离:构建逻辑和运行逻辑分离
- 模块职责清晰:每个模块都有明确的职责,互不干扰
- 通过 Manifest 通信:Editor 层和 Runtime 层通过 Manifest 文件通信
分层架构的优势:
- 清晰的职责划分:每个层都有明确的职责,便于理解和维护
- 独立的测试和优化:可以独立测试和优化每个层
- 灵活的扩展:可以在每个层独立扩展功能
5.3 可扩展性
YooAsset 的设计遵循可扩展性原则:
- 接口抽象:通过 IFileSystem、IDecryptionServices 等接口抽象关键功能
- 子类扩展:通过继承 AsyncOperationBase、ResourceProvider 等基类扩展功能
- 插件化架构:YooAsset 的核心架构是插件化的,支持自定义扩展
可扩展性的应用:
- 自定义文件系统:开发者可以实现 IFileSystem 接口来创建自定义的文件系统
- 自定义解密服务:开发者可以实现 IDecryptionServices 接口来创建自定义的解密服务
- 自定义资源提供者:开发者可以继承 ResourceProvider 来创建自定义的资源提供者
5.4 高性能
YooAsset 的设计遵循高性能原则:
- 异步操作:所有加载操作都是异步的,避免阻塞主线程
- 引用计数:使用引用计数管理资源生命周期,避免内存泄漏
- 对象池:使用对象池减少 GC 压力
- 缓存机制:使用多级缓存提高加载速度
高性能的实现:
- 异步加载:通过 OperationSystem 实现异步加载,避免阻塞主线程
- 引用计数:通过 ResourceManager 实现引用计数管理,确保资源正确释放
- 缓存优化:通过多级缓存机制提高资源加载速度
六、架构演进
6.1 v1.x 架构
YooAsset v1.x 是初版架构,采用了简单的 AssetBundle 封装:
- 简单的 AB 包封装:直接在 AssetBundle 之上进行了简单封装
- 基础的功能支持:支持资源加载和热更新
- 有限的扩展能力:扩展能力有限
v1.x 架构的特点:
v1.x 架构简单易用,但功能有限,扩展能力不足。它主要解决了资源加载和热更新的基本问题,但缺少高级功能。
6.2 v2.x 架构
YooAsset v2.x 引入了 Package/Group/Collector 概念,大幅提升了扩展能力:
- Package/Group/Collector 三级架构:清晰的三级架构,便于管理
- 完善的热更新支持:支持更完善的热更新机制
- IFileSystem 抽象层:引入 IFileSystem 抽象层,支持跨平台
v2.x 架构的特点:
v2.x 架构在 v1.x 的基础上引入了 Package/Group/Collector 概念,使资源管理更加清晰和灵活。同时引入了 IFileSystem 抽象层,支持跨平台文件访问。
6.3 v3.x 架构
YooAsset v3.x 引入了 OperationSystem,是一次重大升级:
- OperationSystem 异步体系:统一的异步操作管理
- 完善的小游戏支持:增加了对小游戏平台的支持
- 增强的调试功能:提供了更强大的调试工具
v3.x 架构的特点:
v3.x 架构在 v2.x 的基础上引入了 OperationSystem,实现了统一的异步操作管理。这大大提高了资源加载的效率和可控性。
6.4 未来演进方向
YooAsset 未来可能的演进方向:
- AI 智能资源管理:利用 AI 技术进行智能资源管理和优化
- 更智能的缓存策略:基于机器学习优化缓存策略
- 云原生的监控工具:提供云原生的监控工具
未来演进的可能性:
随着技术的发展,YooAsset 可能会集成更多先进技术,如 AI、云原生等,为开发者提供更智能、更高效的资源管理解决方案。
小结
本章从架构层面全面解析了 YooAsset 的设计思想,包括:
- 双层系统架构:Editor 层负责构建,Runtime 层负责运行
- 模块协作关系:各个模块协同工作,完成资源管理全流程
- 核心数据流:构建数据流、加载数据流、热更新数据流
- 架构设计原则:非侵入性、分层架构、可扩展性、高性能
- 架构演进:从 v1.x 到 v3.x 的演进历程
理解 YooAsset 的整体架构是深入学习各模块的基础。接下来的章节将分别深入解析 YooAsset 的各个核心模块。
七、架构设计深度解析
YooAsset 的架构设计体现了模块化和分层设计的思想。整个框架可以分为底层基础设施、核心逻辑层和应用接口层三个层次。底层基础设施提供了跨平台的文件操作、加密解密、网络通信和线程调度等基础能力。核心逻辑层实现了资源定位、资源加载、资源缓存和资源更新等核心业务逻辑。应用接口层面向开发者提供了简洁易用的 API 和灵活的扩展点。
架构的分层设计原则
分层设计的核心原则是每一层都只关注自己的职责,通过接口与上下层通信。底层设施层不应该知道上层业务逻辑的存在,核心逻辑层不应该依赖于具体的平台实现,应用接口层不应该直接操作底层设施。这种分层设计带来的好处是每一层都可以独立地测试和优化,更换某一层的实现不会影响其他层。
在编辑模式和运行模式下,YooAsset 采用了不同的实现路径。编辑模式下直接使用 AssetDatabase 加载资源,绕过 AssetBundle 的构建和打包流程。运行模式下通过 AssetBundle 加载资源,完整的资源管理系统全面介入。这种设计让开发者在编辑器中有更高的迭代效率,在运行时保证与最终发布版本一致的行为。
模块间的协作机制
YooAsset 的各个模块通过事件和回调机制进行协作。资源定位模块在完成资源查找后触发资源就绪事件,加载模块监听到事件后开始加载资源。加载模块在加载完成后触发加载完成事件,缓存模块监听到事件后更新缓存状态。这种事件驱动的协作机制降低了模块之间的耦合度。
可扩展性的实现
YooAsset 的可扩展性通过接口和抽象类来实现。IFileSystem 接口允许开发者实现自定义的文件系统。Provider 基类允许开发者实现自定义的资源加载器。Operation 基类允许开发者实现自定义的异步操作。这些扩展点覆盖了文件系统、资源加载和异步操作等关键领域。
八、架构设计深化
资源生命周期体系的完整设计
YooAsset 的资源生命周期体系是框架的核心设计之一。资源从创建到销毁经历了一个完整的生命周期,每一个阶段都有明确的状态和转换规则。理解资源的生命周期对于正确使用框架非常重要。
资源的生命周期包括就绪、加载中、已加载、使用中和已卸载五个状态。就绪状态表示资源可以被加载但尚未开始加载。加载中状态表示资源的加载操作正在进行。已加载状态表示资源已经在内存中等待使用。使用中状态表示资源正被游戏逻辑所引用。已卸载状态表示资源已经释放。
状态之间的转换由框架自动管理。当游戏逻辑请求加载资源时,资源从就绪状态转换为加载中状态。当加载完成后转换为已加载状态。当游戏逻辑获取资源句柄后转换为使用中状态。当游戏逻辑释放资源句柄后回到已加载状态。当引用计数归零时转换为已卸载状态。
编辑器与运行时的协同
YooAsset 的编辑器模块和运行时模块之间有密切的协同关系。编辑器模块负责资源配置和构建,运行时模块负责资源的加载和使用。两个模块之间的数据通过配置文件进行传递。
在编辑器中完成资源分组和构建配置后,构建系统生成运行时需要的资源清单和版本文件。运行时模块读取这些文件进行资源定位和依赖解析。通过配置文件传递信息的设计让编辑器和运行时可以独立开发和测试。
异步操作调度的工程实践
异步操作调度是框架性能的关键影响因素。YooAsset 的 OperationSystem 使用基于优先级的调度策略。高优先级的操作优先执行,低优先级的操作延后执行。
设操作优先级时需要考虑游戏的用户场景。资源加载操作的优先级应该根据资源对当前场景的重要性来设定。关键资源的加载优先级高,非关键资源的加载优先级低。
九、架构深度分析
架构决策的前因后果
YooAsset 的架构设计不是凭空而来的,而是建立在大量实践基础上经过深思熟虑的结果。每一个架构决策都考虑了多个方面的因素。
选择模块化设计的原因是为了让每个模块可以独立开发测试和优化。模块化的设计也降低了新开发者理解框架的门槛。开发者可以根据需要选择关注的模块,而不必了解整个框架的所有细节。
选择接口抽象的原因是为了框架的扩展性。通过抽象接口框架可以在不修改核心代码的情况下支持多种实现。这种设计让 YooAsset 可以适应不同的项目需求。
选择事件驱动的原因是为了降低模块间的耦合。模块之间通过事件进行通信,不直接调用彼此的方法。这种设计让模块可以独立演进而不会影响其他模块。
资源文件的组织方式
资源文件在 YooAsset 中的组织方式对运行时的性能有直接影响。资源文件按照包的形式组织,每个包包含了一组相关的资源。包的概念与 AssetBundle 对应也支持其他的文件格式。
资源的地址是资源的唯一标识。通过地址可以快速定位到资源所在的包和包内的位置。地址的设计需要支持模糊匹配和通配符。在定位时系统从已知的包中查找匹配的资源。
资源加载的优化策略
资源加载的优化可以从多个方面进行。减少加载次数的优化通过合并资源和预加载实现。减少每次加载时间的优化通过压缩和资源分级实现。减少加载对主线程的影响通过异步加载和分帧加载实现。
YooAsset 内置了多种加载优化机制。缓存机制避免了对同一资源的重复加载。预加载机制在空闲时提前加载可能用到的资源。优先级机制确保关键资源优先加载。
第十章 补充知识点
架构设计中的权衡
任何架构设计都充满了权衡。YooAsset 在架构设计中也面临了多个需要权衡的决策。灵活性与易用性之间的权衡让框架既有丰富的扩展点又有简洁的默认配置。性能与通用性之间的权衡让框架在大多数场景下都有良好的性能表现。功能完整性与代码简洁性之间的权衡让框架覆盖了资源管理的全流程。
理解这些权衡有助于开发者在实际项目中做出合理的选择。如果项目对性能有特别高的要求可以选择精简模式。如果项目需要深度定制可以选择扩展模式。
编辑器架构的深度解析
YooAsset 的编辑器架构是框架与 Unity 编辑器交互的桥梁。编辑器模块负责资源配置构建和分析等功能。资源配置界面让开发者可以直观地配置资源分组的规则。构建界面提供了详细的构建参数配置。分析工具帮助开发者检查资源的使用状况。
编辑器与运行时的数据通过配置文件和构建产物进行传递。配置文件包含了资源分组的规则和构建参数。构建产物包括 AssetBundle 文件和资源清单。运行时的代码通过读取这些文件来获取需要的数据。
运行时的核心循环深入分析
YooAsset 运行时的核心循环是框架运行的基础。核心循环驱动的对象是 Operation 操作。操作的生命周期包括创建等待执行和完成。核心循环在每一帧中检查待处理的操作队列,执行可以开始的操作。
操作的调度考虑了优先级和依赖关系。高优先级的操作先执行以保障关键资源的加载。有依赖关系的操作等待依赖操作完成后再开始执行。
十一章 补充知识点
YooAsset 与其他框架的对比
YooAsset 在设计上与一些其他的资源管理框架有相似之处但也有不同。与 Unity Addressables 相比 YooAsset 的架构更加模块化,自定义扩展更加方便。Addressables 与 Unity 编辑器的集成更加紧密,配置文件的可视化编辑功能更强。
与传统的 AssetBundle 方案相比 YooAsset 提供了更高层次的抽象。开发者不需要手动处理资源的分组和依赖关系。YooAsset 在构建时自动分析依赖并分配合适的包。
架构的未来演进
任何框架都在不断演进中。YooAsset 的未来演进方向包括性能的持续优化和生态的持续完善。性能优化方面会进一步减少 GC 分配和提高加载速度。生态完善方面会提供更多的可视化工具和集成方案。
补充说明
资源管理系统的稳定性和效率直接影响到游戏的整体表现。一个设计良好的资源管理系统需要兼顾加载速度和内存效率。在开发过程中持续关注和管理资源的使用状况是保证游戏品质的重要手段。开发团队应该建立资源管理的规范和流程,定期检查和优化资源的使用情况。通过这些措施可以有效提升游戏的性能和用户体验。
735

被折叠的 条评论
为什么被折叠?



