
Unity Addressable Assets 原理深度解析篇章02-原理篇 · 基础阅读时间约 40 分钟前置知识了解 Unity 基本资源加载方式一、引言Addressable Assets System简称 Addressables是 Unity 官方提供的资源管理系统旨在解决 AssetBundle 使用复杂、依赖管理繁琐等问题。理解 Addressables 的工作原理对于掌握 YooAsset 等上层资源管理方案具有重要意义。Addressables 是 Unity 在 2018.1 版本中引入的一个实验性包经过多个版本的迭代已经成为 Unity 推荐的资源管理方案。它基于 AssetBundle 构建但提供了更高级的 API 和更自动化的依赖管理。Addressables 的核心设计理念是可寻址Addressable即为每个资源分配一个唯一的字符串地址开发者可以通过这个地址加载资源而不需要关心资源的具体位置和依赖关系。这种设计大大简化了资源管理的复杂度。Addressables 的设计哲学与 YooAsset 有诸多相似之处两者都采用了可寻址的设计理念但实现方式有所不同。YooAsset 在 Addressables 的基础上进行了改进提供了更灵活的分包策略和更强大的热更新能力。二、Addressables 架构设计2.1 整体架构Addressables 的整体架构可以分为以下几个层次Addressables 架构 ├── API 层 │ ├── AddressableAssetAPI统一的资源加载 API │ ├── AddressableAssetSettings全局配置 │ └── AddressableAssetGroup资源分组管理 ├── 资源分组层 │ ├── Static Group静态分组 │ ├── Dynamic Group动态分组 │ └── Composite Group组合分组 ├── 资源打包层 │ ├── AssetBundle Builder资源打包器 │ ├── Bundle ManifestBundle 清单 │ └── Addressable Asset Entry资源条目 └── 资源加载层 ├── Resource Provider资源提供者 ├── Resource Location Data资源定位数据 └── Async Operation Handle异步操作句柄API 层API 层是 Addressables 与开发者交互的接口提供了统一的资源加载 API。开发者通过Addressables.LoadAssetAsyncT()等方法加载资源而不需要关心资源的具体位置和依赖关系。资源分组层资源分组层负责将资源组织成不同的分组Group每个分组可以独立打包、更新和加载。Addressables 支持静态分组、动态分组和组合分组三种分组方式。资源打包层资源打包层负责将资源打包成 AssetBundle 文件并生成 Bundle Manifest 和 Addressable Asset Entry。Bundle Manifest 记录了所有 Bundle 的依赖关系Addressable Asset Entry 记录了每个资源的地址和位置信息。资源加载层资源加载层负责从 AssetBundle 中加载资源并管理资源的生命周期。Resource Provider 是资源加载的核心组件负责从不同的数据源如 AssetBundle、Resources 目录等加载资源。2.2 Provider 系统详解Provider 是 Addressables 的核心插件化组件每种资源类型都有对应的 ProviderProvider 类型功能适用场景Asset Provider加载 Asset 资源模型、贴图、预制体等Scene Provider加载场景场景资源Atlas Provider加载 Sprite Atlas图集资源Bundle Provider加载 AssetBundle底层 Bundle 文件Provider 系统的设计允许开发者自定义资源加载逻辑。例如可以实现一个自定义的 HTTP Provider 来支持特殊的下载策略。2.3 ResourceManager 工作原理ResourceManager 是 Addressables 的核心管理器它负责资源的加载和卸载引用计数管理缓存管理异步操作调度ResourceManager 使用引用计数来管理资源的生命周期。每次加载资源时引用计数加 1每次调用 Release() 时引用计数减 1。当引用计数为 0 时资源才会被真正卸载。2.4 异步操作体系Addressables 的异步操作体系基于 AsyncOperationHandle 构建AsyncOperationHandle异步操作的句柄用于跟踪操作状态和结果AsyncOperationHandle.Completed操作完成事件AsyncOperationHandle.Status操作状态Succeeded、Failed、WaitingForDependency 等2.5 资源分组机制Addressables 使用分组Group来组织资源每个分组可以独立打包、更新和加载。Addressables 支持以下分组方式分组类型描述优点缺点Static Group静态分组资源在打包时确定打包速度快管理简单不够灵活Dynamic Group动态分组资源在运行时确定灵活支持运行时添加资源打包速度慢Composite Group组合分组由多个子分组组成灵活支持复杂分组策略管理复杂静态分组详解静态分组是 Addressables 最常用的分组方式。在静态分组中所有资源在打包时就已经确定打包完成后不能再添加或移除资源。静态分组的优点是打包速度快管理简单适合大多数项目。动态分组详解动态分组允许在运行时动态添加或移除资源适合需要动态加载资源的项目。动态分组的缺点是打包速度慢管理复杂适合小型项目或原型开发。组合分组详解组合分组由多个子分组组成可以将多个子分组合并为一个逻辑分组。组合分组的优点是灵活支持复杂分组策略缺点是管理复杂适合大型项目。2.6 资源定位机制Addressables 使用资源定位Location机制来管理资源的地址和位置信息。每个资源都有一个唯一的地址Address开发者可以通过这个地址加载资源。资源定位流程资源地址注册在打包时每个资源都会被分配一个唯一的地址资源定位数据生成打包时生成资源定位数据Resource Location Data记录每个资源的地址和位置信息资源定位数据加载在运行时加载资源定位数据资源地址解析通过资源地址解析出资源的位置信息资源加载根据位置信息加载资源资源定位数据详解资源定位数据Resource Location Data是 Addressables 的核心数据结构记录了每个资源的地址和位置信息。资源定位数据包含以下关键信息地址Address资源的唯一地址用于加载资源GUID资源的唯一标识符用于资源引用路径Path资源在 AssetBundle 中的路径Bundle 名称资源所在的 AssetBundle 名称依赖列表资源依赖的其他资源列表三、Addressables 打包原理3.1 打包流程Addressables 的打包流程可以分为以下几个步骤资源分组将资源组织成不同的分组Group依赖分析分析资源之间的依赖关系资源打包将每个分组打包成 AssetBundle 文件清单生成生成 Bundle Manifest 和 Addressable Asset Entry资源定位数据生成生成资源定位数据3.2 依赖分析Addressables 的依赖分析与 AssetBundle 类似但更加自动化。Addressables 会自动分析资源之间的依赖关系并生成依赖图。依赖分析流程资源扫描扫描每个分组中的所有资源依赖提取提取每个资源的直接依赖依赖图构建将资源之间的依赖关系构建为有向图循环依赖检测检测依赖图中是否存在循环依赖共享资源提取识别被多个分组共享的资源提取为独立 Bundle依赖分析的关键点自动依赖分析Addressables 自动分析资源之间的依赖关系不需要手动配置共享资源处理Addressables 自动处理共享资源避免资源重复循环依赖检测Addressables 自动检测循环依赖并抛出错误3.3 打包策略Addressables 支持多种打包策略开发者可以根据需求选择合适的策略打包策略描述优点缺点单独打包每个资源单独打包成一个 AB 文件粒度细更新灵活AB 文件数量多管理复杂分组打包每个分组打包成一个 AB 文件粒度适中管理简单更新不够灵活类型打包同一类型的资源打包成一个 AB 文件便于类型管理可能导致资源冗余四、Addressables 加载原理4.1 加载流程Addressables 的加载流程可以分为以下几个步骤资源定位通过资源地址解析出资源的位置信息依赖加载加载资源依赖的其他资源资源加载从 AssetBundle 中加载指定的资源资源返回将加载的资源返回给开发者4.2 加载 APIAddressables 提供了多种加载 API// 异步加载单个资源 var handle Addressables.LoadAssetAsyncGameObject(MyPrefab); handle.Completed (op) { GameObject prefab op.Result; Instantiate(prefab); }; // 异步加载多个资源 var handles Addressables.LoadAssetsAsyncGameObject(MyPrefab, null); handles.Completed (op) { foreach (var prefab in op.Result) { Instantiate(prefab); } }; // 异步加载场景 var sceneHandle Addressables.LoadSceneAsync(MyScene); sceneHandle.Completed (op) { if (op.Status AsyncOperationStatus.Succeeded) { Debug.Log(场景加载成功); } };API 详解LoadAssetAsyncT()异步加载单个资源LoadAssetsAsyncT()异步加载多个资源LoadSceneAsync()异步加载场景InstantiateAsync()异步实例化资源UnloadAsync()异步卸载资源4.3 异步操作句柄Addressables 使用异步操作句柄Async Operation Handle来管理异步操作的生命周期。每个异步操作都会返回一个句柄开发者可以通过句柄来管理异步操作。异步操作句柄的关键方法Completed异步操作完成时的回调Result异步操作的结果Status异步操作的状态WaitForCompletion()等待异步操作完成同步阻塞Release()释放异步操作句柄五、Addressables 内存管理5.1 引用计数机制Addressables 使用引用计数机制来管理资源的生命周期。每次调用LoadAssetAsyncT()时引用计数加 1。每次调用Release()时引用计数减 1。当引用计数为 0 时资源会被自动卸载。引用计数机制的注意事项引用计数不会自动减少如果资源被其他对象引用引用计数不会自动减少需要手动释放句柄开发者需要手动调用Release()释放句柄使用 using 语句建议使用 using 语句自动释放句柄5.2 内存优化技巧资源共享// 多个地方共享同一个资源 var handle1 Addressables.LoadAssetAsyncGameObject(MyPrefab); var handle2 Addressables.LoadAssetAsyncGameObject(MyPrefab); // handle1 和 handle2 共享同一个资源对象资源池// 使用对象池管理频繁创建和销毁的资源 public class ResourcePoolT where T : Object { private QueueT _pool new QueueT(); public T Get() { if (_pool.Count 0) return _pool.Dequeue(); return null; } public void Put(T obj) { _pool.Enqueue(obj); } }5.3 缓存机制Addressables 内建了资源缓存系统内存缓存已加载的资源对象缓存在内存中磁盘缓存从网络下载的资源缓存在磁盘上缓存策略支持自定义缓存过期策略六、Addressables 与 AssetBundle 的对比特性AssetBundleAddressables依赖管理手动管理自动管理资源定位通过 Bundle 名称和资源名称通过唯一地址加载 API复杂需要手动处理依赖简单统一 API内存管理手动管理引用计数自动管理引用计数热更新需要手动实现内置支持学习曲线陡峭平缓灵活性高中性能高中有额外开销七、总结Addressables 是 Unity 官方提供的资源管理系统基于 AssetBundle 构建但提供了更高级的 API 和更自动化的依赖管理。理解 Addressables 的工作原理对于掌握 YooAsset 等上层资源管理方案具有重要意义。在实际项目中建议合理选择分组策略根据项目需求选择合适的分组策略优化依赖关系避免循环依赖减少依赖层级及时释放句柄在合适的时机释放异步操作句柄监控内存使用使用 Profiler 等工具监控内存使用情况使用异步加载避免阻塞主线程提升用户体验通过深入理解 Addressables 的原理我们可以更好地利用 Unity 的资源管理功能开发出性能更优、体验更好的游戏。下一篇资源打包流程详解九、原理篇补充知识资源依赖管理的深层原理资源依赖管理是资源管理系统中最复杂的部分之一。当游戏加载一个资源时这个资源可能依赖于其他资源而其他资源又可能依赖于更多的资源。这种依赖关系构成了一张有向无环图。资源管理系统需要能够解析这张图确定正确的加载顺序并且在依赖资源还未加载完成时正确处理加载请求。依赖管理的基本原理是引用追踪。每个资源在构建时会被分析其引用关系这些关系被序列化为依赖数据。在运行时通过依赖数据确定资源的加载顺序。当加载一个资源时先加载它的所有依赖所有的依赖都加载完成后再加载它自己。这种递归的依赖加载机制确保了资源在加载完成时处于完整可用的状态。资源对象的生命周期管理资源对象从创建到销毁经历了完整的生命周期。生命周期管理的关键在于确定何时加载资源和何时卸载资源。过早加载会浪费内存过晚加载会导致卡顿。过早卸载会导致资源被频繁地加载和卸载过晚卸载会导致内存浪费。引用计数是解决生命周期问题的基础机制。每个资源对象维护一个引用计数器。当资源被加载时引用计数设置初始值当其他系统获取资源引用时计数加一当其他系统释放资源引用时计数减一。当引用计数降为零时资源可以被安全地卸载。AssetBundle 的底层文件格式Unity AssetBundle 使用了一种特定的文件格式来存储资源数据。这个格式包含了文件头和数据块两部分。文件头包含了文件的基本信息包括文件大小、压缩方式和资源列表。数据块包含了实际的资源数据可以是压缩的也可以是未压缩的。AssetBundle 文件头的结构包括一个魔数标识文件。格式版本号指示使用的序列化版本。文件大小记录了整个文件的大小。压缩方式指示了数据块使用的压缩算法。资源列表包含了包内所有资源的路径和偏移量。异步加载的实现机制Unity 的资源加载接口设计为异步方式。异步加载的实现依赖于 Unity 的 PlayerLoop 系统。资源加载请求被提交后立即返回 AsyncOperation 对象主循环在后续帧中检查加载进度。当加载完成时触发完成回调通知调用者。十、原理篇补充材料资源加载的核心路径理解资源加载的核心路径有助于在遇到问题时进行排查。资源加载路径包括资源定位、依赖解析、数据读取、对象实例化和资源激活等步骤。每一步都可能成为性能瓶颈。资源定位是资源加载的第一步。资源系统根据资源的地址和类型信息找到对应的资源文件。资源定位的效率直接影响首次加载的速度。YooAsset 通过资源索引表加速资源定位将资源地址到文件路径的映射预计算并缓存。依赖解析是资源加载中最复杂的步骤。资源系统分析资源的依赖关系确定需要加载的所有文件和加载的顺序。YooAsset 的依赖图在构建时生成并在运行时按需解析。数据读取后需要经过对象实例化和资源激活才能被游戏所使用。对象实例化是从资源数据创建游戏对象的过程。资源激活是调用资源上的初始化方法的步骤。内存管理的核心机制资源管理系统通过多种机制协同工作来管理内存。引用计数是最基本的机制跟踪资源的使用情况。缓存管理机制决定资源在内存中保留的时间。生命周期管理机制控制资源的创建和销毁。垃圾回收是 Unity 引擎提供的自动内存管理机制。它在回收不再使用的对象时会引起 GC 停顿。减少 GC 分配是性能优化的重要方向。资源更新的技术细节热更新是网络游戏的核心需求之一。热更新的实现依赖版本管理、差异对比和安全校验等技术。版本管理确保客户端和服务器使用一致的资源版本。差异对比减少了不必要的数据传输。安全校验确保下载的资源是完整的和未被篡改的。增量更新只下载变化的部分是最常用的更新方式。断点续传在网络不稳定的环境中提高更新的成功率。并发下载利用带宽资源缩短更新等待的时间。十一、关键技术原理补充AssetBundle 格式的深入理解AssetBundle 的文件格式可以分为几个关键部分。文件头包含了包的元数据信息。数据段包含了实际的资源数据。可选的信息段包含了额外的元数据。理解这些结构对于排查加载问题和优化性能非常有帮助。文件头的结构包括魔数字段用于标识文件类型。文件版本字段用于兼容性检查。数据偏移字段指示数据段的起始位置。资源列表字段包含了包内所有资源的路径和索引。数据段的组织方式取决于使用的压缩方式。未压缩的数据段直接包含了资源文件的序列化数据。LZ4 压缩的数据段按块压缩解压时按需解压特定的块。LZMA 压缩的数据段按流压缩解压速度较慢但压缩率更高。资源哈希与版本管理资源哈希是确定资源唯一性的重要手段。哈希值是根据文件内容计算得出的固定长度字符串。相同内容的文件会产生相同的哈希值。通过比较哈希值可以判断文件是否有变化。在版本管理中使用哈希值进行增量更新。服务器端计算每个资源包的哈希值。客户端下载版本文件后与本地缓存对比。哈希值不同的资源包就是需要更新的包。这种方法可以精确地确定需要更新的资源。异步编程模型在资源管理中的应用Unity 的资源加载大量使用了异步编程模型。异步操作的核心是不阻塞主线程。资源数据在后台线程中读取读取完成后通知主线程进行对象创建。协程是 Unity 中实现异步操作的传统方式。通过 yield return 语句将操作分发到多个帧执行。Task 是 .NET 提供的异步编程模型。在 Unity 中通过 async await 关键字使用。资源缓存的设计要点资源缓存的设计需要在命中率和内存占用之间取得平衡。缓存空间有限需要决定哪些资源应该保留哪些资源应该淘汰。访问频率是决定淘汰策略的重要因素。最近最少使用的资源优先被淘汰。缓存大小的设置直接影响缓存的效率。缓存空间过大会占用过多内存。缓存空间过小会导致频繁的缓存缺失增加加载次数。建议根据设备的内存大小和游戏的需求动态调整缓存大小。十二章 补充知识点资源加载的详细流程资源加载的详细流程涉及多个步骤的协作。当游戏代码调用资源加载接口时资源系统接收请求。第一步解析资源地址确定资源所属的资源包。第二步检查资源缓存看资源是否已经加载。第三步如果需要加载则创建加载任务并提交到队列。第四步加载任务执行从存储介质读取数据。第五步数据读取完成后进行解密和解压。第六步将原始数据转换为 Unity 可识别的资源对象。第七步检查资源的依赖是否已经加载完成。第八步触发加载完成回调通知调用者。每一步都可能出现异常需要相应的错误处理。地址解析失败可能返回无效地址错误。资源包不存在可能返回文件未找到错误。数据读取失败可能返回 IO 错误。解密失败可能返回密钥错误。资源对象创建失败可能返回内存不足错误。资源加载的性能分析资源加载的性能受到多个因素的影响。资源的数量影响总加载时间。资源包的数量影响加载请求的次数。资源包的大小影响单次加载的时间。资源的依赖关系影响加载的复杂度。使用 Unity Profiler 可以分析资源加载中的性能瓶颈。查看每个加载操作的时间消耗。查看加载过程中的 GC 分配。查看资源的加载顺序和依赖关系。根据 Profiler 的数据进行有针对性优化。十三章 补充知识点AssetBundle 的兼容性AssetBundle 在不同版本的 Unity 之间存在兼容性问题。高版本 Unity 构建的 AssetBundle 可能无法在低版本 Unity 中加载。低版本 Unity 构建的 AssetBundle 可以在高版本 Unity 中加载。在项目中应该统一使用相同版本的 Unity 构建资源。AssetBundle 在不同平台之间也不兼容。为 iOS 平台构建的 AssetBundle 不能在 Android 平台使用。在发布时应该为目标平台分别构建资源包。构建工具的版本也要保持一致。资源管理的自动化实践自动化是提高资源管理效率的重要手段。自动构建可以在每次代码提交后自动执行资源构建。自动测试可以在构建通过后自动运行测试用例。自动部署可以将构建产物自动部署到测试环境。自动化的实现依赖于脚本和工具链。使用命令行工具可以集成到 CI 流程中。使用构建脚本可以保证构建过程的重复性。使用测试脚本可以自动验证构建结果的正确性。补充说明资源管理系统的稳定性和效率直接影响到游戏的整体表现。一个设计良好的资源管理系统需要兼顾加载速度和内存效率。在开发过程中持续关注和管理资源的使用状况是保证游戏品质的重要手段。开发团队应该建立资源管理的规范和流程定期检查和优化资源的使用情况。通过这些措施可以有效提升游戏的性能和用户体验。