Unity异步加载框架：Addressables与UniTask的工程实践-拓冰建站

1. 项目概述：当异步加载遇上现代Unity开发

在Unity游戏开发中，资源加载是个老生常谈却又常谈常新的问题。从早期的Resources.Load，到后来的AssetBundle，再到如今官方主推的Addressables可寻址资源系统，我们一直在寻找一种既能高效管理内存，又能让代码保持清晰优雅的加载方案。我最近在一个中型体量的3D手游项目中，深度整合了Addressables与UniTask，目标很明确：彻底告别由传统回调或协程引发的“回调地狱”，并实现对内存生命周期的精细化控制。这套组合拳打下来，不仅加载流程变得丝滑，内存曲线也平稳得让人感动。如果你也受够了在层层回调中迷失，或是为神秘的内存泄漏而头疼，那么这次关于“Addressables + UniTask”的实践分享，或许能给你带来一些直接的参考。

简单来说，这个框架的核心价值在于“可控”与“可读”。Addressables提供了资源生命周期管理的基石，而UniTask则为我们提供了编写异步代码的现代化“语言”。两者结合，让我们能用近乎同步的思维去写异步逻辑，同时牢牢掌握每一份资源从加载、使用到释放的全过程。这不仅仅是换两个API那么简单，它涉及到项目架构思路的转变。

2. 核心痛点解析：为什么我们需要这套组合？

在深入技术细节之前，我们得先搞清楚要解决什么问题。传统资源管理方式，尤其是在异步加载场景下，通常伴随着两大顽疾：混乱的内存管理和糟糕的代码可维护性。

2.1 内存管理之殇：泄漏与冗余

使用AssetBundle时，我们必须手动管理Load、Unload的时机。一个常见的陷阱是：你加载了一个Prefab，实例化后，以为删除了GameObject就万事大吉，却忘了去卸载对应的AssetBundle，导致资源一直留在内存中。这就是内存泄漏。反之，如果过早地调用了AssetBundle.Unload(true)，又可能导致场景中正在使用的资源变成“Missing”，引发粉色材质或模型丢失。

Addressables通过引用计数机制优雅地解决了这个问题。它为每个资源维护一个引用计数，Load时增加，Release时减少。当计数归零，系统会在合适的时机（并非立即）卸载资源。这大大降低了手动管理的内存风险。但是，如果使用不当，比如加载后忘了释放，或者释放的时机不对，同样会造成问题。我们的框架需要建立在正确理解和使用这套引用计数机制之上。

2.2 回调地狱与协程的局限

过去，我们可能用回调函数来处理异步加载：

LoadAssetAsync(“prefabName”, (GameObject prefab) => { Instantiate(prefab, (GameObject instance) => { instance.GetComponent<SomeComponent>().Init(() => { // 更多嵌套回调... }); }); });

或者使用Unity的协程（Coroutine）配合yield return：

IEnumerator LoadCoroutine() { var request = Resources.LoadAsync<GameObject>(“prefab”); yield return request; GameObject obj = Instantiate(request.asset as GameObject); // 等待某个条件 yield return new WaitForSeconds(1); // 更多yield... }

回调嵌套降低了代码可读性，错误处理也变得复杂。协程虽然改善了流程，但它依赖于MonoBehaviour和Unity的生命周期，无法方便地返回值，错误传播也不直观，而且在非GameObject环境（如纯C#类）中使用不便。更重要的是，它们都难以与Addressables的AsyncOperationHandle这类现代异步操作完美、简洁地结合。

UniTask的出现，为C#带来了近乎原生的async/await支持。它轻量、高效，且能无缝对接Unity的各种异步操作和Addressables的加载接口。我们可以这样写：

public async UniTask<GameObject> LoadAndInstantiatePrefab(string address) { // 加载资源 var handle = Addressables.LoadAssetAsync<GameObject>(address); GameObject prefab = await handle.Task.AsUniTask(); // 实例化 GameObject instance = Instantiate(prefab); // 记录handle，用于后续释放 _loadedHandles.Add(handle); return instance; }

代码是顺序执行的，逻辑一目了然。这就是我们要解决“回调地狱”的利器。

3. 框架整体设计与核心思路

我们的目标不是简单地替换几个加载函数，而是构建一个清晰、健壮、易于使用的资源加载层。整体设计围绕以下几个核心原则展开：

单一职责：加载模块只负责资源的加载、缓存和释放，不关心具体的业务逻辑。
生命周期绑定：资源的释放最好能与其使用者的生命周期自动关联，减少手动管理。
异常安全：任何加载步骤都可能失败，框架必须提供统一的错误处理机制。
性能可观测：需要提供工具或接口，方便监控当前加载状态和内存占用。

基于此，我设计了一个以“加载器(Loader) + 句柄缓存池(Handle Pool)”为核心的轻量级框架。其核心工作流程如下：

业务层（如UI界面、场景控制器）向资源管理器发起加载请求。
资源管理器内部使用Addressables API进行异步加载，并立即返回一个UniTask<T>给业务层。
加载过程中产生的AsyncOperationHandle被存入一个句柄缓存字典，Key通常为资源的地址或自定义ID。
业务层await这个UniTask，获得资源实例，并进行使用。
当资源不再需要时（如界面关闭、场景切换），业务层通知资源管理器释放对应资源。管理器减少引用计数，并在适当时机触发Addressables的底层释放。

这个设计的巧妙之处在于，通过UniTask，我们将异步的AsyncOperationHandle转换成了可以await的、可返回值的任务，业务逻辑得以线性展开。同时，集中管理AsyncOperationHandle，确保了每个加载出去的资源都能被追踪和释放。

注意：这里没有采用“每个资源一个GameObject引用”的简单字典缓存，因为Addressables自己已有内存缓存。我们的“缓存”更多是管理AsyncOperationHandle，确保在游戏会话期间，对同一地址的重复加载能快速返回已加载的内容，并协调释放时机。

4. 核心模块实现详解

接下来，我们拆解框架中的几个关键模块，看看代码具体如何实现。

4.1 UniTask与Addressables的桥接

这是整个框架的基石。Addressables的加载方法返回的是AsyncOperationHandle<T>，我们需要将其转换为UniTask<T>。UniTask已经为我们提供了非常方便的扩展方法。

最基本的使用方式如下：

using Cysharp.Threading.Tasks; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class SimpleLoader { public async UniTask<GameObject> LoadAssetAsync(string address) { AsyncOperationHandle<GameObject> handle = Addressables.LoadAssetAsync<GameObject>(address); GameObject asset = await handle.Task.AsUniTask(); // 重要：这里我们暂时持有handle，但还未管理其释放。 return asset; } }

但这还不够。我们需要考虑加载取消、超时和进度报告。一个更健壮的版本如下：

public async UniTask<GameObject> LoadAssetAsync(string address, CancellationToken cancellationToken = default) { AsyncOperationHandle<GameObject> handle = Addressables.LoadAssetAsync<GameObject>(address); try { // 支持取消操作 GameObject asset = await handle.Task.AsUniTask().AttachExternalCancellation(cancellationToken); // 也可以获取加载进度（0~1） // float progress = handle.PercentComplete; return asset; } catch (OperationCanceledException) { // 如果任务被取消，必须释放已创建的handle，否则会内存泄漏 Addressables.Release(handle); throw; // 将取消异常重新抛出 } catch (Exception e) { // 其他异常，同样需要释放handle Addressables.Release(handle); Debug.LogError($“加载资源失败: {address}, Error: {e.Message}”); throw; } // 注意：正常完成情况下，handle由谁释放？这是下一个模块要解决的问题。 }

这里引入了CancellationToken，这对于移动端游戏尤其重要。例如，玩家快速切换界面时，上一个界面尚未加载完的资源应该被取消，以节省带宽和CPU。

4.2 资源管理器与句柄生命周期管理

让每个调用者都去记住释放handle是不现实的。我们需要一个中心化的管理器来负责跟踪和释放。我实现了一个ResourceManager，其核心是一个字典，用来关联资源地址和其对应的AsyncOperationHandle（或一个包装类）。

using System.Collections.Generic; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class ResourceManager : MonoBehaviour { private static ResourceManager _instance; public static ResourceManager Instance => _instance; // 使用字典记录活跃的handle。Key为资源地址，Value为Handle的包装，包含引用计数。 private Dictionary<string, AssetHandleWrapper> _assetHandleMap = new Dictionary<string, AssetHandleWrapper>(); private class AssetHandleWrapper { public AsyncOperationHandle Handle; public int RefCount = 1; // 加载成功即有一次引用 public AssetHandleWrapper(AsyncOperationHandle handle) { Handle = handle; } } void Awake() { if (_instance == null) { _instance = this; DontDestroyOnLoad(gameObject); } else { Destroy(gameObject); } } public async UniTask<T> LoadAssetAsync<T>(string address, CancellationToken cancellationToken = default) where T : class { if (_assetHandleMap.TryGetValue(address, out var wrapper)) { // 已加载过，增加引用计数并直接返回结果 wrapper.RefCount++; return wrapper.Handle.Result as T; } // 首次加载 AsyncOperationHandle<T> handle = Addressables.LoadAssetAsync<T>(address); _assetHandleMap[address] = new AssetHandleWrapper(handle); try { T asset = await handle.Task.AsUniTask().AttachExternalCancellation(cancellationToken); return asset; } catch (Exception e) { // 加载失败，从字典中移除并释放handle _assetHandleMap.Remove(address); Addressables.Release(handle); Debug.LogError($“资源加载失败: {address}”); throw; } } public void ReleaseAsset(string address) { if (_assetHandleMap.TryGetValue(address, out var wrapper)) { wrapper.RefCount--; if (wrapper.RefCount <= 0) { // 引用计数归零，释放资源并从字典移除 Addressables.Release(wrapper.Handle); _assetHandleMap.Remove(address); Debug.Log($“资源已释放: {address}”); } } else { Debug.LogWarning($“尝试释放未加载或已释放的资源: {address}”); } } // 场景切换时，可以批量释放所有非持久化资源 public void ReleaseAll() { var keysToRelease = new List<string>(_assetHandleMap.Keys); foreach (var key in keysToRelease) { // 这里假设所有资源都可以释放。实际项目中可能需要标记“常驻”资源。 Addressables.Release(_assetHandleMap[key].Handle); } _assetHandleMap.Clear(); } }

这个管理器提供了引用计数功能。同一个资源被多个地方请求时，只会真正加载一次，每多一个请求者就增加一次引用计数。每个请求者在用完资源后调用ReleaseAsset，当最后一个请求者释放时，资源才会被真正卸载。

实操心得：引用计数的增减最好与游戏对象的生命周期绑定。例如，可以为UI界面或场景控制器创建一个基类，在OnEnable中加载所需资源，在OnDisable或OnDestroy中释放。这样可以极大降低手动管理的心智负担。

4.3 加载策略与依赖处理

Addressables的强大之处在于它能自动处理资源之间的依赖。比如，一个Prefab引用了一个Material，而这个Material又引用了一张Texture。当你加载这个Prefab时，Addressables会自动加载所有依赖链上的资源。我们的管理器也需要适应这一点。

当我们调用Addressables.LoadAssetAsync加载一个主资源时，其依赖项会被Addressables内部管理。释放主资源的handle时，如果依赖项没有其他引用，也会被一并释放。这意味着，在我们的ResourceManager中，我们通常只需要管理顶层资源的handle。

但是，有些场景需要更细粒度的控制。例如，我们想预加载一个角色模型的所有纹理到内存中，以加快切换速度。这时，我们可以直接加载依赖资源：

// 假设我们知道角色纹理的标签是 “CharacterTextures” public async UniTask PreloadDependenciesByLabel(string label) { // 使用LoadResourceLocationsAsync先获取所有资源位置 var locationsHandle = Addressables.LoadResourceLocationsAsync(label, typeof(Texture2D)); var locations = await locationsHandle.Task.AsUniTask(); Addressables.Release(locationsHandle); // 这个handle可以立即释放 List<UniTask> loadTasks = new List<UniTask>(); foreach (var location in locations) { // 并发加载所有纹理 var loadTask = LoadAssetAsync<Texture2D>(location.PrimaryKey); loadTasks.Add(loadTask); } await UniTask.WhenAll(loadTasks); Debug.Log($“预加载了{locations.Count}个纹理资源。”); }

对于场景加载，Addressables提供了LoadSceneAsync，它返回的是AsyncOperationHandle<SceneInstance>。场景加载比较特殊，通常使用单次加载和释放模式，不适合用引用计数。我们可以为其单独封装：

public async UniTask<SceneInstance> LoadSceneAsync(string sceneAddress, LoadSceneMode loadMode = LoadSceneMode.Single, bool activateOnLoad = true) { var handle = Addressables.LoadSceneAsync(sceneAddress, loadMode, activateOnLoad); SceneInstance sceneInstance = await handle.Task.AsUniTask(); // 场景的handle通常由场景卸载时释放，这里可以存入另一个专门管理场景的字典 _sceneHandles[sceneAddress] = handle; return sceneInstance; } public async UniTask UnloadSceneAsync(string sceneAddress) { if (_sceneHandles.TryGetValue(sceneAddress, out var handle)) { await Addressables.UnloadSceneAsync(handle).Task.AsUniTask(); _sceneHandles.Remove(sceneAddress); } }

5. 实战：一个完整的UI界面资源加载示例

让我们看一个完整的例子，假设有一个“英雄详情”界面，需要异步加载英雄头像、模型和技能图标。

using Cysharp.Threading.Tasks; using UnityEngine; using UnityEngine.UI; public class HeroDetailUI : MonoBehaviour { [SerializeField] private Image _heroAvatarImage; [SerializeField] private Transform _heroModelContainer; [SerializeField] private Image[] _skillIconImages; private GameObject _loadedHeroModel; // 加载的英雄模型实例 private string _heroAssetAddress; // 英雄Prefab的地址 private string _avatarSpriteAddress; // 头像Sprite的地址 private string[] _skillIconAddresses; // 技能图标地址数组 private CancellationTokenSource _cancellationTokenSource; void OnEnable() { _cancellationTokenSource = new CancellationTokenSource(); InitializeAsync(_cancellationTokenSource.Token).Forget(); // Forget()用于触发并“忘记”这个Task，由自己管理生命周期 } void OnDisable() { // 界面禁用时，取消所有正在进行的加载任务 _cancellationTokenSource?.Cancel(); _cancellationTokenSource?.Dispose(); _cancellationTokenSource = null; // 释放加载的资源 CleanupResources(); } private async UniTaskVoid InitializeAsync(CancellationToken ct) { // 1. 并发加载静态资源（头像和技能图标） var loadAvatarTask = ResourceManager.Instance.LoadAssetAsync<Sprite>(_avatarSpriteAddress, ct); var loadSkillIconsTasks = new List<UniTask<Sprite>>(); foreach (var address in _skillIconAddresses) { loadSkillIconsTasks.Add(ResourceManager.Instance.LoadAssetAsync<Sprite>(address, ct)); } try { // 等待所有静态资源加载完成 Sprite avatarSprite = await loadAvatarTask; Sprite[] skillSprites = await UniTask.WhenAll(loadSkillIconsTasks); // 2. 更新UI（注意：需在主线程） _heroAvatarImage.sprite = avatarSprite; for (int i = 0; i < _skillIconImages.Length && i < skillSprites.Length; i++) { _skillIconImages[i].sprite = skillSprites[i]; } // 3. 加载并实例化英雄模型（动态资源） GameObject heroPrefab = await ResourceManager.Instance.LoadAssetAsync<GameObject>(_heroAssetAddress, ct); _loadedHeroModel = Instantiate(heroPrefab, _heroModelContainer); // 可以对模型进行一些初始化设置... _loadedHeroModel.transform.localPosition = Vector3.zero; } catch (OperationCanceledException) { // 加载被取消（比如界面快速切换），安静退出即可 Debug.Log(“HeroDetailUI 加载被取消。”); } catch (Exception e) { // 其他加载错误 Debug.LogError($“HeroDetailUI 初始化失败: {e.Message}”); // 这里可以显示一个错误提示UI } } private void CleanupResources() { // 销毁模型实例 if (_loadedHeroModel != null) { Destroy(_loadedHeroModel); _loadedHeroModel = null; } // 通知ResourceManager释放资源 ResourceManager.Instance.ReleaseAsset(_avatarSpriteAddress); foreach (var address in _skillIconAddresses) { ResourceManager.Instance.ReleaseAsset(address); } ResourceManager.Instance.ReleaseAsset(_heroAssetAddress); } // 外部调用，设置要显示的英雄ID public void SetHero(string heroId) { // 根据heroId配置资源地址 _heroAssetAddress = $“HeroPrefabs/{heroId}”; _avatarSpriteAddress = $“HeroAvatars/{heroId}”; _skillIconAddresses = new string[] { … }; // 从配置读取 // 如果界面已激活，可以在这里触发重新加载 } }

这个示例清晰地展示了如何利用UniTask的async/await语法，将原本需要嵌套回调的并发加载逻辑，写成清晰、线性的代码。通过CancellationToken，我们实现了加载过程的可取消性，这对移动端用户体验至关重要。资源释放与OnDisable生命周期绑定，基本实现了自动化管理。

6. 性能优化与内存调试技巧

一套好的框架不仅要功能正确，还要性能可控。以下是一些在项目实践中总结的优化和调试技巧。

6.1 监控与日志

给ResourceManager添加监控功能，便于在开发阶段和日志中观察资源加载情况。

public class ResourceManager : MonoBehaviour { // … 其他代码 … public void LogCurrentResourceStatus() { Debug.Log($“=== 当前资源状态 ===”); Debug.Log($“活跃资源数量: {_assetHandleMap.Count}”); long totalMemory = 0; foreach (var kvp in _assetHandleMap) { var handle = kvp.Value.Handle; if (handle.IsValid() && handle.Result != null) { // 估算内存，对于Texture、Mesh等可以获取更准确的大小 // 这里只是一个简单示例，实际项目可能需要更复杂的估算 if (handle.Result is Texture2D tex) { totalMemory += tex.width * tex.height * 4; // 近似估算 } Debug.Log($“ [{kvp.Key}] Ref: {kvp.Value.RefCount}, Type: {handle.Result.GetType().Name}”); } } Debug.Log($“预估占用内存: {totalMemory / (1024 * 1024):F2} MB”); Debug.Log($“===================”); } }

可以在游戏的关键节点（如场景切换前后）调用这个日志方法，监控内存变化。

6.2 利用Addressables Profiler

Unity Profiler中集成了Addressables模块，这是最强大的调试工具。你需要通过Package Manager安装“Addressables Profiler”模块。启用后，你可以在Profiler中看到：

资源引用图：清晰展示哪个资源被谁引用，以及其依赖关系。
缓存状态：查看本地和远程资源的缓存情况。
事件流：实时显示加载、释放等事件。
内存详情：精确查看每个Addressable资源在内存中的占用。

注意事项：Addressables的释放（Release）不是立即的。它通常会将资源标记为“未使用”，真正的卸载可能延迟到几帧之后，或者由垃圾收集器触发。在Profiler中观察内存下降会有延迟，这是正常现象，不要误以为是内存泄漏。

6.3 预加载与懒加载策略

预加载：对于进入核心玩法前必须的资源（如主UI、常用音效），在加载界面使用ResourceManager进行预加载。可以使用UniTask.WhenAll并发加载以缩短时间。
懒加载：对于不确定是否会用到的资源（如某个支线任务的特殊道具图标），等到真正需要时再加载。我们的框架完美支持这一点。
分帧加载：如果单帧内需要加载大量小资源（如一堆配置表或图标），可能会造成卡顿。可以使用UniTask.DelayFrame或分批加载来将压力分摊到多帧。

public async UniTask LoadAssetsInBatches(List<string> addresses, int batchSize = 5) { for (int i = 0; i < addresses.Count; i += batchSize) { var batch = addresses.Skip(i).Take(batchSize).ToList(); var tasks = batch.Select(addr => ResourceManager.Instance.LoadAssetAsync<object>(addr)); await UniTask.WhenAll(tasks); // 每加载完一批，等待一帧，避免主线程阻塞 await UniTask.Yield(); } }

6.4 处理异常与超时

网络加载或本地IO可能出错。为关键加载操作添加超时和重试机制是生产环境必备。

public async UniTask<T> LoadAssetWithRetry<T>(string address, int maxRetryCount = 2, int timeoutMilliseconds = 8000, CancellationToken ct = default) where T : class { int retryCount = 0; while (retryCount <= maxRetryCount) { CancellationTokenSource timeoutCts = new CancellationTokenSource(); CancellationTokenSource linkedCts = CancellationTokenSource.CreateLinkedTokenSource(ct, timeoutCts.Token); try { // 创建一个带超时的任务 var loadTask = ResourceManager.Instance.LoadAssetAsync<T>(address, linkedCts.Token); var timeoutTask = UniTask.Delay(timeoutMilliseconds, cancellationToken: ct).SuppressCancellationThrow(); var (isCanceled, result) = await UniTask.WhenAny(loadTask, timeoutTask); if (isCanceled) { // 超时任务先完成 throw new TimeoutException($“加载资源超时: {address}”); } else { // 加载任务先完成 return result; } } catch (TimeoutException) { Debug.LogWarning($“加载超时，开始第{retryCount + 1}次重试: {address}”); retryCount++; if (retryCount > maxRetryCount) throw; await UniTask.Delay(1000 * retryCount, cancellationToken: ct); // 延迟重试 } catch (Exception e) when (e is not OperationCanceledException) { // 其他非取消异常 Debug.LogError($“加载失败: {address}, Error: {e.Message}”); throw; } finally { timeoutCts?.Dispose(); } } throw new InvalidOperationException(“不应执行到此”); }

7. 常见问题与排查实录

在实际集成和使用过程中，我踩过不少坑。这里记录一些典型问题和解决方法。

7.1 问题：资源明明释放了，但内存没有下降？

排查：
1. 首先确认是否调用了ResourceManager.ReleaseAsset，并且引用计数确实归零。
2. 打开Addressables Profiler，查看该资源是否还存在于“Loaded Assets”列表中。如果还在，说明仍有其他AsyncOperationHandle引用它。
3. 检查是否有其他地方（比如某个全局管理器、静态变量）直接持有了该资源（如Texture、Material对象），而不是通过Addressables系统加载。这种直接持有会阻止Addressables卸载资源。
4. 记住Addressables的释放是延迟的。多等几帧，或者手动触发一次垃圾收集（Resources.UnloadUnusedAssets，谨慎使用），再看内存变化。
解决：确保资源释放路径唯一，并通过Profiler确认引用关系。避免非Addressables API与Addressables混用管理同一份资源。

7.2 问题：异步加载过程中，游戏对象被销毁了，引发`MissingReferenceException`。

场景：在UI界面发起加载任务后，玩家立刻关闭了界面，OnDisable中取消了CancellationToken并销毁了UI对象。但加载任务可能在取消请求发出后的一小段时间内完成，并试图去设置一个已被销毁的Image组件的sprite。
解决：在await之后，立即检查组件或GameObject是否还有效。

private async UniTaskVoid LoadAvatarAsync(CancellationToken ct) { Sprite avatarSprite = await ResourceManager.Instance.LoadAssetAsync<Sprite>(_avatarAddress, ct); // 关键检查：如果界面已被销毁，则不再执行后续UI更新 if (this == null || !_heroAvatarImage /* 或 gameObject */) { // 立即释放刚加载的资源，因为使用者已不存在 ResourceManager.Instance.ReleaseAsset(_avatarAddress); return; } _heroAvatarImage.sprite = avatarSprite; }

7.3 问题：使用`UniTask`后，编辑器播放模式下偶尔出现“`AddressableException`”或加载卡住。

排查：
1. 检查是否在非主线程尝试实例化GameObject或访问UnityEngine API。UniTask的await默认会在主线程恢复，但某些配置（如PlayerLoopTiming.Update）或手动指定ConfigureAwait可能会改变行为。确保资源加载后的实例化、赋值等操作在正确的上下文中。
2. 在编辑器快速进出播放模式时，Addressables的静态状态可能没有完全重置。这有时会导致奇怪的问题。
解决：
1. 对于必须在主线程执行的操作，使用await UniTask.SwitchToMainThread()进行显式切换。
2. 在编辑器中，遇到诡异问题时，尝试完全停止播放，并清除Addressables的缓存（Window -> Asset Management -> Addressables -> Clean Build），然后重新构建。

7.4 问题：如何管理AssetBundle的依赖和打包策略？

说明：这不是代码框架问题，而是项目设置问题，但直接影响加载效率。
建议：
- 按逻辑分组：将同一场景、同一功能模块的资源打在一个组里。例如，“UI_Login”组包含登录界面的所有资源。
- 共享资源单独分组：将多个模块共用的资源（如通用字体、音效、Shader）放在一个单独的“Shared”组中，并设置为“不可变”（Immutable），这样它会被单独打包且不易重复。
- 利用标签（Labels）：除了地址，可以给资源打上标签，方便进行批量操作，如我们之前提到的预加载示例。
- 远程分发与热更：对于需要热更的资源，将其分组并设置为“远程”（Remote）。框架中的加载代码无需改动，Addressables会自动处理本地与远程的加载源。

7.5 问题：在WebGL平台运行出现跨域问题或加载失败？

排查：WebGL平台对网络请求有严格的限制。如果资源托管在远程服务器，需要确保服务器配置了正确的CORS（跨域资源共享）策略。
解决：
1. 联系服务器管理员，为资源文件（如.bundle文件）的响应头添加Access-Control-Allow-Origin: *。
2. 在Unity构建WebGL时，可以在Addressables分组设置中，为远程组设置合适的“Bundle Mode”（如“Pack Together”可以减少请求数）和“Load Path”（使用相对路径或完整的URL）。
3. 在开发阶段，可以使用本地HTTP服务器（如Python的http.server）来测试，避免文件协议（file://）带来的限制。

这套“Unity Addressables + UniTask”的异步加载框架，经过多个项目的锤炼，已被证明是管理现代Unity项目资源的有效方案。它将开发者从繁琐的手动内存管理和回调嵌套中解放出来，让代码重心回归到游戏逻辑本身。当然，没有银弹，它需要你对Addressables的打包、部署有清晰的认识，并遵循一定的资源管理规范。但一旦搭建起来，其带来的开发效率提升和运行时稳定性，绝对是值得的。