讲到Unity的资源加载很多团队是从Resources目录一路走过来的。Resources.Load写起来简单但包体、内存、热更新这三座大山迟早会压垮它。我真正下决心迁到Addressables是在一个卡了许久的加载流程优化里——当时项目素材越来越多加载逻辑散落在各个界面想统一做优先级、做进度条、做预加载根本无从下手。Addressables的价值不只是换了一套API而是把资源的定位、加载、依赖、释放变成了一套可管理的体系。这篇文章把我在项目里实际用过的所有加载方式做一个汇总单个加载、引用加载、批量加载、实例化加载、场景加载、远程目录加载每一条都带上适用场景和释放细节给正在迁移或刚起步的团队一份可以照着写的参考。1. LoadAssetAsync单个资源加载的三种落地写法1.1 加载前先确认地址和类型很多新手第一句代码就是Addressables.LoadAssetAsyncGameObject(Assets/Prefabs/Enemy.prefab)结果跑起来直接报错。这里最容易被忽略的前提是这个资源必须在Addressables Groups窗口里被标记为Addressable。标记之后默认地址就是它在Assets下的完整路径你可以在Inspector里把它改成任意短字符串比如Enemy。地址确定了还要确定泛型类型。加载Prefab用GameObject加载ScriptableObject用你自定义的SO类型加载图片用Sprite或Texture2D。类型传错会直接失败因为Aseet底层是按照类型去找对应对象的。我的建议是项目中约定好地址命名规则不要一部分人用短地址、一部分人用全路径后面排查问题阶段会省掉大量时间。1.2 回调、await、同步等待怎么选单个资源加载的消费方式有三种我按项目里出现的频率分别说。第一种是Completed回调适合那种加载完就干一件事、不需要继续串联的场景var handle Addressables.LoadAssetAsyncGameObject(Enemy); handle.Completed op { if (op.Status AsyncOperationStatus.Succeeded) { var prefab op.Result; Instantiate(prefab, transform); } else { Debug.LogError($加载失败: {op.OperationException}); } };第二种是我个人用得最多的async/await写法代码可读性好出错可以用try-catch包住适合加载后有后续逻辑的情况public async void SpawnEnemy() { try { var handle Addressables.LoadAssetAsyncGameObject(Enemy); var prefab await handle.Task; Instantiate(prefab, transform); } catch (System.Exception e) { Debug.LogError(e); } }第三种是WaitForCompletion()本质上是强制把异步操作变成同步等待。我只建议在测试脚本或初始化阶段使用任何可能导致长时间卡顿的地方都不建议碰var handle Addressables.LoadAssetAsyncGameObject(Enemy); var prefab handle.WaitForCompletion();这三种方式背后其实是同一个句柄区别只在于你什么时候去取结果。选哪种不取决于倾向而取决于调用时机如果调用点本身就在异步管线里优先await如果是开火后不管的子弹特效回调就够了如果是编辑器工具里临时验证资源WaitForCompletion最省事。1.3 时刻记住你拿到的是操作句柄加载完成后Result给了你真正的资源对象但它不替你持有引用。真正握有引用计数的是AsyncOperationHandle这个句柄。很多人写完await handle.Task就把变量一丢后面又要用这个资源就得重新加载一次引用计数越堆越高。正确做法是把句柄保存起来资源生命周期结束时调用Addressables.Release(handle)。一句话总结这一节用LoadAssetAsync加载单个资源地址要配好、类型要传对、句柄要留住三步缺一不可。2. AssetReference想彻底摆脱硬编码地址就靠它2.1 Inspector拖拽背后发生了什么AssetReference是Unity提供的序列化引用类型。你在脚本里声明一个AssetReference字段Inspector会直接显示一个资源选择框美术和策划可以不碰代码、纯靠拖拽就把资源绑定到对象上public AssetReference enemyRef; public async void Spawn() { var handle enemyRef.LoadAssetAsyncGameObject(); var prefab await handle.Task; Instantiate(prefab); }它和字符串地址最大的区别在于字符串是写给代码看的资源路径或地址一旦改你的字符串就要跟着改改漏就是运行时才发现的问题AssetReference在序列化时保存的是资源GUID资源和引用字段可以各自调整只要资源还在同一个Addressable分组里引用关系就不会断。这玩意儿对大型项目尤其重要。我们当时把十几个界面的图标全部换成了AssetReference之后的资源整理就没有再出现过某个按钮图标变成默认问号的问题。2.2 泛型版与子资源引用AssetReference是不限类型的字段绑定错了类型要在运行时才会炸。项目里建议直接用泛型版AssetReferenceTTpublic AssetReferenceTSprite iconRef;这样Inspector里只能拖Sprite类型的资源类型安全在编辑器阶段就有了保障。同一张图片里如果包含多个子资源比如图集里的若干张小图可以使用AssetReferenceUISprite或指定子资源名的方式加载地址写法类似Assets/UI/icon.png[icon_main]方括号里是子资源名字。这块细节官方文档写得比较散我的经验是尽量把UI小图拆成独立资源千万别为了省事全塞一张图集里加载和释放都会遇到很多边界情况。2.3 它的释放和普通加载不一样AssetReference加载出来的资源释放时要调用enemyRef.ReleaseAsset()不是Addressables.Release(handle)。虽然两者底层都能把引用计数归零但AssetReference内部还维护了自己的状态混用API容易出现引用释放了但AssetReference状态还挂着的诡异现象。记住口号谁加载谁释放用什么加载就用对应的释放方法。3. LoadAssetsAsync与标签一次性加载多资源的正确姿势3.1 按单标签批量加载与进度回调批量加载的核心入口是LoadAssetsAsyncT。它的第一个参数可以是一个标签也可以是一个地址列表。按标签加载时标签下所有匹配的资源都会被捞出来var handle Addressables.LoadAssetsAsyncAudioClip( levelMusic, clip { /* 每加载一个回调一次 */ } ); var clips await handle.Task;第二个参数是逐元素回调我通常用它做加载进度UI的增量更新。有的团队会在这里直接往集合里塞数据也得留意如果加载的是缓存命中资源这个回调可能同步执行你在回调里做耗时操作会把主线程卡住。3.2 多key加载与MergeMode三兄弟当需要同时加载多种标签或地址时把key放进一个Liststring再配合MergeMode决定结果如何合并var handle Addressables.LoadAssetsAsyncAudioClip( new Liststring { music, sfx }, clip { }, MergeMode.Union );MergeMode.Union是并集两个标签下的资源都加载MergeMode.Intersection是交集只加载同时满足所有标签的资源MergeMode.UseFirst是碰到第一个有结果的key就返回适合做多级备选资源。一个经常被忽略的点是如果某个key对应的标签下没有任何资源UseFirst可能会跳过它继续往后找Union则会把结果集变小但不报错。写代码前先想清楚业务想要哪种语义。3.3 批量加载的三个坑批量加载最容易踩的坑有三个。第一个是重复加载不释放批量加载会把一批资源全部计入引用如果同一批key反复Load内存会以肉眼可见的速度膨胀。第二个是内存峰值一次性把上百张贴图加载出来在低端机上必然闪退建议分批或按帧加载。第三个是回调时机不可控前面说过缓存命中的资源可能同步回调如果你的回调里依赖了某些初始化状态记得加一个synchronization上下文或者直接承受这个同步行为而不是假设回调一定发生在异步帧里。4. InstantiateAsync实例化加载和普通加载的细节差异4.1 两种实例化方式的区别很多团队刚上手时用的是LoadAssetAsync拿到Prefab再Instantiate这个组合。它的问题在于加载和生成是两步释放时要分别处理加载句柄和实例对象。InstantiateAsync把这两步合成一步直接返回实例var handle Addressables.InstantiateAsync(Enemy, pos, Quaternion.identity); var instance await handle.Task;实例的销毁也有专属APIAddressables.ReleaseInstance(instance)。它会自动把底层Prefab的引用计数减掉同时删除实例。如果你用普通Destroy删掉了实例底层Prefab引用还在下次再InstantiateAsync引用计数会越叠越高。这一点我是吃过亏的后面会展开讲。两种方式的选择标准其实很清楚需要频繁生成和销毁、数量较大的用InstantiateAsync只是加载一个模板做配置读取、不实际生成对象的用LoadAssetAsync。4.2 通过InstantiationParameters控制生成细节InstantiateAsync还有一个重载接收InstantiationParameters可以在加载前就把生成位置、旋转、父节点、是否世界坐标都定好var parameters new InstantiationParameters( position, Quaternion.identity, parent, true); var handle Addressables.InstantiateAsync(Enemy, parameters);对于子弹、怪物这类生成参数高度统一的资源把参数封装成一个工厂方法会非常舒服。我们项目里就是写了一个SpawnHost所有战斗实体生成都走同一个入口后续加阴影、加特效挂点都只改那一处。4.3 实例化管理与释放实战这里分享一个真实教训。我们某一版本怪物死亡后只调用了Destroy(gameObject)没有调用ReleaseInstance。结果就是每个怪物除了生成时占用一份引用死亡后引用计数始终不归零。玩家打一关内存涨一截打十关移动端直接白屏重启。后来我们给所有战斗实体加了一个统一的生成时记录句柄、销毁时释放的组件public class ManagedSpawn : MonoBehaviour { private AsyncOperationHandle _handle; public void BindHandle(AsyncOperationHandle handle) { _handle handle; } private void OnDestroy() { if (!_handle.IsValid()) return; Addressables.ReleaseInstance(gameObject); } }从此之后战斗模块的内存曲线终于能看懂了。这个组件思路很简单但它救回了无数个加班的夜晚。5. LoadSceneAsync场景加载的激活时机与释放链路5.1 activateOnLoad参数决定了你要不要手动激活Addressables加载场景用的是LoadSceneAsync签名看起来和SceneManager很像但多了一个关键参数activateOnLoad。把它设为false时场景资源会加载完毕但不会立刻激活你可以先做自己的准备工作比如播放Loading动画、预加载主角数据时机成熟再手动激活var handle Addressables.LoadSceneAsync( Scenes/Map01, loadMode: LoadSceneMode.Additive, activateOnLoad: false); await handle.Task; // 场景数据已加载完毕这里手动激活 var sceneInstance handle.Result; sceneInstance.Activate();这个能力做关卡切换进度条特别好用。资源没到位前进度条可以停在90%等数据校验通过再瞬间完成切换避免画面闪了一下但模型还是白模的问题。5.2 Additive模式的Loading UI过渡使用Additive模式加载场景时场景会叠加在当前场景之上。常见的过渡方案是先加载一个全屏Loading界面场景再Additive加载目标场景最后卸载Loading界面场景。这样切换时不会出现黑屏也不会让玩家看到半加载状态下的空场景。配合前面的手动激活整个流程的顺序是Loading界面常驻目标场景加载并等待数据准备完毕激活目标场景最后卸载Loading场景。场景卸载也有专属API不要用SceneManager.UnloadSceneAsync去卸载Addressable场景var unloadOp Addressables.UnloadSceneAsync(sceneInstance); await unloadOp.Task;5.3 场景加载与场景卸载的引用关系要特别注意的是Addressable场景本身也是一个资源它被加载时会占一份引用计数。如果场景里又引用了其他Addressable资源那些资源的引用计数也会随着场景加载而增加。卸载场景时Addressables会帮你把场景相关的资源引用一并处理但这要求你在场景脚本里不要手动持有这些资源句柄。我们踩过一个坑场景里的某个UI界面持有了一份UI贴图的句柄场景卸载后贴图句柄没有释放导致场景每次进入都会残留一份内存。场景级资源的生命周期建议统一交给场景管理器来记录和释放。6. 释放与引用计数加载体系里最容易失控的后半程6.1 引用计数是怎么涨上去的Addressables底层对每个资源都维护了引用计数。同一个地址每调用一次加载API引用计数就加一每次Release计数减一。减到零资产才有可能被真正卸载。问题在于它不会主动提醒你这个资源还被引用着。常见的失控场景是同一个资源在多个模块里各自加载了一次模块各自释放自己也只减了一份结果另一份引用永久残留。我在项目里见过一个字体资源被UI、伤害飘字、战斗日志三个模块分别加载过其中有一个模块忘了释放最终结果是字体常驻内存直到进程结束。6.2 三类释放API的适用对照我把项目里用到的释放API整理成了一个对应表建议直接贴在团队文档里加载方式释放方式说明LoadAssetAsynchandle.Release() 或 Addressables.Release(handle)通用释放入口AssetReference.LoadAssetAsyncassetReference.ReleaseAsset()与AssetReference配套InstantiateAsyncAddressables.ReleaseInstance(instance)删除实例并减引用LoadSceneAsyncAddressables.UnloadSceneAsync(handle)卸载场景并减引用这个表看着简单但项目里一半以上的内存问题都能靠对照它解决。所有和释放相关的代码我建议都写在资源管理器里统一维护而不是散落在各个业务脚本中。6.3 一个能兜底的统一资源缓存管理器如果你还在为加载完没释放发愁最直接的解法是写一个简单的资源缓存中心所有加载都通过它走所有释放也都由它集中管理public class AssetCache : MonoBehaviour { private readonly Dictionaryobject, AsyncOperationHandle _cache new Dictionaryobject, AsyncOperationHandle(); public async TaskT LoadAsyncT(object key) where T : Object { if (_cache.TryGetValue(key, out var oldHandle) oldHandle.IsValid()) { return (T)oldHandle.Result; } var handle Addressables.LoadAssetAsyncT(key); _cache[key] handle; await handle.Task; return handle.Result; } public void ReleaseAll() { foreach (var handle in _cache.Values) { if (handle.IsValid()) { Addressables.Release(handle); } } _cache.Clear(); } }注意这个管理器只是兜底它保证重复加载会复用同一个句柄也保证释放时不会重复释放。但真正确定资源生命周期的工作还是得业务层配合。建议在切场景、切章节的节点上调用一次ReleaseAll把全局性资源释放干净。7. 初始化与内容目录远程资源包的前置环节7.1 隐式初始化与Play Mode脚本Addressables第一次调用任意加载API时会自动执行初始化读取AddressableAssetSettings、加载内容目录、建立本地资源映射。如果项目只需要本地加载这些隐式操作一般够用。但编辑器里调试时有三个Play Mode脚本需要理解Use Asset Database不走打包直接读源资源最适合开发、Use Simulated Groups模拟打包后的加载行为适合验证分组配置、Use Actual Build走真实Bundle适合验证打包内容。切到模拟或真实模式后很多在数据库模式下跑得好好的接口突然失败多半就是分组配置和测试模式不匹配。7.2 手动检查与更新目录的推荐流程如果你的项目涉及远程资源更新默认的启动自动检查可能不够灵活。推荐的做法是自己控制检查时机在进入标题界面后静默检查下载完成后提示重启或刷新资源var checkHandle Addressables.CheckForCatalogUpdates(false); await checkHandle.Task; Liststring updatedCatalogs checkHandle.Result; if (updatedCatalogs ! null updatedCatalogs.Count 0) { var updateHandle Addressables.UpdateCatalogs(updatedCatalogs); await updateHandle.Task; updateHandle.Release(); } checkHandle.Release();这个流程的好处是可以把检查更新从启动阶段挪到玩家已经看到UI之后再执行避免冷启动时间被网络拖垮。CheckForCatalogUpdates返回的列表就是需要更新的目录ID后面UpdateCatalogs会异步完成内容目录的刷新。注意两个句柄都要释放否则每次更新都会残留一份目录引用。7.3 本地/远程双目录的路径规划要点Addressables的加载路径由Profile里的BuildPath和LoadPath决定常见做法是本地资源打包进StreamingAssets远程资源放到CDN或文件服务器。规划时我会坚持一个原则本地目录只放启动必需的小资源远程目录放所有可后置加载的内容。别把几十MB的过场动画塞进远程目录却在启动时就必须加载那是给自己挖坑。路径配置错的前兆通常是日志里出现Failed to load asset bundle from path这时候优先检查Profile的LoadPath拼接出来的URL能不能直接在浏览器里打开省得来回怀疑代码。8. 实战项目里最容易踩的坑与排查思路8.1 无效Key报错先查Groups窗口再查拼写项目里最频繁的报错就是InvalidKey或Address not found。每次出现我的排查顺序都固定不变第一步打开Addressables Groups窗口确认目标资源有没有被标记为Addressable第二步看Inspector里设置的Address和代码里传的key是否完全一致第三步确认这个资源是否在正确的分组里。有时你以为已经标记了实际上只是放进了某个分组但忘了勾选Addressable复选框这种情况下报错信息会伪装成别的样子。Assets/xxx.prefab这种路径作为key能生效的前提是该资源已经是Addressable路径只是它的默认地址不是万能钥匙。8.2 加载后立刻释放花贴图和空引用从这里来还有一个很隐蔽的坑加载完成后马上释放句柄但业务上还在用资源。比如某个界面先LoadAssetAsyncSprite拿到贴图在回调里立刻Release然后UI才开始异步加载布局。结果贴图句柄已经归零AssetBundle被回收UI界面实际渲染时读取到的是一块被释放的内存表现就是花贴图、紫屏或者空引用。正确做法是资源的加载句柄生命周期应覆盖到最后一次使用该资源之后。宁可晚释放也不要因为想省内存而提前释放导致运行时炸掉。8.3 用Profiler确认引用计数泄漏的真凶当内存曲线异常时直接用Addressables Profiler模块看引用计数。它能列出当前所有加载句柄、引用计数、持有者信息。我的排查步骤是先跑一遍典型玩法流程打开Profiler拉出所有句柄凡是引用计数不为零但业务逻辑里已经找不到持有者的就是泄漏点。大多数情况是异步回调没执行完就切换场景或者对象被Destroy时没有触发释放逻辑。找到泄漏点后修复通常只需要在合适生命周期补一句Release但找的过程确实需要耐心。最后再说一个我用下来觉得最重要的小习惯加载和释放永远写在同一个上下文里。要么写在同一方法要么写入同一个管理器不要让句柄在不同模块之间传来传去。Addressables本身的设计很强大但失控的从来不是API而是没有规则的调用方式。希望这份汇总能让你少走我走过的那几条弯路。 
长河君 · 2026/10/14 8:34:23 · 阅读 1.2k Unity Addressables 资源加载全攻略：从入门到内存管理实战
讲到Unity的资源加载很多团队是从Resources目录一路走过来的。Resources.Load写起来简单但包体、内存、热更新这三座大山迟早会压垮它。我真正下决心迁到Addressables是在一个卡了许久的加载流程优化里——当时项目素材越来越多加载逻辑散落在各个界面想统一做优先级、做进度条、做预加载根本无从下手。Addressables的价值不只是换了一套API而是把资源的定位、加载、依赖、释放变成了一套可管理的体系。这篇文章把我在项目里实际用过的所有加载方式做一个汇总单个加载、引用加载、批量加载、实例化加载、场景加载、远程目录加载每一条都带上适用场景和释放细节给正在迁移或刚起步的团队一份可以照着写的参考。1. LoadAssetAsync单个资源加载的三种落地写法1.1 加载前先确认地址和类型很多新手第一句代码就是Addressables.LoadAssetAsyncGameObject(Assets/Prefabs/Enemy.prefab)结果跑起来直接报错。这里最容易被忽略的前提是这个资源必须在Addressables Groups窗口里被标记为Addressable。标记之后默认地址就是它在Assets下的完整路径你可以在Inspector里把它改成任意短字符串比如Enemy。地址确定了还要确定泛型类型。加载Prefab用GameObject加载ScriptableObject用你自定义的SO类型加载图片用Sprite或Texture2D。类型传错会直接失败因为Aseet底层是按照类型去找对应对象的。我的建议是项目中约定好地址命名规则不要一部分人用短地址、一部分人用全路径后面排查问题阶段会省掉大量时间。1.2 回调、await、同步等待怎么选单个资源加载的消费方式有三种我按项目里出现的频率分别说。第一种是Completed回调适合那种加载完就干一件事、不需要继续串联的场景var handle Addressables.LoadAssetAsyncGameObject(Enemy); handle.Completed op { if (op.Status AsyncOperationStatus.Succeeded) { var prefab op.Result; Instantiate(prefab, transform); } else { Debug.LogError($加载失败: {op.OperationException}); } };第二种是我个人用得最多的async/await写法代码可读性好出错可以用try-catch包住适合加载后有后续逻辑的情况public async void SpawnEnemy() { try { var handle Addressables.LoadAssetAsyncGameObject(Enemy); var prefab await handle.Task; Instantiate(prefab, transform); } catch (System.Exception e) { Debug.LogError(e); } }第三种是WaitForCompletion()本质上是强制把异步操作变成同步等待。我只建议在测试脚本或初始化阶段使用任何可能导致长时间卡顿的地方都不建议碰var handle Addressables.LoadAssetAsyncGameObject(Enemy); var prefab handle.WaitForCompletion();这三种方式背后其实是同一个句柄区别只在于你什么时候去取结果。选哪种不取决于倾向而取决于调用时机如果调用点本身就在异步管线里优先await如果是开火后不管的子弹特效回调就够了如果是编辑器工具里临时验证资源WaitForCompletion最省事。1.3 时刻记住你拿到的是操作句柄加载完成后Result给了你真正的资源对象但它不替你持有引用。真正握有引用计数的是AsyncOperationHandle这个句柄。很多人写完await handle.Task就把变量一丢后面又要用这个资源就得重新加载一次引用计数越堆越高。正确做法是把句柄保存起来资源生命周期结束时调用Addressables.Release(handle)。一句话总结这一节用LoadAssetAsync加载单个资源地址要配好、类型要传对、句柄要留住三步缺一不可。2. AssetReference想彻底摆脱硬编码地址就靠它2.1 Inspector拖拽背后发生了什么AssetReference是Unity提供的序列化引用类型。你在脚本里声明一个AssetReference字段Inspector会直接显示一个资源选择框美术和策划可以不碰代码、纯靠拖拽就把资源绑定到对象上public AssetReference enemyRef; public async void Spawn() { var handle enemyRef.LoadAssetAsyncGameObject(); var prefab await handle.Task; Instantiate(prefab); }它和字符串地址最大的区别在于字符串是写给代码看的资源路径或地址一旦改你的字符串就要跟着改改漏就是运行时才发现的问题AssetReference在序列化时保存的是资源GUID资源和引用字段可以各自调整只要资源还在同一个Addressable分组里引用关系就不会断。这玩意儿对大型项目尤其重要。我们当时把十几个界面的图标全部换成了AssetReference之后的资源整理就没有再出现过某个按钮图标变成默认问号的问题。2.2 泛型版与子资源引用AssetReference是不限类型的字段绑定错了类型要在运行时才会炸。项目里建议直接用泛型版AssetReferenceTTpublic AssetReferenceTSprite iconRef;这样Inspector里只能拖Sprite类型的资源类型安全在编辑器阶段就有了保障。同一张图片里如果包含多个子资源比如图集里的若干张小图可以使用AssetReferenceUISprite或指定子资源名的方式加载地址写法类似Assets/UI/icon.png[icon_main]方括号里是子资源名字。这块细节官方文档写得比较散我的经验是尽量把UI小图拆成独立资源千万别为了省事全塞一张图集里加载和释放都会遇到很多边界情况。2.3 它的释放和普通加载不一样AssetReference加载出来的资源释放时要调用enemyRef.ReleaseAsset()不是Addressables.Release(handle)。虽然两者底层都能把引用计数归零但AssetReference内部还维护了自己的状态混用API容易出现引用释放了但AssetReference状态还挂着的诡异现象。记住口号谁加载谁释放用什么加载就用对应的释放方法。3. LoadAssetsAsync与标签一次性加载多资源的正确姿势3.1 按单标签批量加载与进度回调批量加载的核心入口是LoadAssetsAsyncT。它的第一个参数可以是一个标签也可以是一个地址列表。按标签加载时标签下所有匹配的资源都会被捞出来var handle Addressables.LoadAssetsAsyncAudioClip( levelMusic, clip { /* 每加载一个回调一次 */ } ); var clips await handle.Task;第二个参数是逐元素回调我通常用它做加载进度UI的增量更新。有的团队会在这里直接往集合里塞数据也得留意如果加载的是缓存命中资源这个回调可能同步执行你在回调里做耗时操作会把主线程卡住。3.2 多key加载与MergeMode三兄弟当需要同时加载多种标签或地址时把key放进一个Liststring再配合MergeMode决定结果如何合并var handle Addressables.LoadAssetsAsyncAudioClip( new Liststring { music, sfx }, clip { }, MergeMode.Union );MergeMode.Union是并集两个标签下的资源都加载MergeMode.Intersection是交集只加载同时满足所有标签的资源MergeMode.UseFirst是碰到第一个有结果的key就返回适合做多级备选资源。一个经常被忽略的点是如果某个key对应的标签下没有任何资源UseFirst可能会跳过它继续往后找Union则会把结果集变小但不报错。写代码前先想清楚业务想要哪种语义。3.3 批量加载的三个坑批量加载最容易踩的坑有三个。第一个是重复加载不释放批量加载会把一批资源全部计入引用如果同一批key反复Load内存会以肉眼可见的速度膨胀。第二个是内存峰值一次性把上百张贴图加载出来在低端机上必然闪退建议分批或按帧加载。第三个是回调时机不可控前面说过缓存命中的资源可能同步回调如果你的回调里依赖了某些初始化状态记得加一个synchronization上下文或者直接承受这个同步行为而不是假设回调一定发生在异步帧里。4. InstantiateAsync实例化加载和普通加载的细节差异4.1 两种实例化方式的区别很多团队刚上手时用的是LoadAssetAsync拿到Prefab再Instantiate这个组合。它的问题在于加载和生成是两步释放时要分别处理加载句柄和实例对象。InstantiateAsync把这两步合成一步直接返回实例var handle Addressables.InstantiateAsync(Enemy, pos, Quaternion.identity); var instance await handle.Task;实例的销毁也有专属APIAddressables.ReleaseInstance(instance)。它会自动把底层Prefab的引用计数减掉同时删除实例。如果你用普通Destroy删掉了实例底层Prefab引用还在下次再InstantiateAsync引用计数会越叠越高。这一点我是吃过亏的后面会展开讲。两种方式的选择标准其实很清楚需要频繁生成和销毁、数量较大的用InstantiateAsync只是加载一个模板做配置读取、不实际生成对象的用LoadAssetAsync。4.2 通过InstantiationParameters控制生成细节InstantiateAsync还有一个重载接收InstantiationParameters可以在加载前就把生成位置、旋转、父节点、是否世界坐标都定好var parameters new InstantiationParameters( position, Quaternion.identity, parent, true); var handle Addressables.InstantiateAsync(Enemy, parameters);对于子弹、怪物这类生成参数高度统一的资源把参数封装成一个工厂方法会非常舒服。我们项目里就是写了一个SpawnHost所有战斗实体生成都走同一个入口后续加阴影、加特效挂点都只改那一处。4.3 实例化管理与释放实战这里分享一个真实教训。我们某一版本怪物死亡后只调用了Destroy(gameObject)没有调用ReleaseInstance。结果就是每个怪物除了生成时占用一份引用死亡后引用计数始终不归零。玩家打一关内存涨一截打十关移动端直接白屏重启。后来我们给所有战斗实体加了一个统一的生成时记录句柄、销毁时释放的组件public class ManagedSpawn : MonoBehaviour { private AsyncOperationHandle _handle; public void BindHandle(AsyncOperationHandle handle) { _handle handle; } private void OnDestroy() { if (!_handle.IsValid()) return; Addressables.ReleaseInstance(gameObject); } }从此之后战斗模块的内存曲线终于能看懂了。这个组件思路很简单但它救回了无数个加班的夜晚。5. LoadSceneAsync场景加载的激活时机与释放链路5.1 activateOnLoad参数决定了你要不要手动激活Addressables加载场景用的是LoadSceneAsync签名看起来和SceneManager很像但多了一个关键参数activateOnLoad。把它设为false时场景资源会加载完毕但不会立刻激活你可以先做自己的准备工作比如播放Loading动画、预加载主角数据时机成熟再手动激活var handle Addressables.LoadSceneAsync( Scenes/Map01, loadMode: LoadSceneMode.Additive, activateOnLoad: false); await handle.Task; // 场景数据已加载完毕这里手动激活 var sceneInstance handle.Result; sceneInstance.Activate();这个能力做关卡切换进度条特别好用。资源没到位前进度条可以停在90%等数据校验通过再瞬间完成切换避免画面闪了一下但模型还是白模的问题。5.2 Additive模式的Loading UI过渡使用Additive模式加载场景时场景会叠加在当前场景之上。常见的过渡方案是先加载一个全屏Loading界面场景再Additive加载目标场景最后卸载Loading界面场景。这样切换时不会出现黑屏也不会让玩家看到半加载状态下的空场景。配合前面的手动激活整个流程的顺序是Loading界面常驻目标场景加载并等待数据准备完毕激活目标场景最后卸载Loading场景。场景卸载也有专属API不要用SceneManager.UnloadSceneAsync去卸载Addressable场景var unloadOp Addressables.UnloadSceneAsync(sceneInstance); await unloadOp.Task;5.3 场景加载与场景卸载的引用关系要特别注意的是Addressable场景本身也是一个资源它被加载时会占一份引用计数。如果场景里又引用了其他Addressable资源那些资源的引用计数也会随着场景加载而增加。卸载场景时Addressables会帮你把场景相关的资源引用一并处理但这要求你在场景脚本里不要手动持有这些资源句柄。我们踩过一个坑场景里的某个UI界面持有了一份UI贴图的句柄场景卸载后贴图句柄没有释放导致场景每次进入都会残留一份内存。场景级资源的生命周期建议统一交给场景管理器来记录和释放。6. 释放与引用计数加载体系里最容易失控的后半程6.1 引用计数是怎么涨上去的Addressables底层对每个资源都维护了引用计数。同一个地址每调用一次加载API引用计数就加一每次Release计数减一。减到零资产才有可能被真正卸载。问题在于它不会主动提醒你这个资源还被引用着。常见的失控场景是同一个资源在多个模块里各自加载了一次模块各自释放自己也只减了一份结果另一份引用永久残留。我在项目里见过一个字体资源被UI、伤害飘字、战斗日志三个模块分别加载过其中有一个模块忘了释放最终结果是字体常驻内存直到进程结束。6.2 三类释放API的适用对照我把项目里用到的释放API整理成了一个对应表建议直接贴在团队文档里加载方式释放方式说明LoadAssetAsynchandle.Release() 或 Addressables.Release(handle)通用释放入口AssetReference.LoadAssetAsyncassetReference.ReleaseAsset()与AssetReference配套InstantiateAsyncAddressables.ReleaseInstance(instance)删除实例并减引用LoadSceneAsyncAddressables.UnloadSceneAsync(handle)卸载场景并减引用这个表看着简单但项目里一半以上的内存问题都能靠对照它解决。所有和释放相关的代码我建议都写在资源管理器里统一维护而不是散落在各个业务脚本中。6.3 一个能兜底的统一资源缓存管理器如果你还在为加载完没释放发愁最直接的解法是写一个简单的资源缓存中心所有加载都通过它走所有释放也都由它集中管理public class AssetCache : MonoBehaviour { private readonly Dictionaryobject, AsyncOperationHandle _cache new Dictionaryobject, AsyncOperationHandle(); public async TaskT LoadAsyncT(object key) where T : Object { if (_cache.TryGetValue(key, out var oldHandle) oldHandle.IsValid()) { return (T)oldHandle.Result; } var handle Addressables.LoadAssetAsyncT(key); _cache[key] handle; await handle.Task; return handle.Result; } public void ReleaseAll() { foreach (var handle in _cache.Values) { if (handle.IsValid()) { Addressables.Release(handle); } } _cache.Clear(); } }注意这个管理器只是兜底它保证重复加载会复用同一个句柄也保证释放时不会重复释放。但真正确定资源生命周期的工作还是得业务层配合。建议在切场景、切章节的节点上调用一次ReleaseAll把全局性资源释放干净。7. 初始化与内容目录远程资源包的前置环节7.1 隐式初始化与Play Mode脚本Addressables第一次调用任意加载API时会自动执行初始化读取AddressableAssetSettings、加载内容目录、建立本地资源映射。如果项目只需要本地加载这些隐式操作一般够用。但编辑器里调试时有三个Play Mode脚本需要理解Use Asset Database不走打包直接读源资源最适合开发、Use Simulated Groups模拟打包后的加载行为适合验证分组配置、Use Actual Build走真实Bundle适合验证打包内容。切到模拟或真实模式后很多在数据库模式下跑得好好的接口突然失败多半就是分组配置和测试模式不匹配。7.2 手动检查与更新目录的推荐流程如果你的项目涉及远程资源更新默认的启动自动检查可能不够灵活。推荐的做法是自己控制检查时机在进入标题界面后静默检查下载完成后提示重启或刷新资源var checkHandle Addressables.CheckForCatalogUpdates(false); await checkHandle.Task; Liststring updatedCatalogs checkHandle.Result; if (updatedCatalogs ! null updatedCatalogs.Count 0) { var updateHandle Addressables.UpdateCatalogs(updatedCatalogs); await updateHandle.Task; updateHandle.Release(); } checkHandle.Release();这个流程的好处是可以把检查更新从启动阶段挪到玩家已经看到UI之后再执行避免冷启动时间被网络拖垮。CheckForCatalogUpdates返回的列表就是需要更新的目录ID后面UpdateCatalogs会异步完成内容目录的刷新。注意两个句柄都要释放否则每次更新都会残留一份目录引用。7.3 本地/远程双目录的路径规划要点Addressables的加载路径由Profile里的BuildPath和LoadPath决定常见做法是本地资源打包进StreamingAssets远程资源放到CDN或文件服务器。规划时我会坚持一个原则本地目录只放启动必需的小资源远程目录放所有可后置加载的内容。别把几十MB的过场动画塞进远程目录却在启动时就必须加载那是给自己挖坑。路径配置错的前兆通常是日志里出现Failed to load asset bundle from path这时候优先检查Profile的LoadPath拼接出来的URL能不能直接在浏览器里打开省得来回怀疑代码。8. 实战项目里最容易踩的坑与排查思路8.1 无效Key报错先查Groups窗口再查拼写项目里最频繁的报错就是InvalidKey或Address not found。每次出现我的排查顺序都固定不变第一步打开Addressables Groups窗口确认目标资源有没有被标记为Addressable第二步看Inspector里设置的Address和代码里传的key是否完全一致第三步确认这个资源是否在正确的分组里。有时你以为已经标记了实际上只是放进了某个分组但忘了勾选Addressable复选框这种情况下报错信息会伪装成别的样子。Assets/xxx.prefab这种路径作为key能生效的前提是该资源已经是Addressable路径只是它的默认地址不是万能钥匙。8.2 加载后立刻释放花贴图和空引用从这里来还有一个很隐蔽的坑加载完成后马上释放句柄但业务上还在用资源。比如某个界面先LoadAssetAsyncSprite拿到贴图在回调里立刻Release然后UI才开始异步加载布局。结果贴图句柄已经归零AssetBundle被回收UI界面实际渲染时读取到的是一块被释放的内存表现就是花贴图、紫屏或者空引用。正确做法是资源的加载句柄生命周期应覆盖到最后一次使用该资源之后。宁可晚释放也不要因为想省内存而提前释放导致运行时炸掉。8.3 用Profiler确认引用计数泄漏的真凶当内存曲线异常时直接用Addressables Profiler模块看引用计数。它能列出当前所有加载句柄、引用计数、持有者信息。我的排查步骤是先跑一遍典型玩法流程打开Profiler拉出所有句柄凡是引用计数不为零但业务逻辑里已经找不到持有者的就是泄漏点。大多数情况是异步回调没执行完就切换场景或者对象被Destroy时没有触发释放逻辑。找到泄漏点后修复通常只需要在合适生命周期补一句Release但找的过程确实需要耐心。最后再说一个我用下来觉得最重要的小习惯加载和释放永远写在同一个上下文里。要么写在同一方法要么写入同一个管理器不要让句柄在不同模块之间传来传去。Addressables本身的设计很强大但失控的从来不是API而是没有规则的调用方式。希望这份汇总能让你少走我走过的那几条弯路。