1. 项目概述为什么我们需要绕开SubScene如果你正在用Unity的EntitiesECS做项目尤其是那种需要动态加载大量场景、模型、特效资源的游戏或应用那你肯定对SubScene又爱又恨。爱的是它确实提供了一套官方认可的、将GameObject世界与ECS世界桥接起来的方案让复杂的场景数据能够以Entity的形式被运行时系统处理。恨的是它的“束缚感”太强了。SubScene本质上是一个设计时和烘焙时的概念它要求你将资源预先分割并标记为SubScene然后在运行时通过SceneSystem来加载。这个流程在项目结构相对固定时没问题但一旦遇到需要高度动态化的需求——比如开放世界地图的流式加载、根据玩家行为即时生成并加载战斗场景、或者一个内容持续更新的在线游戏——SubScene的局限性就暴露无遗。最大的痛点在于“动态性”不足。虽然Unity提供了异步加载SubScene的API但加载的单位是整个SubScene文件。你很难做到精细到“只加载这个房子里的三把椅子和一个桌子”这种粒度。更麻烦的是资源依赖管理一个SubScene里可能打包了模型、材质、贴图等各种资产你无法在运行时灵活地卸载其中一部分而不影响其他。此外SubScene的烘焙过程也与项目构建流程深度耦合对于需要热更新资源或者使用AssetBundle分发内容的项目来说这套机制显得笨重且不够灵活。所以这个项目的目标很明确为Unity Entities 1.0.16设计一套简易的、不依赖SubScene的动态资源加载方案。我们不是要完全取代SubScene而是要在它力所不及的“动态、细粒度”加载场景下提供一个补充方案。这套方案的核心思想是绕过SubScene的烘焙和加载流程直接操作Unity的底层资源加载接口如Addressables或Resources并将加载得到的GameObject或Prefab在运行时动态地转换为ECS的Entity和Component数据。这样一来我们就能获得近乎无限的灵活性可以按需加载任意Prefab可以独立管理每个资源的生命周期可以轻松适配AssetBundle和热更新。2. 核心思路与架构设计2.1 技术选型为什么是Addressables要实现动态加载我们首先得选一个资源管理系统。Unity提供了几种选择古老的Resources、相对现代的AssetBundleAPI、以及官方主推的Addressables可寻址资源系统。Resources简单粗暴但所有东西都打包在一个巨大的文件里无法增量更新内存管理不精细基本被淘汰于生产环境。原始AssetBundle功能强大但API较为底层需要开发者自己处理依赖、打包、加载、卸载等全套生命周期容易出错。Addressables可以看作是AssetBundle的上层封装和最佳实践集成。它提供了基于标签Address的加载方式自动处理依赖关系内置了内存管理和缓存策略并且与Unity的构建管线、Cloud Content Delivery都有很好的集成。对于我们的动态ECS资源加载来说Addressables的异步加载、依赖跟踪和按需卸载特性正是我们所需要的。因此本方案将基于Addressables作为资源加载层。这并不意味着你不能用AssetBundle只是用Addressables会更省心、更稳健。2.2 架构总览从Addressable到Entity的转换流水线我们的方案可以看作一个简易的“转换流水线”核心步骤如下图所示概念流程非代码[Addressables系统] --(异步加载)-- [GameObject/Prefab实例] --(运行时转换)-- [ECS Entity Components]资源准备阶段将需要动态加载的Prefab或场景资产通过Unity编辑器标记为Addressables并设置好标签Address和分组策略。运行时加载阶段在ECS的某个System例如一个ResourceLoadingSystem中根据业务逻辑如玩家位置发出加载请求。请求中包含资源的Address。异步加载与实例化使用Addressables的LoadAssetAsync和InstantiateAsyncAPI异步获取Prefab并实例化到世界中。注意此时生成的是传统的GameObject。ECS转换阶段这是最关键的一步。我们需要将实例化出来的GameObject其身上的组件数据转换到ECS的Entity和Component中。这需要借助IConvertGameObjectToEntity接口或我们自定义的转换逻辑。清理与卸载当某个动态实体不再需要时我们销毁对应的ECS Entity。同时需要通知Addressables系统释放对应的GameObject实例和可能缓存的资产防止内存泄漏。整个架构的核心是一个资源加载与生命周期管理系统它负责协调Addressables的加载/卸载并触发GameObject到Entity的转换。这个系统本身可以是一个标准的ECSSystemBase。2.3 关键挑战与应对策略挑战一异步加载与ECS同步执行的矛盾。ECS的System默认在OnUpdate里同步执行而资源加载是异步操作。我们不能在OnUpdate里等待异步操作完成这会卡住主线程。策略使用EntityCommandBufferECB和“状态组件”。创建一个LoadResourceRequest组件附加到一个“加载代理”Entity上。在ResourceLoadingSystem中检测带有此组件的Entity发起异步加载。异步回调函数中再通过ECB或直接操作EntityManager来创建目标Entity并添加数据最后移除请求组件或标记完成。挑战二GameObject到Entity的高效转换。手动为每个Prefab写转换代码不现实。策略利用Unity提供的GameObjectConversionUtility或自定义的转换逻辑。更通用的做法是要求所有需要动态加载的Prefab都挂载一个自定义的Authoring组件例如DynamicEntityAuthoring这个组件上配置了需要转换为哪些ECS的IComponentData。在运行时转换时读取这个Authoring组件的信息来动态构造目标Entity。挑战三依赖与复合实体的加载。一个“坦克”Prefab可能依赖“炮弹”Prefab或者一个“房间”实体由“墙”、“门”、“家具”多个子实体组成。策略对于资源依赖材质、贴图Addressables已经自动处理。对于实体间的逻辑依赖或组合关系我们需要在自定义的Authoring组件中定义。例如DynamicEntityAuthoring可以有一个列表里面是子实体的Address。在父实体加载完成后再发起子实体的加载请求并通过一个Parent组件或LinkedEntityGroup来维护层级关系。3. 核心模块实现详解3.1 定义资源请求与状态组件首先我们需要一套ECS组件来表述“加载请求”和“加载状态”。using Unity.Entities; // 标记一个Entity为动态加载的实体并指向其资源地址 public struct DynamicEntityTag : IComponentData {} // 加载请求组件附加到“加载代理”Entity上 public struct LoadResourceRequest : IComponentData { public FixedString64Bytes Address; // Addressables的地址 // 可以添加更多信息如加载优先级、加载后父Entity的ID等 } // 加载状态组件用于跟踪异步操作 public struct ResourceLoadingState : IComponentData { public enum Phase { None, Loading, Instantiated, Converting, Done, Error } public Phase CurrentPhase; public Entity TargetEntity; // 加载完成后要附加数据的Entity可能先创建空Entity public UnityEngine.ResourceManagement.AsyncOperations.AsyncOperationHandleUnityEngine.GameObject? LoadHandle; }LoadResourceRequest是发起加载的“指令”ResourceLoadingState是跟踪加载过程的“记事本”。我们通常会创建一个没有任何渲染组件的“服务性”Entity来携带这些组件专门用于处理加载逻辑。3.2 实现资源加载系统 (ResourceLoadingSystem)这个SystemBase是整个方案的大脑运行在SimulationSystemGroup中。using Unity.Entities; using Unity.Collections; using UnityEngine; using UnityEngine.ResourceManagement.AsyncOperations; [UpdateInGroup(typeof(SimulationSystemGroup))] public partial class ResourceLoadingSystem : SystemBase { private BeginSimulationEntityCommandBufferSystem.Singleton _ecbSingleton; protected override void OnCreate() { base.OnCreate(); _ecbSingleton World.GetExistingSystemManagedBeginSimulationEntityCommandBufferSystem.Singleton(); } protected override void OnUpdate() { var ecb _ecbSingleton.CreateCommandBuffer(); var entityManager EntityManager; // 1. 处理新的加载请求 Entities .WithAllLoadResourceRequest() .WithNoneResourceLoadingState() .ForEach((Entity requestEntity, in LoadResourceRequest request) { // 为这个请求创建一个状态跟踪组件 entityManager.AddComponentData(requestEntity, new ResourceLoadingState { CurrentPhase ResourceLoadingState.Phase.Loading, TargetEntity entityManager.CreateEntity(), // 先创建目标空Entity LoadHandle null }); // 使用Addressables异步加载Prefab var loadHandle Addressables.LoadAssetAsyncGameObject(request.Address.ToString()); // 注册回调注意这里需要捕获必要的上下文如requestEntity, ecb // 由于ECS的约束我们不能直接在回调里操作EntityManager需要将回调信息“转发”回主线程。 // 一种常见做法是将handle存储起来在后续的Update中轮询状态。 var newState entityManager.GetComponentDataResourceLoadingState(requestEntity); newState.LoadHandle loadHandle; entityManager.SetComponentData(requestEntity, newState); // 移除请求组件防止重复处理 ecb.RemoveComponentLoadResourceRequest(requestEntity); }).WithoutBurst().Run(); // 注意Addressables API不是Burst兼容的需要WithoutBurst() // 2. 轮询正在进行的加载操作 Entities .WithAllResourceLoadingState() .ForEach((Entity stateEntity, ref ResourceLoadingState state) { if (state.LoadHandle.HasValue state.LoadHandle.Value.IsValid()) { var handle state.LoadHandle.Value; if (handle.IsDone) { if (handle.Status AsyncOperationStatus.Succeeded) { var prefab handle.Result; // 实例化GameObject var goInstance GameObject.Instantiate(prefab); // 开始转换阶段 ConvertGameObjectToEntity(goInstance, state.TargetEntity, entityManager); state.CurrentPhase ResourceLoadingState.Phase.Instantiated; // 可以在这里触发转换完成的事件或者由另一个System处理转换后的逻辑 } else { Debug.LogError($Failed to load resource at address. Error: {handle.OperationException}); state.CurrentPhase ResourceLoadingState.Phase.Error; // 清理目标Entity ecb.DestroyEntity(state.TargetEntity); } // 释放加载Handle注意Instantiate的实例需要单独管理释放 Addressables.Release(handle); state.LoadHandle null; // 加载流程结束可以销毁这个状态Entity或标记完成 ecb.AddComponentResourceLoadCompleteTag(state.TargetEntity); ecb.DestroyEntity(stateEntity); } } }).WithoutBurst().Run(); } private void ConvertGameObjectToEntity(GameObject go, Entity targetEntity, EntityManager entityManager) { // 这里是转换的核心。 // 方案A如果Prefab上挂载了实现了IConvertGameObjectToEntity的MonoBehaviour var converters go.GetComponentsInChildrenIConvertGameObjectToEntity(); foreach (var converter in converters) { // 注意我们需要一个临时的GameObjectEntity或自定义的转换上下文。 // 由于是运行时不能直接用GameObjectConversionUtility.ConvertGameObjectHierarchy。 // 更实用的做法是我们自定义一个运行时转换组件。 } // 方案B推荐使用自定义的运行时转换组件 var dynamicAuthoring go.GetComponentDynamicEntityAuthoring(); if (dynamicAuthoring ! null) { dynamicAuthoring.Convert(targetEntity, entityManager, this.World); } else { Debug.LogWarning($GameObject {go.name} has no DynamicEntityAuthoring component. Only basic Transform may be converted.); } // 无论如何销毁原始的GameObject因为我们只需要ECS数据 GameObject.Destroy(go); } }注意上面的ConvertGameObjectToEntity方法是一个简化示意。直接使用IConvertGameObjectToEntity在运行时并不直接支持因为该接口通常用于SubScene烘焙时。我们需要方案B自定义DynamicEntityAuthoring。3.3 创建运行时转换组件 (DynamicEntityAuthoring)这是一个MonoBehaviour用于在Prefab上配置它应该转换成哪些ECS组件。using UnityEngine; using Unity.Entities; using System.Collections.Generic; public class DynamicEntityAuthoring : MonoBehaviour, IConvertGameObjectToEntity { // 配置示例你可以在这里暴露一些字段用于生成ECS组件 public float Health 100f; public float Speed 5f; public GameObject[] SubEntityPrefabs; // 子实体Prefab需要也是Addressables // 这个方法在Prefab被Addressables加载并实例化后由我们的ResourceLoadingSystem调用 public void Convert(Entity entity, EntityManager dstManager, World world) { // 1. 添加必要的ECS组件 // 例如添加一个标识组件 dstManager.AddComponentData(entity, new DynamicEntityTag()); // 2. 根据MonoBehaviour上的配置添加对应的IComponentData dstManager.AddComponentData(entity, new Health { Value Health }); dstManager.AddComponentData(entity, new MoveSpeed { Value Speed }); // 3. 添加渲染相关的组件如果Prefab有Renderer // 这里需要从GameObject上提取信息并注册到ECS渲染系统如RenderMesh。 // 这是一个复杂步骤通常需要借助RenderMeshUtility等API。 // 为了简化我们可以要求Prefab上有一个特定的组件来持有这些渲染信息。 var renderer GetComponentInChildrenRenderer(); if (renderer ! null) { var meshFilter GetComponentInChildrenMeshFilter(); if (meshFilter ! null) { // 这是一个非常简化的示例实际生产环境请使用更健壮的渲染实体创建方式 // RenderMeshUtility.AddComponents(entity, dstManager, new RenderMeshDescription(...)); } } // 4. 处理子实体可选异步加载 // 可以将子实体的加载请求发送到ResourceLoadingSystem var requestSystem world.GetExistingSystemManagedResourceLoadingSystem(); foreach (var subPrefab in SubEntityPrefabs) { // 需要一种方式获取子Prefab的Addressables地址 // 假设我们通过一个自定义组件存储了地址 var subAuthoring subPrefab.GetComponentDynamicEntityAuthoring(); if (subAuthoring ! null !string.IsNullOrEmpty(subAuthoring.AssetAddress)) { // 创建子实体加载请求Entity var requestEntity dstManager.CreateEntity(); dstManager.AddComponentData(requestEntity, new LoadResourceRequest { Address subAuthoring.AssetAddress }); // 还可以添加一个ParentLink组件到请求上以便加载后建立父子关系 dstManager.AddComponentData(requestEntity, new ParentLink { Parent entity }); } } } // 用于在编辑器模式下配合SubScene烘焙流程可选 void IConvertGameObjectToEntity.Convert(Entity entity, EntityManager dstManager, GameObjectConversionSystem conversionSystem) { // 如果这个Prefab也会用于SubScene烘焙可以在这里实现相同的转换逻辑 // 确保数据一致性。但我们的动态加载方案不依赖此方法。 Convert(entity, dstManager, conversionSystem.World); } }这个DynamicEntityAuthoring组件是连接PrefabGameObject和ECSEntity的桥梁。它定义了转换规则。3.4 发起一个加载请求在游戏逻辑中当你需要动态生成一个东西时你不再直接Instantiate一个Prefab而是创建一个加载请求Entity。// 在某个ECS System或MonoBehaviour中 EntityManager entityManager World.DefaultGameObjectInjectionWorld.EntityManager; Entity requestEntity entityManager.CreateEntity(); entityManager.AddComponentData(requestEntity, new LoadResourceRequest { Address Assets/Prefabs/Enemies/Goblin.prefab // Addressables的地址 });ResourceLoadingSystem会捕获这个请求开始异步加载、实例化、转换的完整流程。加载完成后一个带有Health、MoveSpeed和DynamicEntityTag组件的ECS实体就出现在你的世界里了可以被其他ECS System如移动系统、战斗系统处理。4. 进阶优化与生产环境考量4.1 资源生命周期与内存管理这是本方案最容易出问题的地方。Addressables的加载LoadAssetAsync和实例化InstantiateAsync会产生不同的AsyncOperationHandle需要分别管理。加载Handle在LoadAssetAsync完成后如果不再需要加载其他相同资产可以调用Addressables.Release(loadHandle)。这会减少内部引用计数当计数为0时底层AssetBundle可能会被卸载。实例HandleInstantiateAsync返回的Handle代表这个具体的GameObject实例。这个实例在被我们的系统转换成Entity并销毁原GameObject后其对应的资源Prefab引用可能还被其他实例或缓存持有。我们需要在动态实体被销毁时通知Addressables释放这个实例。策略在DynamicEntityAuthoring.Convert方法中或者在创建实体后为Entity添加一个自定义组件如AddressableInstanceHandle用来存储InstantiateAsync返回的Handle。当这个Entity被销毁时通过一个DestroyEntity事件或一个System来检测取出这个Handle并调用Addressables.ReleaseInstance(gameObject)。注意我们销毁的是转换后的GameObject但释放的是实例Handle。public struct AddressableInstanceHandle : IComponentData { // 这里不能直接存储UnityEngine.Object的引用因为IComponentData需要是blittable类型。 // 我们需要一个间接的存储方式例如一个唯一的ID然后在一个MonoBehaviour或另一个非ECS系统中管理一个字典来映射ID和实际的Handle。 // 更简单但不够ECS的做法是在转换完成后立即释放实例Handle因为我们不再需要那个GameObject了。 // 前提是Prefab资产本身还通过LoadHandle被缓存着。 }实操心得对于简单的项目可以在ConvertGameObjectToEntity的最后Destroy(go)之后立即调用Addressables.ReleaseInstance(go)。但这要求Prefab资产本身必须通过LoadAssetAsync被缓存即另一个Handle持有否则资源会被立即卸载导致后续无法再实例化。更稳健的做法是建立一个简单的引用计数管理器。4.2 依赖加载与复合实体前面提到了子实体加载。一个更优雅的模式是使用“配方”Recipe或“实体原型”Entity Archetype的概念。DynamicEntityAuthoring不再直接持有子Prefab引用而是持有一个“配方ID”或“原型ID”。ResourceLoadingSystem加载完父实体后根据这个ID去查询一个DynamicEntityRecipe组件这是一个SharedComponentData或存储在BlobAsset中的数据结构这个配方里定义了需要加载的所有子资源地址及其相对位置/逻辑关系。然后系统批量发起子实体的加载请求并最终将它们链接起来。4.3 与现有渲染管线如Entities Graphics集成如果你的项目使用了Entities Graphics以前叫Hybrid Renderer V2进行渲染那么动态实体的渲染设置会复杂一些。你需要确保转换后的Entity拥有正确的渲染组件如RenderMesh、MaterialMeshInfo、WorldRenderBounds等并且这些组件的数据需要从原始GameObject的MeshFilter和Renderer中提取。Unity提供了RenderMeshUtility.AddComponents等API来帮助创建渲染实体。你需要在DynamicEntityAuthoring.Convert方法中调用这些API。一个常见的做法是在Prefab上添加一个额外的RenderMeshAuthoring组件这个组件负责在转换时收集所有必要的渲染信息Mesh, Material, SubMesh等并调用RenderMeshUtility来设置目标Entity。// 伪代码示例 var renderAuthoring GetComponentRenderMeshAuthoring(); if (renderAuthoring ! null) { var renderMeshDescription new RenderMeshDescription(...); // 填充数据 var renderMeshArray new RenderMeshArray(...); // 填充材质和网格 RenderMeshUtility.AddComponents(entity, dstManager, renderMeshDescription, renderMeshArray); }4.4 性能考量与System设计异步操作与主线程Addressables的API和GameObject.Instantiate都在主线程执行。我们的ResourceLoadingSystem使用了WithoutBurst().Run()这会导致主线程的Jobs。对于大量加载请求可能会造成卡顿。优化将加载请求队列化每帧只处理固定数量的请求。或者探索使用Addressables的Task异步模式并结合ECS的EntityCommandBufferSystem在合适的时机如EndSimulationEntityCommandBufferSystem处理回调结果减少对主线程OnUpdate的阻塞。实体创建风暴一次性加载上百个实体并立即转换可能会在单帧内产生大量EntityManager操作造成性能尖峰。优化在ResourceLoadingSystem中实现分帧转换。将“转换”阶段也做成一个状态每帧只转换固定数量的GameObject实例平滑性能消耗。5. 常见问题与排查技巧实录问题1加载后实体在场景中看不到没有渲染。排查首先检查Entity是否成功创建并拥有DynamicEntityTag等逻辑组件。然后检查是否成功添加了渲染组件如RenderMesh。使用Unity的Entities Debugger窗口查看Entity的组件构成。技巧在DynamicEntityAuthoring.Convert方法中添加一个临时的Debug.Log输出转换的Entity的Index和Version确认转换被调用。同时检查Prefab上的Mesh和Material是否已正确标记为Addressables并且其依赖也被打包。问题2内存泄漏资源似乎没有被卸载。排查使用Unity Profiler的Memory模块查看AssetBundle和Object的引用情况。重点检查AsyncOperationHandle是否被正确释放。确保对InstantiateAsync返回的Handle调用了ReleaseInstance并且对LoadAssetAsync的Handle在适当的时候如所有实例都销毁后调用Release。技巧为你的ResourceLoadingSystem添加一个调试模式记录所有活跃的Handle及其状态。在游戏退出或场景切换时强制释放所有Handle。问题3异步加载过程中游戏对象被销毁如场景切换导致回调出错。排查在所有的异步操作回调中第一步先检查MonoBehaviour或相关上下文是否已被销毁this null或!enabled。在ECS中我们需要检查承载状态的Entity是否还存在。技巧在ResourceLoadingState组件中增加一个CancellationToken的标识如一个bool Cancel字段。当需要取消加载时如玩家快速离开某个区域设置这个标识。在轮询加载状态的System中如果发现Cancel为真则立即释放Handle并清理相关Entity。问题4转换后的实体没有物理碰撞。排查物理碰撞Physics在Entities中通常通过PhysicsShape和PhysicsBody等组件表示。我们的动态加载方案只处理了基本的渲染和逻辑组件。物理组件需要额外的转换逻辑。技巧扩展DynamicEntityAuthoring让它也能读取GameObject上的Collider组件并生成对应的PhysicsShapeAuthoring数据或直接添加PhysicsShape组件。这需要你深入了解Unity的Physics for Entities即Unity Physics的运行时组件创建流程。一个可行的办法是参考Unity Physics包中ColliderAuthoring组件的实现将其转换逻辑适配到我们的运行时环境中。问题5在编辑器模式下运行正常打包后加载失败。排查Addressables的构建和部署路径问题。确保在打包前已经通过Addressables Groups窗口正确构建了资源包Build - New Build - Default Build Script。构建后检查ServerData文件夹如果使用本地加载或远程加载地址是否正确。技巧在运行时先尝试加载一个非常简单的、已知的Addressables资源如一个文本文件来测试整个Addressables加载路径是否畅通。使用Addressables.InitializeAsync()的返回值来确保初始化完成。在加载失败的回调中详细打印错误信息和操作句柄的状态。这套“动态资源加载”方案本质上是在ECS的纯净数据和Unity传统的资产管线之间架起一座桥梁。它牺牲了一点SubScene带来的“开箱即用”的便利性换来了极大的灵活性和对动态场景的掌控力。在实际项目中你可以根据复杂度逐步完善这个方案例如加入资源池、预加载、优先级队列等高级特性。记住没有银弹SubScene和动态加载方案往往是共存的用SubScene处理静态的、大型的背景场景用动态加载方案处理游戏逻辑中频繁创建销毁的角色、道具和特效才能发挥各自的最大优势。
