1. 项目概述为什么我们需要告别SubScene在Unity ECS实体组件系统的开发中尤其是使用Entities 1.0.16这个版本SubScene曾经是管理场景和资源的“标准答案”。它允许我们将一部分实体和组件序列化到场景文件中然后在运行时异步加载这对于管理大型世界的不同区域非常有用。然而随着项目规模的扩大和资源管理需求的精细化SubScene的局限性也日益凸显。最核心的问题在于它本质上是一种“场景切片”的静态管理方式资源与场景逻辑绑定过紧缺乏真正的动态性和灵活性。想象一下你正在开发一个开放世界游戏。玩家从一个区域移动到另一个区域SubScene可以帮你加载新的地形和静态建筑。但是如果玩家在战斗中击毁了一个建筑需要动态加载爆炸特效和废墟模型或者一个NPC根据任务状态需要更换身上的装备模型——这些需求SubScene就力不从心了。你不可能为每一个可能动态出现的资源组合都预先制作一个SubScene那样会带来灾难性的场景管理和构建复杂度。此外SubScene的加载和卸载粒度是“场景切片”对于单个预制体、材质球或音频等细粒度资源的按需加载与释放它显得过于笨重。这就是Addressables资源管理系统登场的时候。Addressables的核心思想是“按地址加载”它将资源从传统的Resources文件夹或直接场景引用中解耦出来为每个资源分配一个唯一的地址。你可以像在网络上通过URL请求数据一样通过这个地址在运行时异步加载任何资源。将这套系统与Unity Entities结合我们就能实现真正的、细粒度的动态资源加载按需加载一个角色模型、一套粒子特效、一段环境音效并在使用完毕后精准释放内存管理将变得前所未有的清晰和高效。本指南将带你一步步将一个依赖SubScene的Entities项目彻底改造为基于Addressables的动态资源加载架构。这不仅是一次技术升级更是一种开发范式的转变旨在为你的项目带来终极的灵活性与可维护性。2. 核心架构设计Entities与Addressables的融合之道将Entities与Addressables结合并非简单地将Prefab引用换成Addressables的加载调用。我们需要设计一个与ECS数据驱动、面向数据设计理念契合的异步加载架构。核心目标是在不阻塞主线程游戏逻辑的前提下发起资源请求并在资源准备就绪后将其正确注入到对应的Entity中。2.1 传统模式与新模式对比在SubScene模式下资源加载流程是定义SubScene资产将包含原型的GameObject放入其中。运行时通过SceneSystem.LoadSceneAsync加载整个SubScene。加载完成后SubScene中的实体自动并入当前世界。这个过程是黑盒的你很难介入加载中间状态也无法单独卸载某个特定的预制体。在Addressables Entities模式下流程变为将需要动态实例化的预制体如敌人、道具、特效标记为Addressable。在ECS系统中通过一个EntityCommandBufferECB或直接在一个System中发起一个Addressables.LoadAssetAsyncGameObject请求。这个异步操作会返回一个AsyncOperationHandleGameObject。我们需要管理这个Handle的生命周期。加载完成后在回调或通过检查Handle状态将加载到的GameObject通过EntityManager实例化为一个Entity。关键在于第2步到第4步必须与ECS的作业Job系统和组件更新周期协调。我们不能在Job中直接调用异步加载因为Job不允许托管调用也不能让资源加载的不确定性破坏ECS确定性的执行顺序。2.2 核心组件设计我们需要创建几个关键的ECS组件来驱动整个流程SpawnerComponent (Authoring Component): 这是一个挂在GameObject上的MonoBehaviour组件用于在编辑器中配置。它包含一个AssetReferenceGameObject字段这是Addressables系统提供的类型让我们可以像拖拽普通预制体一样从Addressables Groups中拖拽资源引用进来。这个组件在Baking过程中会转换为一个ECS组件。SpawnRequestComponent (IComponentData): 这是一个纯ECS组件表示一个“生成实体”的请求。它可能包含生成位置、旋转等信息以及最关键的一个AssetReferenceGameObject的GUID或一个表示地址的FixedString。这个组件由游戏逻辑系统添加触发加载流程。AssetLoadingComponent (IComponentData): 这是一个状态组件用于跟踪异步加载的进度。它内部持有一个AsyncOperationHandleGameObject的弱引用实际上我们需要一个自定义的、可序列化到BlobAsset或通过其他方式管理的标识或者更简单点持有一个加载状态枚举如None, Loading, Loaded, Failed和资源的地址。一个独立的System会轮询所有带有此组件的实体检查其加载状态。PrefabLoadSystem (SystemBase): 这是核心管理系统。它每帧执行主要做两件事处理SpawnRequest: 遍历所有带有SpawnRequestComponent但没有AssetLoadingComponent的实体。为它们添加AssetLoadingComponent并在主线程SystemBase.OnUpdate中调用Addressables.LoadAssetAsync将返回的Handle与这个Entity关联起来。检查加载状态: 遍历所有带有AssetLoadingComponent且状态为Loading的实体。检查其关联的异步操作Handle是否完成IsDone。如果完成且成功则获取加载到的GameObject预制体通过EntityManager.Instantiate将其转换为Entity并建立父子关系或设置位置。最后移除AssetLoadingComponent和SpawnRequestComponent并释放或缓存AsyncOperationHandle。关键设计决策为什么不在Job中加载因为Addressables的API是托管代码与Burst编译的Job不兼容。因此资源加载的发起和完成检查必须在主线程的SystemBase中进行。我们可以利用SystemBase的OnUpdate来管理这些主线程操作而将大量的数据处理如计算生成位置、应用伤害等放在ISystem或SystemBase中调度Burst Job去完成。这就是典型的“主线程驱动异步I/O数据层并行处理”的ECS架构。2.3 资源标识与依赖管理使用Addressables后资源通过地址字符串或AssetReference进行标识。在ECS中字符串操作成本较高且不利于Burst。因此一个常见的优化是使用FixedString64Bytes或FixedString128Bytes来存储资源地址或者使用AssetReference的运行时Key也是一个字符串的哈希值如FixedString的GetHashCode作为一个int类型的ID在组件间传递。更高级的架构会引入“资产注册表”的概念。在游戏初始化时将所有可能用到的Addressables资源的地址和其对应的哈希ID或一个自增的枚举值注册到一个NativeHashMap中。这样在SpawnRequestComponent中只需要存储一个int类型的AssetID极大地提高了数据局部性和查询效率。加载系统根据这个ID去注册表中查找实际的地址字符串再进行加载。依赖管理则由Addressables系统自动处理。如果你加载一个预制体它依赖的材质、贴图、网格等资源会自动被加载和引用计数。当你通过Addressables释放该预制体时只有当所有依赖它的实例都被销毁且引用计数归零底层资源才会被真正从内存中卸载。这比手动管理Resources或AssetBundle要可靠得多。3. 实战步骤从零搭建动态加载框架理论讲完我们开始动手。假设我们有一个简单的需求玩家点击鼠标在点击位置动态加载一个Addressables管理的炮塔预制体。3.1 项目初始化与包安装首先确保你的项目使用的是Unity 2022.3 LTS或更新版本并且已通过Package Manager安装了Entities 1.0.16及相关包如Hybrid Renderer。安装Addressables打开Package Manager选择Unity Registry找到“Addressables”包并安装。目前稳定版本为1.21.21左右与Entities 1.0.16兼容良好。初始化Addressables菜单栏选择Window - Asset Management - Addressables - Groups。首次打开会提示创建设置点击Create Addressables Settings。这会在Assets目录下生成AddressableAssetsData文件夹。配置Addressables分组策略可选但推荐在Addressables Groups窗口你可以创建不同的组来管理资源例如“UI”、“Characters”、“Effects”、“Sounds”。将资源按生命周期和更新频率分组便于远程分发和增量更新。对于初学者可以暂时使用默认的“Built In Data”组。3.2 准备可动态加载的预制体在场景中创建一个炮塔模型做成一个普通的预制体Turret.prefab。将这个预制体拖入到Addressables Groups窗口的某个组比如“Characters”组中。你会发现预制体资产左上角多了一个绿色的Addressables标识。点击这个预制体在Addressables窗口中的条目在Inspector面板可以看到它的“Address”。默认是它的资产路径你可以修改为一个更友好的名字如“TurretRed”。记住这个地址它是加载的关键。3.3 创建ECS组件与Authoring我们需要创建请求组件和Authoring组件。1. 创建SpawnRequestComponentusing Unity.Entities; using Unity.Collections; // 这是一个生成请求由游戏逻辑如输入系统创建 public struct SpawnRequest : IComponentData { // 使用FixedString存储资源地址避免GC public FixedString64Bytes AssetAddress; // 生成位置世界坐标 public float3 Position; // 生成旋转 public quaternion Rotation; }2. 创建SpawnerAuthoring (MonoBehaviour)这个组件用于在编辑器中方便地配置生成点。using UnityEngine; using Unity.Entities; using UnityEngine.AddressableAssets; // 引入Addressables命名空间 public class SpawnerAuthoring : MonoBehaviour { // 在Inspector中拖拽Addressables资源引用 public AssetReferenceGameObject PrefabToSpawn; // 生成位置偏移相对于此GameObject public Vector3 SpawnOffset Vector3.zero; // 一个Baker类负责将MonoBehaviour数据转换为ECS组件 class Baker : BakerSpawnerAuthoring { public override void Bake(SpawnerAuthoring authoring) { var entity GetEntity(TransformUsageFlags.Dynamic); // 将AssetReference转换为一个字符串地址存储在组件中。 // 注意这里直接获取了运行时Key。确保PrefabToSpawn在Addressables中已分配。 if (authoring.PrefabToSpawn ! null authoring.PrefabToSpawn.RuntimeKeyIsValid()) { // 添加一个SpawnRequest组件但AssetAddress先留空由另一个初始化系统填充。 // 或者我们可以添加一个包含AssetReference的Tag组件但这更复杂。 // 更简单的做法我们不在Baking时添加SpawnRequest而是由另一个MonoBehaviour或系统在运行时触发。 // 这里我们先添加一个Tag组件标记这是一个生成器。 AddComponent(entity, new SpawnerTag()); // 将资源地址和偏移量存储到另一个组件中 AddComponent(entity, new SpawnerData { PrefabAddress authoring.PrefabToSpawn.RuntimeKey.ToString(), SpawnOffset authoring.SpawnOffset }); } } } } // 用于标记生成器实体的Tag public struct SpawnerTag : IComponentData { } // 存储生成器配置数据 public struct SpawnerData : IComponentData { public FixedString64Bytes PrefabAddress; public float3 SpawnOffset; }注意这里的设计是SpawnerAuthoring在Baking时并不直接创建SpawnRequest而是将配置信息地址、偏移量存入SpawnerData。实际的SpawnRequest将由游戏逻辑例如一个响应鼠标点击的系统来创建。这样实现了配置与逻辑的分离。3.4 实现核心加载系统这是最复杂也最核心的部分。我们将创建一个PrefabLoadSystem它继承自SystemBase因为我们需要在主线程操作Addressables API。using Unity.Entities; using Unity.Collections; using Unity.Jobs; using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.AddressableAssets.ResourceLocators; using UnityEngine.ResourceManagement.AsyncOperations; using System.Collections.Generic; // 用于跟踪加载状态的组件 public struct AssetLoadingState : IComponentData, IEnableableComponent { public enum Status { None, Requested, Loading, Loaded, Failed } public Status CurrentStatus; public FixedString64Bytes AssetAddress; // 我们无法直接将AsyncOperationHandle存储在ECS组件中非blittable类型。 // 因此我们需要一个间接的解决方案使用一个唯一的ID并在System中用一个Dictionary来管理Handle。 public int HandleId; } // 核心加载系统 [UpdateInGroup(typeof(InitializationSystemGroup))] // 在每帧早期执行 public partial struct PrefabLoadSystem : ISystem { private NativeHashMapint, AsyncOperationHandleGameObject _loadingHandles; private int _nextHandleId; public void OnCreate(ref SystemState state) { _loadingHandles new NativeHashMapint, AsyncOperationHandleGameObject(100, Allocator.Persistent); _nextHandleId 1; state.RequireForUpdateBeginInitializationEntityCommandBufferSystem.Singleton(); } public void OnDestroy(ref SystemState state) { // 非常重要系统销毁时清理所有未完成的加载操作 foreach (var handle in _loadingHandles.GetValueArray(Allocator.Temp)) { if (handle.IsValid()) { Addressables.Release(handle); } } _loadingHandles.Dispose(); } public void OnUpdate(ref SystemState state) { var ecbSingleton SystemAPI.GetSingletonBeginInitializationEntityCommandBufferSystem.Singleton(); var ecb ecbSingleton.CreateCommandBuffer(state.WorldUnmanaged); // 阶段1处理新的生成请求创建加载状态 foreach (var (spawnReq, entity) in SystemAPI.QuerySpawnRequest().WithEntityAccess().WithNoneAssetLoadingState()) { ecb.AddComponent(entity, new AssetLoadingState { CurrentStatus AssetLoadingState.Status.Requested, AssetAddress spawnReq.AssetAddress, HandleId 0 // 稍后分配 }); // 注意我们暂时不移除SpawnRequest等加载完成后再一并清理 } // 阶段2启动加载状态为Requested的实体 // 这个循环必须在主线程因为要调用Addressables API var loadingStateQuery SystemAPI.QueryBuilder().WithAllAssetLoadingState().WithNonePrefabLoadedTag().Build(); var loadingStates loadingStateQuery.ToComponentDataArrayAssetLoadingState(Allocator.Temp); var loadingEntities loadingStateQuery.ToEntityArray(Allocator.Temp); for (int i 0; i loadingStates.Length; i) { var stateComp loadingStates[i]; var entity loadingEntities[i]; if (stateComp.CurrentStatus AssetLoadingState.Status.Requested) { // 分配一个唯一ID并启动异步加载 int handleId _nextHandleId; var loadHandle Addressables.LoadAssetAsyncGameObject(stateComp.AssetAddress.ToString()); // 将Handle存入字典 _loadingHandles.Add(handleId, loadHandle); // 更新组件状态 stateComp.CurrentStatus AssetLoadingState.Status.Loading; stateComp.HandleId handleId; ecb.SetComponent(entity, stateComp); } } loadingStates.Dispose(); loadingEntities.Dispose(); // 阶段3检查加载完成状态 var loadingStateQuery2 SystemAPI.QueryBuilder().WithAllAssetLoadingState().WithNonePrefabLoadedTag().Build(); var loadingStates2 loadingStateQuery2.ToComponentDataArrayAssetLoadingState(Allocator.Temp); var loadingEntities2 loadingStateQuery2.ToEntityArray(Allocator.Temp); var spawnRequestLookup SystemAPI.GetComponentLookupSpawnRequest(true); for (int i 0; i loadingStates2.Length; i) { var stateComp loadingStates2[i]; var entity loadingEntities2[i]; if (stateComp.CurrentStatus AssetLoadingState.Status.Loading _loadingHandles.ContainsKey(stateComp.HandleId)) { var handle _loadingHandles[stateComp.HandleId]; if (handle.IsDone) { if (handle.Status AsyncOperationStatus.Succeeded) { GameObject loadedPrefab handle.Result; // 获取该实体原本的生成请求信息 if (spawnRequestLookup.TryGetComponent(entity, out SpawnRequest req)) { // 实例化预制体为Entity var prefabEntity state.EntityManager.Instantiate(loadedPrefab); // 设置位置和旋转 var transform SystemAPI.GetComponentRWLocalTransform(prefabEntity); transform.ValueRW.Position req.Position; transform.ValueRW.Rotation req.Rotation; // 标记原始请求实体为“已加载”并清理组件 ecb.AddComponentPrefabLoadedTag(entity); ecb.RemoveComponentAssetLoadingState(entity); ecb.RemoveComponentSpawnRequest(entity); // 注意我们不移除Handle因为实例化的实体还依赖这个资源。 // 应该将Handle与实例化后的实体关联或者使用引用计数。 // 简化处理我们暂时不释放Handle在系统销毁时统一释放仅用于演示。 } stateComp.CurrentStatus AssetLoadingState.Status.Loaded; ecb.SetComponent(entity, stateComp); } else { Debug.LogError($Failed to load asset at address: {stateComp.AssetAddress}); stateComp.CurrentStatus AssetLoadingState.Status.Failed; ecb.SetComponent(entity, stateComp); // 释放失败的Handle Addressables.Release(handle); _loadingHandles.Remove(stateComp.HandleId); } } } } loadingStates2.Dispose(); loadingEntities2.Dispose(); } } // 用于标记加载完成的Tag public struct PrefabLoadedTag : IComponentData, IEnableableComponent { }重要提示上述系统是一个简化版本用于演示核心流程。在生产环境中你需要一个更健壮的Handle生命周期管理系统例如将Handle与实例化后的实体关联使用引用计数当所有关联实体销毁后再释放Handle并且要考虑性能优化比如使用IJobEntity来并行处理部分逻辑但加载启动和完成检查仍需在主线程。3.5 创建触发系统如鼠标点击生成我们需要一个系统来响应玩家输入并创建SpawnRequest。using Unity.Entities; using Unity.Burst; using Unity.Mathematics; using UnityEngine; // 这是一个每帧在FixedStepSimulationSystemGroup中运行的系统 [UpdateInGroup(typeof(FixedStepSimulationSystemGroup))] public partial struct MouseClickSpawnSystem : ISystem { [BurstCompile] public void OnUpdate(ref SystemState state) { // 注意Input.GetMouseButtonDown是主线程API不能在Burst Job中使用。 // 因此我们把这个检查放在ISystem的主线程部分。 // 更规范的做法是使用InputSystem包并创建一个缓冲区来存储输入事件。 // 这里为简化我们直接在主线程查询。 if (Input.GetMouseButtonDown(0)) // 左键点击 { // 简单的屏幕点到世界坐标转换假设主相机有标签“MainCamera” Camera mainCam Camera.main; if (mainCam ! null) { Ray ray mainCam.ScreenPointToRay(Input.mousePosition); // 假设点击到Y0的地平面 float3 groundNormal new float3(0, 1, 0); float3 groundPoint new float3(0, 0, 0); if (math.dot(ray.direction, groundNormal) ! 0) { float t -math.dot(ray.origin - groundPoint, groundNormal) / math.dot(ray.direction, groundNormal); if (t 0) { float3 spawnPos ray.origin ray.direction * t; var ecb new EntityCommandBuffer(Allocator.Temp); // 创建一个新的实体来承载生成请求 Entity requestEntity state.EntityManager.CreateEntity(); ecb.AddComponent(requestEntity, new SpawnRequest { // 使用我们在Addressables中设置的地址 AssetAddress TurretRed, Position spawnPos, Rotation quaternion.identity }); ecb.Playback(state.EntityManager); ecb.Dispose(); } } } } } }3.6 配置与运行测试在场景中创建一个空的GameObject挂载SpawnerAuthoring脚本。在Inspector中将Addressables Groups里的“TurretRed”预制体拖到PrefabToSpawn字段。确保你的场景中有一个标签为“MainCamera”的摄像机。运行游戏。点击地面你应该能看到炮塔预制体被动态加载并实例化在点击位置。至此一个最基础的、基于Addressables的Entities动态加载流程就完成了。你成功告别了SubScene的束缚实现了按需、细粒度的资源加载。4. 高级优化与生产环境实践上面的示例展示了核心原理但要用于实际项目还需要考虑更多。4.1 异步操作Handle的生命周期管理上面的简化系统在OnDestroy时释放所有Handle这很粗糙。正确的做法是实现一个引用计数机制。创建AssetHandleTracker组件附加到每个由Addressables预制体实例化出来的Entity上。public struct AssetHandleLink : IComponentData { public int HandleId; // 关联到PrefabLoadSystem中的_loadingHandles }修改加载系统当实例化成功后不仅将HandleId存储在系统字典里还要给实例化出的Entity添加AssetHandleLink组件。创建资源清理系统监控所有带有AssetHandleLink的Entity。当这些Entity被销毁时通过监听DestroyEntity事件或检查Entity的存活状态递减对应HandleId的引用计数。当某个Handle的引用计数归零时调用Addressables.Release(handle)。使用Addressables.ResourceManager创建可跟踪的HandleAddressables.LoadAssetAsync返回的Handle已经内置了引用计数。每次调用LoadAssetAsync计数1每次调用Release计数-1。我们的AssetHandleLink本质上是在游戏逻辑层面跟踪“谁在使用这个资源”确保在最后一个逻辑使用者消失后才调用Release。4.2 使用BlobAsset存储资源引用频繁使用FixedString比较字符串地址依然有开销。对于已知的、大量的资源可以在启动时使用BlobAsset存储一个资源ID到地址的映射表。创建一个BlobAssetReferenceResourceMapBlob其中ResourceMapBlob包含一个BlobArrayFixedString64Bytes。在初始化系统如BeginInitializationSystemGroup中使用Addressables同步或异步加载所有关键资源的地址列表并构建这个BlobAsset。在SpawnRequest中只需存储一个int类型的ResourceIndex。加载系统通过索引从BlobAsset中获取地址字符串。这完全兼容Burst Job性能极高。4.3 与Entities烘焙Baker深度集成我们之前的SpawnerAuthoring只是在Baking时存储了地址。更高级的做法是利用IBaker接口和IDeclareReferencedPrefabs让Addressables资源也能参与到ECS的Baking依赖链条中。实现IDeclareReferencedPrefabs接口虽然Addressables资源不在构建时直接包含但声明依赖可以确保构建管线知道这些资源的存在对于分析构建大小和依赖关系有帮助。在IBaker.Bake中你可以通过AssetReference的EditorAsset属性仅在编辑器中可用获取到预制体然后使用GetEntity将其转换为一个EntityPrefab引用并存储到BlobAsset或另一个配置实体中。这样运行时就不再需要字符串地址而是直接使用EntityPrefab进行实例化但这要求资源在编辑时是已知的限制了动态性。4.4 错误处理与加载状态反馈生产级系统必须有完善的错误处理。网络加载失败如果资源在远程服务器上需要处理下载失败、重试逻辑。资源地址无效加载前验证地址是否在当前的Addressables资源定位器ResourceLocator中。加载超时为每个加载请求设置超时时间防止因个别资源问题卡死整个加载流程。进度反馈AsyncOperationHandle有PercentComplete属性可以用于更新UI进度条。你需要一个系统将加载进度信息汇总并传递给UI层。4.5 内存与性能考量资源预热对于即将高频使用的资源如主角的武器、常用UI可以在场景加载时或进入特定区域前使用Addressables.LoadAssetAsync进行预加载但不立即实例化。这能避免运行时卡顿。资源卸载策略不要过于激进地释放资源。对于小型、频繁使用的资源如子弹特效可以考虑使用对象池配合Addressables在池子初始化时加载游戏退出时释放。依赖链分析使用Addressables Analyze工具检查资源之间的依赖关系避免因为一个很小的资源改动导致整个资源组需要重新下载。合理规划资源分组是关键。5. 常见问题与调试技巧在实际集成中你肯定会遇到各种问题。这里记录一些典型坑点和解决方法。5.1 “InvalidKey Exception: The address does not exist...”问题运行时加载抛出异常提示地址无效。排查检查地址拼写确保代码中的地址字符串与Addressables Groups窗口中显示的地址完全一致包括大小写和空格。检查资源是否真的被打包在Addressables Groups窗口选择对应的组点击“Build - New Build - Default Build Script”。只有构建后的资源才能在运行时加载。开发模式下可以使用“Play Mode Script”设置为“Use Asset Database”但发布时需要构建。检查运行时初始化确保Addressables系统已初始化。通常第一次调用Addressables.LoadAssetAsync时会自动初始化但有时在非常早的Awake阶段调用可能会出问题。可以在场景启动时手动调用Addressables.InitializeAsync()。5.2 预制体加载成功但实例化后没有渲染或功能异常问题Entity被创建了但看不到模型或者MonoBehaviour脚本失效。排查Hybrid Renderer转换确保你的Addressables预制体已经过Subscene或Baking处理或者其渲染组件如MeshRenderer能被Hybrid Renderer V2识别。最简单的方法是在预制体根节点上添加ConvertToEntity组件并设置“Conversion Mode”为“Convert And Inject”用于动态实例化。这样当Addressables加载该GameObject后ConvertToEntity会自动将其转换为Entity。MonoBehaviour脚本如果预制体上有必须的MonoBehaviour逻辑你需要确保这些脚本也支持ECS。要么将它们重写为ECS的System和Component要么使用GameObjectEntity不推荐是旧版方式或者确保这些脚本在GameObject被实例化后能正确运行它们会作为托管对象存在与ECS实体并行。5.3 内存泄漏资源似乎从未被卸载问题动态创建和销毁了很多实体但游戏内存持续增长。排查检查Handle释放确保为每个LoadAssetAsync调用都配对了Release调用。使用Addressables.ResourceManager.Acquire和Release来手动管理引用计数或者使用Addressables.InstantiateAsync和Addressables.ReleaseInstance后者会自动管理实例与资源的生命周期。使用Profiler打开Unity Profiler的Memory模块查看Asset类型的内存占用。过滤出你的Addressables资源观察其加载和卸载情况。确保当你认为资源应该被卸载时对应的AsyncOperationHandle状态变为Invalid或内存确实下降。注意间接引用即使你释放了主要的GameObject预制体Handle如果这个预制体引用了其他也被标记为Addressables的资源如材质、贴图并且这些资源还被别的Handle引用着它们也不会被卸载。Addressables的依赖管理是自动的但你需要确保根节点的Handle被正确释放。5.4 在Burst Job中无法访问加载的资源问题你希望在Job中读取加载的预制体数据如网格顶点数。解决这是不可能的。通过Addressables加载的UnityEngine.Object如GameObject、Texture是托管对象不能在Burst Job中直接访问。你必须将需要的数据在加载完成后提前提取并复制到ECS组件或BlobAsset中。例如加载一个包含伤害值的ScriptableObject后将其中的数值复制到一个IComponentData中然后这个组件就可以在Job中安全读取了。5.5 构建后资源丢失问题在编辑器下运行正常但打出的包中点击无法生成物体。排查构建包含资源在构建Player之前必须通过Addressables Groups窗口执行“Build - New Build - Default Build Script”。这会根据你的分组设置将资源打包到ServerData目录远程加载或与应用程序一起构建本地加载。构建路径设置检查AddressableAssetSettings在Assets/AddressableAssetsData目录下中的Build Path和Load Path。对于本地加载通常设置为[UnityEngine.AddressableAssets.Addressables.BuildPath]和{UnityEngine.AddressableAssets.Addressables.RuntimePath}。检查构建报告构建完成后会生成一个AddressablesBuildTEP.json文件。打开它检查是否有错误或警告并确认你的“TurretRed”资源是否在构建的资源列表里。5.6 调试利器Addressables Event Viewer菜单栏选择Window - Asset Management - Addressables - Event Viewer。这个工具可以实时查看所有Addressables的加载、释放、缓存事件是诊断资源生命周期问题的神器。如果你怀疑某个资源没被释放在这里可以清晰地看到它的加载和释放记录。6. 性能优化实战从能用到好用基础功能跑通后性能是下一个挑战。目标是实现丝滑的动态加载无卡顿无内存波动。6.1 使用Addressables的异步实例化我们之前的流程是LoadAssetAsync- 获取GameObject -EntityManager.Instantiate。对于频繁实例化的对象如子弹这会产生大量GameObject到Entity的转换开销。Addressables提供了InstantiateAsync方法它内部优化了实例化流程并且返回的AsyncOperationHandleGameObject可以直接用于后续的ReleaseInstance管理起来更简单。修改PrefabLoadSystem的加载成功部分// 替换原有的实例化逻辑 // var prefabEntity state.EntityManager.Instantiate(loadedPrefab); var instantiateHandle Addressables.InstantiateAsync(stateComp.AssetAddress.ToString(), req.Position, req.Rotation); // 需要将instantiateHandle也管理起来并与生成的GameObject/Entity关联InstantiateAsync会直接返回一个场景中的GameObject实例已经过Addressables系统处理。你仍然需要将其转换为Entity如果它上面有ConvertToEntity组件会自动转换或者将其与一个已有的Entity关联。6.2 实现资源池Pooling对于超高频创建销毁的对象即使使用InstantiateAsync也有开销。此时应实现基于Addressables的资源池。预热池子游戏初始化时使用Addressables.LoadAssetAsync加载预制体然后使用Object.Instantiate或Addressables.InstantiateAsync创建指定数量的实例放入池中。从池中获取需要生成时从池中取出一个已存在的实例重置其状态位置、旋转、血量等并SetActive(true)。归还池子对象“销毁”时SetActive(false)并放回池中。关键点池子持有的AsyncOperationHandle永远不释放直到游戏结束或关卡切换。这避免了运行时加载/卸载的开销。注意ECS与GameObject池的混合需要小心。池中的GameObject在“回收”时其对应的Entity应该被销毁EntityManager.DestroyEntity而在“取出”时需要重新运行一次Baking或转换流程来创建新的Entity。或者你可以设计一个系统在Entity被“回收”时只是禁用其渲染和逻辑组件通过SetComponentEnabled而不是销毁Entity本身实现纯ECS层面的对象池。6.3 分帧加载与优先级控制如果一帧内触发加载几十个资源主线程可能会卡住。我们需要将加载请求分散到多帧完成。请求队列在PrefabLoadSystem中维护一个NativeQueueSpawnRequest。当有新的生成请求时不立即启动加载而是入队。分帧处理在OnUpdate中每帧只从队列中取出固定数量如2-5个的请求为其启动加载。这可以通过一个计数器或时间切片来实现。优先级为SpawnRequest增加一个Priority字段。紧急的资源如玩家脚下的特效优先级高可以插队处理。队列可以使用优先队列如NativeList配合排序来实现。6.4 依赖预加载与子场景混合使用完全抛弃SubScene并非总是最佳选择。对于大型静态地形、背景建筑等使用SubScene进行流式加载仍然是最优解。Addressables用于动态实体。两者可以混合SubScene负责大地块将世界划分为多个SubScene用于加载地形、静态网格、光照数据等。Addressables负责动态物敌人、道具、可破坏物体、玩家等全部使用Addressables管理。协同加载当玩家接近一个SubScene区域时同步加载该SubScene并同时预加载这个区域可能用到的Addressables资源如该区域特有的敌人类型。这可以通过在SubScene中放置一个“区域配置”实体来实现该实体包含一个需要预加载的Addressables资源地址列表。这种混合架构结合了两种技术的优点SubScene提供了高效的大规模静态数据流式加载Addressables提供了极致的动态资源灵活性。