1. 问题现象与核心痛点最近在做一个Unity项目用上了ECS框架本来想着能靠这套数据驱动、面向数据的架构把性能优化一下结果踩了个不大不小的坑。具体表现是我在一个叫GameScene的场景里写了一个专门处理玩家输入和移动的PlayerMovementSystem。这个系统只在GameScene里需要逻辑也绑定了这个场景里的特定实体。但是当我切换到另一个完全无关的菜单场景MenuScene时控制台居然还在刷PlayerMovementSystem的日志甚至尝试去查找那些在MenuScene里根本不存在的玩家实体导致了一堆空引用和逻辑错误。这问题乍一看有点反直觉。按照我们传统的MonoBehaviour思维脚本是挂在GameObject上的场景一卸载GameObject没了脚本自然也就停止运行了。但ECS的System不是这么玩的。它是一个全局的、持续运行的逻辑处理器。一旦你通过World.CreateSystem或者依赖注入的方式创建了一个System并且把它添加到了某个ComponentSystemGroup比如默认的SimulationSystemGroup里它就会在每一帧都被调用除非你显式地禁用它或者把它从组里移除。这个“默认启动”的特性就是问题的根源。对于刚接触ECS的开发者来说这很容易造成困扰。我们可能会下意识地认为System是“场景相关”的但实际上ECS的World和System的生命周期通常是独立于Unity场景的。你的游戏可能只有一个World所有System都在里面跑场景切换只是Entity的创建和销毁并不会自动管理System的启停。如果不处理好System的按需启用轻则浪费CPU周期执行无用的查询重则引发运行时异常破坏游戏状态。2. ECS System生命周期与场景管理机制剖析要彻底解决这个问题我们得先抛开MonoBehaviour那套基于GameObject的生命周期观念深入理解ECS架构下System是如何被驱动和管理的。2.1 System的注册与执行流在Unity ECS这里主要指Entities包中核心的调度单位是World。一个World包含了一系列的ComponentSystemGroup系统组而我们的System就生活在这些组里。最常见的几个默认组按执行顺序排列是InitializationSystemGroup: 每帧最早执行用于初始化逻辑。SimulationSystemGroup: 每帧执行一次是游戏逻辑的主要场所。PresentationSystemGroup: 在SimulationSystemGroup之后执行通常用于和渲染相关的逻辑。当你创建一个继承自SystemBase的类并为其添加[UpdateInGroup(typeof(SimulationSystemGroup))]特性时这个System就会被自动注册到SimulationSystemGroup中。从这一刻起只要这个World存在并且该系统所在的组被更新这个System的OnUpdate()方法就会每帧被调用。// 一个典型的System默认会在SimulationSystemGroup中每帧运行 [UpdateInGroup(typeof(SimulationSystemGroup))] public partial class PlayerMovementSystem : SystemBase { protected override void OnUpdate() { // 这里的逻辑会在每一帧执行无论当前是什么场景 Entities.ForEach((ref Translation trans, in PlayerInput input) { // 移动逻辑... }).ScheduleParallel(); } }关键点在于这个注册和启动过程通常发生在游戏启动初期例如在某个启动场景的初始化脚本中并且与具体的业务场景Scene无关。Unity的场景加载SceneManager.LoadScene只会影响场景中的GameObject和由它转换而来的Entity但不会去干预已经存在于World中的System的运行状态。2.2 场景Scene在ECS中的真实含义在纯粹的ECS视角下Unity的“场景”文件.unity主要是一个数据和资源的组织与序列化工具。当你加载一个场景时ECS做的事情是反序列化场景中所有包含ConvertToEntity组件的GameObject。根据这些组件上配置的转换设置Convert And Destroy, Convert And Inject等将GameObject及其子物体转换为一个或多个Entity并挂载相应的ECS组件。原始GameObject可能被销毁如果选择了Convert And Destroy。这个过程并不包含对现有System的“暂停”、“停止”或“销毁”操作。System就像一个不知疲倦的工人只要工厂World还在运转它就会一直工作不管流水线上现在生产的是产品AGameScene的实体还是产品BMenuScene的实体。如果这个工人System的工作指令OnUpdate中的查询只适用于产品A那么当流水线上是产品B时它要么在做无用功要么就会因为找不到合适的零件实体而出错。3. 解决方案精准控制System的启停理解了问题的本质是“System生命周期与场景生命周期脱钩”解决方案就清晰了我们需要建立一种机制让System能够感知场景状态并据此决定自己是运行还是休眠。这里有几种不同粒度和复杂度的方案。3.1 方案一基于标签组件的开关推荐这是最符合ECS思想、也最灵活的一种方式。其核心思想是为System添加一个条件只有当场景中存在某个代表“场景状态”的标签组件时System才执行逻辑。步骤一定义场景状态标签组件首先我们创建一些空的IComponentData作为不同场景的标识。// 标记当前处于游戏场景 public struct GameSceneTag : IComponentData { } // 标记当前处于菜单场景 public struct MenuSceneTag : IComponentData { } // 可以扩展更多如LoadingSceneTag, CutsceneTag等步骤二创建场景管理System我们需要一个专门的System来管理这些标签的添加和移除。这个System可以放在InitializationSystemGroup中在每帧最早执行。[UpdateInGroup(typeof(InitializationSystemGroup))] [UpdateBefore(typeof(BeginInitializationEntityCommandBufferSystem))] public partial class SceneStateManagementSystem : SystemBase { private EntityQuery _gameSceneQuery; private EntityQuery _menuSceneQuery; private EntityQuery _sceneStateTagQuery; protected override void OnCreate() { // 查询是否已经存在场景状态标签 _sceneStateTagQuery GetEntityQuery( ComponentType.ReadWriteGameSceneTag(), ComponentType.ReadWriteMenuSceneTag() ); // 这里假设你的不同场景有一个特定的“场景控制器”实体并挂载了可区分的组件。 // 例如GameScene有一个GameSceneController组件MenuScene有MenuSceneController。 _gameSceneQuery GetEntityQuery(ComponentType.ReadOnlyGameSceneController()); _menuSceneQuery GetEntityQuery(ComponentType.ReadOnlyMenuSceneController()); RequireForUpdate(EntityQuery.Union(_gameSceneQuery, _menuSceneQuery)); } protected override void OnUpdate() { var ecb new EntityCommandBuffer(WorldUpdateAllocator); // 先清除所有旧的场景标签 ecb.RemoveComponentGameSceneTag(_sceneStateTagQuery); ecb.RemoveComponentMenuSceneTag(_sceneStateTagQuery); // 根据当前活跃的场景控制器添加新的场景标签 // 我们假设一次只激活一个场景所以用if-else if (!_gameSceneQuery.IsEmpty) { // 如果存在GameScene控制器则添加GameSceneTag // 通常我们会创建一个单例实体来持有这个标签 var sceneStateEntity GetSingletonEntityGameSceneTag(); ecb.AddComponentGameSceneTag(sceneStateEntity); // 同时可以移除可能存在的其他场景标签确保唯一性 ecb.RemoveComponentMenuSceneTag(sceneStateEntity); } else if (!_menuSceneQuery.IsEmpty) { // 如果存在MenuScene控制器则添加MenuSceneTag var sceneStateEntity GetSingletonEntityMenuSceneTag(); ecb.AddComponentMenuSceneTag(sceneStateEntity); ecb.RemoveComponentGameSceneTag(sceneStateEntity); } ecb.Playback(EntityManager); } // 一个辅助方法获取或创建单例标签实体 private Entity GetSingletonEntityT() where T : struct, IComponentData { var query GetEntityQuery(ComponentType.ReadWriteT()); if (query.CalculateEntityCount() 0) { // 如果不存在则创建一个 return EntityManager.CreateEntity(typeof(T)); } // 如果已存在返回第一个应该是唯一的 return query.GetSingletonEntity(); } }注意上面的GetSingletonEntity方法是一个简化示例。在实际项目中你可能需要更健壮的单例实体管理比如使用EntityQueryBuilder来确保唯一性或者使用World.GetOrCreateSystem来获取一个专门管理全局状态的System。这里为了清晰展示逻辑做了简化。步骤三修改业务System使其依赖场景标签现在我们可以修改PlayerMovementSystem让它只在GameSceneTag存在时才执行核心逻辑。[UpdateInGroup(typeof(SimulationSystemGroup))] public partial class PlayerMovementSystem : SystemBase { private EntityQuery _gameSceneTagQuery; protected override void OnCreate() { // 创建查询查找是否存在GameSceneTag _gameSceneTagQuery GetEntityQuery(ComponentType.ReadOnlyGameSceneTag()); // 如果不需要在非游戏场景下做任何事可以在这里设置RequireForUpdate // RequireForUpdate(_gameSceneTagQuery); // 这样如果没有标签OnUpdate就不会被调用 } protected override void OnUpdate() { // 方案A在OnUpdate开头判断如果不在游戏场景则直接返回 if (_gameSceneTagQuery.IsEmpty) { return; // 菜单场景不执行任何逻辑 } // 方案B使用RequireForUpdate后能走到这里说明一定在游戏场景 // 以下是正常的业务逻辑 float deltaTime Time.DeltaTime; Entities .WithAllGameSceneTag() // 也可以在这里加一个WithAll确保只处理游戏场景的实体如果实体也打了标签 .ForEach((ref Translation trans, in PlayerInput input, in MoveSpeed speed) { float3 moveDir new float3(input.Horizontal, 0, input.Vertical); trans.Value moveDir * speed.Value * deltaTime; }).ScheduleParallel(); } }这种方案的优点解耦清晰场景管理System只负责打标签业务System只负责读标签。两者职责分明。灵活性强可以轻松扩展支持多个场景、子状态如游戏中的暂停状态PausedTag。性能高效EntityQuery.IsEmpty的判断开销极低。使用RequireForUpdate则连调度开销都省了。符合ECS范式完全利用组件查询来控制逻辑流。3.2 方案二手动启用/禁用System如果你希望更直接地控制System可以手动调用System.Enabled属性。你可以在场景加载/卸载的边界点例如使用SceneManager.sceneLoaded事件来操作。步骤一获取System实例你需要能够引用到你的System。可以通过World.GetOrCreateSystem来获取。public class SceneLoaderHelper : MonoBehaviour { private World _defaultWorld; private PlayerMovementSystem _playerMovementSystem; void Start() { _defaultWorld World.DefaultGameObjectInjectionWorld; _playerMovementSystem _defaultWorld.GetOrCreateSystemPlayerMovementSystem(); SceneManager.sceneLoaded OnSceneLoaded; } void OnSceneLoaded(Scene scene, LoadSceneMode mode) { if (scene.name GameScene) { _playerMovementSystem.Enabled true; } else if (scene.name MenuScene) { _playerMovementSystem.Enabled false; } } void OnDestroy() { SceneManager.sceneLoaded - OnSceneLoaded; } }步骤二在System中处理禁用状态即使System被禁用它的OnCreate和OnDestroy仍然会被调用。但OnUpdate不会。你可以在OnUpdate里再加一层判断但通常Enabledfalse就够了。protected override void OnUpdate() { // 即使Enabledtrue也可以在这里加额外判断双保险 if (!Enabled) return; // ... 业务逻辑 }这种方案的优缺点优点控制非常直接和绝对。System的OnUpdate根本不会被调度。缺点依赖MonoBehaviour需要借助SceneManager等Unity引擎层面的API与ECS的纯数据驱动理念有些背离。管理繁琐每个需要场景控制的System都需要在这里注册和手动开关容易遗漏。时机问题sceneLoaded事件触发时场景的Entity转换可能尚未完成直接启用依赖这些Entity的System可能导致首帧错误。3.3 方案三动态创建与销毁System不推荐理论上你可以在进入某个场景时创建并注册所需的System在离开时销毁它。但这在实践中非常棘手且容易出错。创建复杂System之间可能有依赖关系通过[UpdateBefore],[UpdateAfter]动态创建需要处理好这些依赖的排序。状态丢失System内部可能维护着一些状态缓存、计时器等销毁意味着状态丢失下次创建需要重新初始化。性能开销频繁创建和销毁System会带来不必要的内存分配与GC压力。 除非有非常特殊的需求否则不建议采用这种方案。4. 方案对比与选型建议特性方案一标签组件方案二手动启用/禁用方案三动态创建销毁ECS纯度高完全基于组件查询中依赖MonoBehaviour桥接低违背System作为长期处理器设计控制粒度细可精确到每帧、每个查询粗整个System的开关粗整个System的生命周期灵活性高易于扩展多场景、复合状态中需修改多处管理代码低依赖关系管理复杂性能最优仅增加一个轻量查询优系统调度被跳过差创建销毁开销大代码复杂度中需要设计状态组件和管理System低逻辑简单直接高需要处理依赖和状态持久化推荐度★★★★★★★★☆☆★☆☆☆☆个人实操心得与建议 对于大多数项目我强烈推荐方案一标签组件。它虽然前期需要多写一个状态管理System但带来的好处是长期的架构清晰场景状态变成了数据组件所有System都通过查询数据来决定行为这是最地道的ECS开发模式。利于测试你可以非常方便地在测试中通过添加或移除标签组件来模拟不同的场景状态而不必真的加载场景。便于调试在Entity Debugger中你可以一眼就看到当前生效的场景标签是哪个状态一目了然。无缝支持复杂状态比如你可以很容易地实现“在游戏场景中但处于暂停菜单”这种嵌套状态只需同时拥有GameSceneTag和PausedTag然后让某些System同时要求这两个标签另一些System只要求GameSceneTag而忽略PausedTag。方案二可以作为快速原型开发时的临时方案或者用于控制一些绝对不需要在特定场景运行的、开销极大的后台System如某些AI计算。方案三则基本应该避免。5. 高级技巧与常见陷阱5.1 处理“单例”场景状态实体在方案一中我们提到了使用一个“单例实体”来持有场景标签。确保这个实体唯一且易于访问很重要。除了上面示例中的简易方法更常见的做法是使用一个专门的Singleton组件和一个System来保障它。// 定义一个空的单例标记组件 public struct SceneStateSingleton : IComponentData { } // 在SceneStateManagementSystem的OnCreate或OnUpdate中确保它存在 Entity sceneStateEntity; if (!TryGetSingletonEntitySceneStateSingleton(out sceneStateEntity)) { sceneStateEntity EntityManager.CreateEntity(typeof(SceneStateSingleton)); // 可以在这里初始化默认场景标签 EntityManager.AddComponentData(sceneStateEntity, new MenuSceneTag()); } // 后续对GameSceneTag/MenuSceneTag的增删都针对这个sceneStateEntity操作这样可以保证全局只有一个地方存储场景状态避免歧义。5.2 System之间的执行顺序依赖当你引入了SceneStateManagementSystem后必须确保它在所有依赖场景状态的业务System之前执行。这是通过[UpdateInGroup]和[UpdateBefore/After]特性实现的。// 场景状态管理系统必须在最早执行 [UpdateInGroup(typeof(InitializationSystemGroup))] [UpdateBefore(typeof(BeginInitializationEntityCommandBufferSystem))] // 在ECB系统之前更新状态 public partial class SceneStateManagementSystem : SystemBase { ... } // 业务系统依赖该状态在Simulation组中但无需指定Before/After因为不在同一个组。 // 只要SceneStateManagementSystem在Initialization组更新完了Simulation组就能读到最新状态。 [UpdateInGroup(typeof(SimulationSystemGroup))] public partial class PlayerMovementSystem : SystemBase { ... }这里的关键是理解不同ComponentSystemGroup的执行顺序是固定的Initialization - Simulation - Presentation而组内System的顺序可以通过特性调整。5.3 异步场景加载与状态同步如果你的场景加载是异步的SceneManager.LoadSceneAsync需要特别注意状态切换的时机。SceneStateManagementSystem在OnUpdate中判断的依据如GameSceneController是否存在必须是在该场景的Entity转换完成之后。确保转换完成Unity ECS在转换场景时默认的ConvertToEntity模式Convert And Destroy会在场景加载后的某一帧进行。为了确保我们的状态系统能检测到可以在代表场景的实体上添加一个特殊的组件如SceneLoadedTag该组件由场景中一个特定的“场景根实体”在转换完成后添加可以通过一个简单的MonoBehaviour脚本配合IConvertGameObjectToEntity接口实现。状态切换延迟可以考虑让SceneStateManagementSystem在检测到新场景控制器实体后延迟一帧再切换标签以确保所有该场景的Entity都已就绪避免业务System在第一帧查询不到实体。5.4 常见问题排查表问题现象可能原因解决方案切换场景后旧场景的System仍在报错找不到实体业务System没有做场景状态判断或判断条件EntityQuery写错。检查业务System的OnUpdate开头是否有if (_sceneTagQuery.IsEmpty) return;并确认查询的组件类型是否正确。场景状态标签切换了但某些System好像没反应1. 状态管理System的执行顺序晚于业务System。2. 业务System使用了RequireForUpdate但查询条件太严格导致一帧被跳过下一帧才生效。1. 确保SceneStateManagementSystem在InitializationSystemGroup中且早于所有依赖它的逻辑。2. 检查业务System的RequireForUpdate查询或改用OnUpdate内判断。出现了多个持有场景标签的实体造成状态混乱场景状态实体创建逻辑有误没有保证单例。使用上面提到的“单例实体”模式在状态管理System中确保只有一个实体持有SceneStateSingleton及相关的场景标签。从场景A切换到场景B一瞬间两个场景的System都执行了场景加载是渐进的可能有一帧同时存在两个场景的控制器实体。在状态管理System中实现明确的优先级逻辑。例如只认最后加载的场景或者在检测到多个场景时使用一个明确的规则如按场景名排序选择一个。更稳妥的方式是在场景加载开始时就通过一个全局状态标记“正在切换场景”让所有System暂停。6. 实战构建一个健壮的场景感知ECS架构让我们把上面的方案整合成一个更工程化的示例。假设我们有一个小游戏包含Boot启动、Menu菜单、Game游戏三个场景。第一步定义状态组件与单例// Assets/Scripts/ECS/Components/SceneStateComponents.cs using Unity.Entities; // 单例标记 public struct SceneStateSingleton : IComponentData { } // 场景标签 public struct BootSceneTag : IComponentData { } public struct MenuSceneTag : IComponentData { } public struct GameSceneTag : IComponentData { } // 场景控制器组件挂在每个场景的根GameObject上 public class BootSceneController : MonoBehaviour { } public class MenuSceneController : MonoBehaviour { } public class GameSceneController : MonoBehaviour { }第二步实现场景状态管理System// Assets/Scripts/ECS/Systems/SceneStateManagementSystem.cs using Unity.Entities; using UnityEngine; [UpdateInGroup(typeof(InitializationSystemGroup))] [UpdateBefore(typeof(BeginInitializationEntityCommandBufferSystem))] public partial class SceneStateManagementSystem : SystemBase { private EntityQuery _bootSceneQuery; private EntityQuery _menuSceneQuery; private EntityQuery _gameSceneQuery; private EntityQuery _sceneStateSingletonQuery; protected override void OnCreate() { // 查询各场景控制器 _bootSceneQuery GetEntityQuery(ComponentType.ReadOnlyBootSceneController()); _menuSceneQuery GetEntityQuery(ComponentType.ReadOnlyMenuSceneController()); _gameSceneQuery GetEntityQuery(ComponentType.ReadOnlyGameSceneController()); // 查询单例实体 _sceneStateSingletonQuery GetEntityQuery( ComponentType.ReadWriteSceneStateSingleton(), ComponentType.ReadWriteBootSceneTag(), ComponentType.ReadWriteMenuSceneTag(), ComponentType.ReadWriteGameSceneTag() ); // 至少有一个场景控制器存在时才运行 RequireForUpdate(EntityQuery.Union(_bootSceneQuery, _menuSceneQuery, _gameSceneQuery)); } protected override void OnUpdate() { var ecb new EntityCommandBuffer(WorldUpdateAllocator); Entity sceneStateEntity EnsureSingletonEntity(ecb); // 清除所有可能存在的旧场景标签 ecb.RemoveComponentBootSceneTag(sceneStateEntity); ecb.RemoveComponentMenuSceneTag(sceneStateEntity); ecb.RemoveComponentGameSceneTag(sceneStateEntity); // 根据优先级或规则设置新标签这里假设游戏场景优先级最高 if (!_gameSceneQuery.IsEmpty) { ecb.AddComponentGameSceneTag(sceneStateEntity); Debug.Log(切换到 Game 场景状态); } else if (!_menuSceneQuery.IsEmpty) { ecb.AddComponentMenuSceneTag(sceneStateEntity); Debug.Log(切换到 Menu 场景状态); } else if (!_bootSceneQuery.IsEmpty) { ecb.AddComponentBootSceneTag(sceneStateEntity); Debug.Log(切换到 Boot 场景状态); } ecb.Playback(EntityManager); } private Entity EnsureSingletonEntity(EntityCommandBuffer ecb) { if (_sceneStateSingletonQuery.CalculateEntityCount() 0) { // 创建单例实体 Entity newEntity ecb.CreateEntity(); ecb.AddComponentSceneStateSingleton(newEntity); // 初始化一个默认标签例如Menu ecb.AddComponentMenuSceneTag(newEntity); return newEntity; } return _sceneStateSingletonQuery.GetSingletonEntity(); } }第三步改造业务System以PlayerMovementSystem为例它只在GameSceneTag存在时工作。// Assets/Scripts/ECS/Systems/PlayerMovementSystem.cs using Unity.Entities; using Unity.Mathematics; using Unity.Transforms; [UpdateInGroup(typeof(SimulationSystemGroup))] public partial class PlayerMovementSystem : SystemBase { private EntityQuery _gameSceneTagQuery; protected override void OnCreate() { _gameSceneTagQuery GetEntityQuery(ComponentType.ReadOnlyGameSceneTag()); // 使用RequireForUpdate让系统在非游戏场景下完全不被调度性能最优 RequireForUpdate(_gameSceneTagQuery); } protected override void OnUpdate() { // 能执行到这里说明一定在游戏场景 float deltaTime SystemAPI.Time.DeltaTime; Entities .WithName(PlayerMovementJob) .ForEach((ref LocalTransform transform, in PlayerInput input, in MoveSpeed speed) { float3 move new float3(input.Horizontal, 0, input.Vertical); if (math.lengthsq(move) 0.01f) { move math.normalize(move); } transform.Position move * speed.Value * deltaTime; }).ScheduleParallel(); } }对于菜单场景的UINavigationSystem则可以依赖MenuSceneTag。第四步配置场景在每个场景中创建一个空的GameObject重命名为_SceneController并挂载对应的XXXSceneControllerMono脚本。为该GameObject添加ConvertToEntity组件并选择“Convert And Destroy”模式。这样当场景加载时这个控制器就会转换为一个带有对应组件的Entity被我们的状态管理系统识别。通过以上四步我们就搭建了一个清晰、健壮、完全基于ECS数据的场景状态管理机制。所有System都能自动、正确地响应场景切换再也不会出现“System在别的场景默认启动”的尴尬问题了。这套架构不仅解决了当前问题也为游戏添加更多复杂状态如暂停、对话、过场动画打下了坚实的基础。