入DOTS的时候最先卡住我的不是Entity也不是Component而是World。这个名词看着简单但它在ECS里的位置比想象中重得多。很多教程上来就让你写System、查Entity却没人讲清楚World到底管什么。等我自己花了两个多月跑通一个多关卡原型的World切换回头整理代码时才发现World理解到位了DOTS的整体架构才算真正入门。这篇文章就从Unity DOTS里的World入手讲清楚World是什么、怎么创建和销毁、它和Entity/System/Component之间到底怎么协作以及我在实际项目中踩过的World相关坑。既有概念拆解也有能直接抄的代码片段和排查思路适合刚开始接触DOTS的Unity开发者也适合那些已经把Entity和System跑通、但对World边界模糊的朋友。1. World整体设计思路为什么ECS非要有个“世界”1.1 World在ECS里到底是什么World在DOTS里可以理解成一个“数据容器”或者“运行环境”。它不是传统游戏开发里的场景对象也不是一个可视化的空间概念。从代码角度说World就是一个封装了EntityManager、ComponentSystemGroup、EntityQuery、BlobAssetStore等核心对象的顶级容器。一个World内部大致长这样var world new World(MyWorld); // world.EntityManager - 管理所有Entity // world.GetExistingSystemSomeSystem() - 访问特定System // world.Unmanaged - 非托管数据的访问入口 // world.UpdateAllSystems() - 按SystemGroup调度所有System你可以把World想象成一个独立的“小宇宙”。Entity是这个宇宙里的物体Component是物体身上的属性标签System是宇宙运转的规则。宇宙World本身负责维护这一切的边界哪些Entity存在、哪些System在跑、数据存储在哪。这个设计带来的第一个好处是隔离。你可以在同一个进程里开多个World每个World的数据完全独立。比如客户端一个World、服务端一个World互不干扰。这在多人游戏、帧同步、以及编辑器工具链开发中非常实用。1.2 World、Entity、Component、System的包含关系为了把World的位置讲清楚我画一个抽象的分层关系你不需要记代码先建立心智模型World最外层容器负责创建和销毁内部的所有内容。EntityManagerWorld的“数据操作窗口”它负责增删Entity、增删Component、创建Archetype、执行查询。ComponentSystemGroupSystem的调度分组World通过它决定System的执行顺序。System处理逻辑的单元它通过EntityQuery从World里取数据、改数据。EntityWorld里的一个ID指向一组Component数据。Component附在Entity上的结构化数据块。这个模型在你写任何DOTS代码前都值得先在脑中过一遍。很多刚上手的朋友搞混“EntityManager”和“World”的关系其实World是天花板EntityManager是World对外暴露的一个核心接口。你拿到了world.EntityManager就等于拿到了操作这个世界里所有实体的钥匙。1.3 从GameObject思维到World思维的原点以前用GameObject的时候场景里的物体层级关系很明确父物体、子物体、组件挂载关系。但World里的Entity没有传统意义上的父子关系Entity有Parent组件但和Transform层级是两码事。Entity就是一堆Component的集合它的“存在感”完全由它身上的Component组合决定。这套设计的目标很明确让数据连续存储让System批量处理从而利用CPU缓存高速处理同构数据。这里有个关键权衡——你放弃了传统OOP的封装和继承换来了极致的遍历性能。注意如果你只是做一个简单的3D小游戏完全不需要强行上DOTS。DOTS的优势在高密度实体、大量同构数据、需要压榨CPU性能的场景。World这套抽象带来的理解成本在小项目中是负收益。2. World的创建、销毁与生命周期管理2.1 默认World是怎么来的Unity在进入Play Mode时会通过DefaultWorldInitialization自动创建一个默认World名字一般叫“Default World”。这个World里会自动初始化一系列基础SystemGroup比如InitializationSystemGroup、SimulationSystemGroup、PresentationSystemGroup。你平时写ISystem或ComponentSystem默认就会被注册到这个默认World里。如果你打开代码查一下会看到类似这样的初始化流程DefaultWorldInitialization.Initialize(Default World, false);这个调用发生在播放模式启动时它做了几件事扫描程序集里所有带WorldSystemGroup特性的System类型。根据SystemGroup层级构建System更新顺序。将System实例注册进默认World。把默认World存到World.DefaultGameObjectInjectionWorld静态属性中。这就是为什么你运行时在代码里写World.DefaultGameObjectInjectionWorld就能拿到当前主世界。2.2 什么时候需要手动建World虽然Unity帮你建好了默认World但下列场景你需要自己动手实现双World同步逻辑比如模拟World和渲染World分离。编写编辑器工具或测试代码不想污染默认World。做帧同步或多人游戏时需要独立于Unity引擎更新循环的World。需要临时创建一个World跑批量计算用完立刻销毁。手动创建World的代码非常简单var world new World(MyBakeWorld); var entityManager world.EntityManager;但要注意new World只是创建了一个空壳里面默认没有System。如果你需要这个World跑逻辑得像这样添加Systemvar world new World(MySimulationWorld); var simulationGroup world.CreateSystemManagedSimulationSystemGroup(); world.AddSystemManaged(simulationGroup);不过说实话手动串SystemGroup非常容易踩坑因为SystemGroup的更新顺序很讲究。我一般在工具链代码里用World比较多游戏逻辑还是尽量用默认World加SubScene配合。2.3 World销毁的正确姿势World的销毁是一个容易被低估的环节。因为World里包含EntityManager、System、BlobAssetStore等一堆资源如果直接丢弃引用内存泄漏是小事Unity编辑器下还可能出现反复进入播放模式后World状态残留的问题。安全销毁的方式是调用World.Dispose()world.Dispose();Dispose会做这几件事销毁World里所有实体的Component数据。销毁所有已注册的System。释放BlobAssetStore。清理内部非托管资源。我在实际项目里遇到过一个问题在播放模式下动态创建了一个World退出播放时没有Dispose结果再次进入播放模式旧的World数据残留在内存里导致同一个EntityID被两个World引用查问题查了很久。提示如果你不是自己new出来的World不要轻易Dispose——比如World.DefaultGameObjectInjectionWorld。这属于Unity管的默认World手动Dispose会让整个引擎数据损坏。3. World内部结构拆解EntityManager、Archetype与Chunk3.1 EntityManager到底管什么EntityManager是World的数据管理层。World持有EntityManager所有对Entity的创建、销毁、组件增删、查询都通过它完成。常用的操作// 获取World对应的EntityManager var entityManager world.EntityManager; // 创建一个空Entity var entity entityManager.CreateEntity(); // 添加组件 entityManager.AddComponentData(entity, new Translation { Value float3.zero }); // 创建带Archetype的Entity var archetype entityManager.CreateArchetype(typeof(Translation), typeof(LocalToWorld)); var entity2 entityManager.CreateEntity(archetype); // 实例化Entity var clone entityManager.Instantiate(entity);EntityManager之所以在World里地位特殊是因为它直接管理底层的数据存储。所有增删操作都会引发“结构性变更”Structural Change结构性变更会导致Chunk内存重新排列所以频繁增删Entity/Component是一个性能大坑。3.2 Archetype与ChunkWorld里的数据如何存储World里存储Entity数据时并不是每个Entity单独一个对象而是按Archetype分组以Chunk为单位连续存储。Archetype是“组件类型组合”的唯一标识。比如TranslationRotation是一个ArchetypeTranslationVelocity是另一个Archetype。同一Archetype的Entity会存储在同一个Chunk数组里。Chunk是一块固定大小的内存块默认16KB。一个Chunk可以容纳多个Entity的组件数据且这些数据是紧凑排列的。比如一个Chunk存了100个Translation那么遍历这100个Translation时CPU缓存友好度极高。这就解释了为什么DOTS在某些场景下比传统MonoBehaviour快很多因为数据天然按“同构批量”排布System遍历时不用到处找内存。但是代价也明显当你执行结构性变更比如给一个Entity新加一个组件这个Entity会被移到另一个对应新Archetype的Chunk去原Chunk需要做数据的移除和迁移。如果频繁增删组件整体性能会非常难看。3.3 EntityQuery如何从World里查数据System要读取World里的数据不能直接拿到全量实体列表然后一个个if判断那样效率太低。正确姿势是构造EntityQuery让框架直接根据Archetype匹配结果。var query entityManager.CreateEntityQuery(typeof(Translation), typeof(Velocity));这条语句的意思是从World里筛选出“同时拥有Translation和Velocity组件”的Entity集合。EntityQuery内部会维护Archetype的匹配表查询的时候直接跳过不匹配的Chunk所以性能极高。在ISystem里通常用SystemAPI.Query来写更简洁public partial struct MoveSystem : ISystem { public void OnUpdate(ref SystemState state) { foreach (var (translation, velocity) in SystemAPI.QueryRefRWLocalTransform, RefROVelocity()) { translation.ValueRW.Position velocity.ValueRO.Value * SystemAPI.Time.DeltaTime; } } }这段代码背后的逻辑是SystemAPI.Query会根据World里的Archetype自动匹配数据把符合条件的所有实体分组遍历。实际操作中的体会EntityQuery的匹配很严格。你要是多查一个组件结果集会大不一样少查一个组件可能把不该处理的实体也卷进来。写Query前先用Entities窗口看清楚当前World里有哪些Archetype组合能省去大量调试时间。4. World与System的运行机制System到底在哪个世界跑4.1 System注册进World的两种方式System不是自己独立运行的它必须注册到某个World里由World的SystemGroup调度。Entities 1.0时代推荐用ISystem值类型System代替ComponentSystem类System。ISystem性能更好、更符合DOTS设计哲学。注册方式有两种自动注册通过标记特性Unity会把它加到默认World。[UpdateInGroup(typeof(SimulationSystemGroup))] public partial struct MySystem : ISystem { public void OnUpdate(ref SystemState state) { // 每帧由SimulationSystemGroup调度执行 } }手动注册创建自定义World后手动AddSystem。var world new World(EditorSimulationWorld); world.CreateSystemManagedSimulationSystemGroup();这里要特别留意ISystem的OnCreate、OnUpdate里拿到的SystemState包含了当前World的引用。你不需要自己全局缓存World直接用state.World即可。public void OnCreate(ref SystemState state) { var world state.World; var entityManager world.EntityManager; }4.2 System更新顺序由SystemGroup控制World里跑System不是乱序的而是通过SystemGroup组织成树状结构。默认分三大组InitializationSystemGroup先执行处理初始化逻辑。SimulationSystemGroup主循环逻辑比如移动、战斗。PresentationSystemGroup最后执行处理渲染相关。每个组里还可以继续嵌套子系统。System的执行顺序决定了数据的一致性。比如移动系统必须先于碰撞检测系统执行否则碰撞检测用的位移是上一帧的。调整执行顺序的经典做法[UpdateAfter(typeof(PlayerInputSystem))] [UpdateBefore(typeof(CollisionSystem))] public partial struct MoveSystem : ISystem { }这套机制是World内部维护的。World每帧调用UpdateAllSystems时从根SystemGroup开始递归更新。4.3 多World场景下System怎么隔离既然World是独立的那多World意味着同一套System逻辑可以跑多份吗答案是默认情况下System只会被自动注册到默认World。如果你在代码里sync World或创建自定义World需要显式地添加系统到那个World。典型例子是服务器客户端分离你不想让渲染系统在服务器World里跑也不想让网络同步系统在编辑器World里跑。实现方式有几种条件编译。#if UNITY_SERVER // 只在服务器端添加的System #else // 客户端System #endif根据World名称或WorldType判断。[UpdateInGroup(typeof(SimulationSystemGroup))] public partial struct NetworkSyncSystem : ISystem { public void OnUpdate(ref SystemState state) { if (state.World.Name ! ClientWorld) return; // 只在客户端World执行 } }多World的System执行顺序管理确实麻烦但它带来的数据隔离和职责边界很清晰。我在一个模拟项目中就拆了“渲染World”和“逻辑World”渲染World只处理表现层数据逻辑World专职做帧步进同步问题从根上少了大半。5. DOTS的World与场景加载SubScene是怎么融入World的5.1 SubScene烘焙过程与World的关系在DOTS工作流里美术和策划在普通场景里摆放GameObject然后用SubScene把场景内容“烘焙”成Entity。烘焙产物最终会加载进World里。烘焙的流程如下编辑器中把GameObject放入SubScene。通过Baking过程BakingSystem将GameObjectComponent转换为EntityComponent。烘焙结果生成EntityScene数据运行时由SceneSystem加载进目标World。所以场景里的GameObject并不会直接出现在World里。SubScene只是一个编辑器层面的容器真正的运行时数据是EntityScene。你在World里看到的是烘焙后的纯ECS数据。这里有一个重要概念GameObject里的MonoBehaviour组件可以转换成IComponentData。比如自定义一个HealthComponent挂在GameObject上Baking系统识别后生成Entity的HealthComponent数据。5.2 关卡的World切换实践单关卡游戏用默认World一条路走到黑问题不大。但多关卡游戏或者类似大世界分区块加载的场景World的切换设计就变得关键。我做过的一个原型里每个关卡对应一个独立Worldpublic sealed class LevelWorldManager : IDisposable { private World currentWorld; public void LoadLevel(string levelName) { UnloadCurrent(); currentWorld new World(levelName); var systemGroup currentWorld.CreateSystemManagedSimulationSystemGroup(); currentWorld.AddSystemManaged(systemGroup); // 加载这个World对应的场景数据 var sceneSystem currentWorld.GetExistingSystemManagedSceneSystem(); // 通过SceneSystem.LoadSceneAsync加载烘焙好的场景 } public void UnloadCurrent() { if (currentWorld null) return; currentWorld.Dispose(); currentWorld null; } public void Dispose() { UnloadCurrent(); } }这种方案的最大好处是每个关卡的Entity、System、BlobAsset都随World一起创建和销毁。切关卡时不需要手动一个个清理Entity直接Dispose整个World干净利落。但同时也有代价World的创建和销毁本身有开销如果关卡很小频繁切换反而有性能损耗。建议在重资产场景、需要严格隔离数据时用独立World普通小关卡用默认World加Entity清理就够了。5.3 多World的数据交互方案多World不是完全隔离的二进制开关。很多时候需要跨World传数据。比如逻辑World算出的位置要同步给渲染World的Entity。跨World传数据的常用手段通过SystemAPI的ExternalWorld访问。var renderWorld World.DefaultGameObjectInjectionWorld; var renderEntity renderWorld.EntityManager.CreateEntity();把数据写入共享的BlobAsset或者非托管数组另一边的System去读取。事件队列。比如逻辑World产生一个伤害事件渲染World订阅这个事件播放特效。用SharedData或者跨World直接拿EntityManager操作注意线程安全问题。DOTS的线程安全上下文是World级别的跨World写数据时如果同时跑Job需要用EntityCommandBuffer或专门的同步点来保证正确性。6. 调试World内部状态的实用技巧与常见问题6.1 用Entities窗口看World内部在Unity编辑器里打开菜单栏Window Entities Hierarchy就能看到当前所有World、每个World里的Entity列表、Archetype组合以及各类组件数据。这是调试World内部状态的第一入口。System执行情况在Window Entities System Schedule里查看。你能看到每个System属于哪个World、当前帧是否被调度、耗时多少。我个人调试习惯是先看World列表确认有几个World在跑再看目标World里的Archetype组合有没有异常最后看SystemSchedule定位哪个System没执行。6.2 World相关高频问题排查表底下这张表是我在实际项目里最容易踩到的World相关问题和排查思路可以直接收藏。现象可能原因排查和处理方式创建了Entity但查询查不到EntityQuery的组件条件不匹配或Entity在另一个World确认查询的组件类型是否与Archetype完全一致用Entities窗口查看目标WorldSystem没执行System没被注册进当前World或SystemGroup顺序不对检查System特性是否匹配当前World查看SystemSchedule窗口场景里的GameObject烘焙后不显示SubScene未加载或烘焙的World不是当前渲染World确认SubScene加载状态检查SceneSystem在哪个WorldWorld.Dispose后其他代码还在引用EntityManagerWorld的引用没有清空在Dispose后置空World引用后续代码使用前先判空结构性变更导致严重卡顿在Update里大量CreateEntity/AddComponent用EntityCommandBuffer缓冲结构性变更合并到帧末批量执行多World中System互相干扰System在多个World都被注册且执行了不期望的逻辑用World名字或WorldType条件过滤在System代码开头加World判断旧World数据残留播放模式退出时没有Dispose自定义World在OnDisable或OnDestroy里释放World用World.Dispose6.3 结构性变更卡顿的优化心得最后分享一个实战里最常见的性能坑结构性变更导致World卡顿。这个问题不是World设计问题而是对World内数据存储方式理解不深导致的。每次AddComponent/RemoveComponent都会让Entity从一个Chunk迁移到另一个Chunk迁移过程涉及数据的拷贝和新旧内存的整理。如果10000个实体同时AddComponent那画面就会卡一下。优化思路总结成三句话批量操作前先想清楚是否需要频繁增删组件尽量让Entity生命周期稳定。如果必须频繁增删用EntityCommandBuffer把结构性变更延后到帧末统一执行。考虑用EnableableComponent代替删除组件。DOTS支持组件开关比如需要“暂时失效”的数据用SetComponentEnabled而不是RemoveComponent性能会好很多。// 用Enableable组件避免结构性变更 entityManager.SetComponentEnabledHealth(entity, false);这条经验在实际大项目里价值很高。因为World内部的数据迁移越少Chunk的连续性就越稳System遍历性能就越接近极致。7. 写在最后的World使用建议World这套概念在DOTS里是地基中的地基。理解越深后面写System、调Job、做Baking就越顺手。我的建议是不要一上来就尝试多World或者复杂SubScene流程。先用默认World把Entity、Component、System的循环跑通再开一个独立World跑一份纯粹的计算任务对比两个World的数据隔离效果。在这个过程里你对“World到底管了什么”会有切身体感。我在做DOTS项目时发现World其实是整个数据驱动架构的“边界感”来源。它把庞大的实体数据切分成多个可独立管理的封闭空间每块空间有自己的规则、自己的生命周期最终让复杂系统变得可以控制。理解World之后再看Entities包源码里的EntityManager、SystemGroup、SceneSystem就不再是孤立概念而是一个完整闭环的一部分。 
长河君 · 2026/9/9 19:46:09 · 阅读 1.2k Unity DOTS深入浅出：World容器架构与实战指南
入DOTS的时候最先卡住我的不是Entity也不是Component而是World。这个名词看着简单但它在ECS里的位置比想象中重得多。很多教程上来就让你写System、查Entity却没人讲清楚World到底管什么。等我自己花了两个多月跑通一个多关卡原型的World切换回头整理代码时才发现World理解到位了DOTS的整体架构才算真正入门。这篇文章就从Unity DOTS里的World入手讲清楚World是什么、怎么创建和销毁、它和Entity/System/Component之间到底怎么协作以及我在实际项目中踩过的World相关坑。既有概念拆解也有能直接抄的代码片段和排查思路适合刚开始接触DOTS的Unity开发者也适合那些已经把Entity和System跑通、但对World边界模糊的朋友。1. World整体设计思路为什么ECS非要有个“世界”1.1 World在ECS里到底是什么World在DOTS里可以理解成一个“数据容器”或者“运行环境”。它不是传统游戏开发里的场景对象也不是一个可视化的空间概念。从代码角度说World就是一个封装了EntityManager、ComponentSystemGroup、EntityQuery、BlobAssetStore等核心对象的顶级容器。一个World内部大致长这样var world new World(MyWorld); // world.EntityManager - 管理所有Entity // world.GetExistingSystemSomeSystem() - 访问特定System // world.Unmanaged - 非托管数据的访问入口 // world.UpdateAllSystems() - 按SystemGroup调度所有System你可以把World想象成一个独立的“小宇宙”。Entity是这个宇宙里的物体Component是物体身上的属性标签System是宇宙运转的规则。宇宙World本身负责维护这一切的边界哪些Entity存在、哪些System在跑、数据存储在哪。这个设计带来的第一个好处是隔离。你可以在同一个进程里开多个World每个World的数据完全独立。比如客户端一个World、服务端一个World互不干扰。这在多人游戏、帧同步、以及编辑器工具链开发中非常实用。1.2 World、Entity、Component、System的包含关系为了把World的位置讲清楚我画一个抽象的分层关系你不需要记代码先建立心智模型World最外层容器负责创建和销毁内部的所有内容。EntityManagerWorld的“数据操作窗口”它负责增删Entity、增删Component、创建Archetype、执行查询。ComponentSystemGroupSystem的调度分组World通过它决定System的执行顺序。System处理逻辑的单元它通过EntityQuery从World里取数据、改数据。EntityWorld里的一个ID指向一组Component数据。Component附在Entity上的结构化数据块。这个模型在你写任何DOTS代码前都值得先在脑中过一遍。很多刚上手的朋友搞混“EntityManager”和“World”的关系其实World是天花板EntityManager是World对外暴露的一个核心接口。你拿到了world.EntityManager就等于拿到了操作这个世界里所有实体的钥匙。1.3 从GameObject思维到World思维的原点以前用GameObject的时候场景里的物体层级关系很明确父物体、子物体、组件挂载关系。但World里的Entity没有传统意义上的父子关系Entity有Parent组件但和Transform层级是两码事。Entity就是一堆Component的集合它的“存在感”完全由它身上的Component组合决定。这套设计的目标很明确让数据连续存储让System批量处理从而利用CPU缓存高速处理同构数据。这里有个关键权衡——你放弃了传统OOP的封装和继承换来了极致的遍历性能。注意如果你只是做一个简单的3D小游戏完全不需要强行上DOTS。DOTS的优势在高密度实体、大量同构数据、需要压榨CPU性能的场景。World这套抽象带来的理解成本在小项目中是负收益。2. World的创建、销毁与生命周期管理2.1 默认World是怎么来的Unity在进入Play Mode时会通过DefaultWorldInitialization自动创建一个默认World名字一般叫“Default World”。这个World里会自动初始化一系列基础SystemGroup比如InitializationSystemGroup、SimulationSystemGroup、PresentationSystemGroup。你平时写ISystem或ComponentSystem默认就会被注册到这个默认World里。如果你打开代码查一下会看到类似这样的初始化流程DefaultWorldInitialization.Initialize(Default World, false);这个调用发生在播放模式启动时它做了几件事扫描程序集里所有带WorldSystemGroup特性的System类型。根据SystemGroup层级构建System更新顺序。将System实例注册进默认World。把默认World存到World.DefaultGameObjectInjectionWorld静态属性中。这就是为什么你运行时在代码里写World.DefaultGameObjectInjectionWorld就能拿到当前主世界。2.2 什么时候需要手动建World虽然Unity帮你建好了默认World但下列场景你需要自己动手实现双World同步逻辑比如模拟World和渲染World分离。编写编辑器工具或测试代码不想污染默认World。做帧同步或多人游戏时需要独立于Unity引擎更新循环的World。需要临时创建一个World跑批量计算用完立刻销毁。手动创建World的代码非常简单var world new World(MyBakeWorld); var entityManager world.EntityManager;但要注意new World只是创建了一个空壳里面默认没有System。如果你需要这个World跑逻辑得像这样添加Systemvar world new World(MySimulationWorld); var simulationGroup world.CreateSystemManagedSimulationSystemGroup(); world.AddSystemManaged(simulationGroup);不过说实话手动串SystemGroup非常容易踩坑因为SystemGroup的更新顺序很讲究。我一般在工具链代码里用World比较多游戏逻辑还是尽量用默认World加SubScene配合。2.3 World销毁的正确姿势World的销毁是一个容易被低估的环节。因为World里包含EntityManager、System、BlobAssetStore等一堆资源如果直接丢弃引用内存泄漏是小事Unity编辑器下还可能出现反复进入播放模式后World状态残留的问题。安全销毁的方式是调用World.Dispose()world.Dispose();Dispose会做这几件事销毁World里所有实体的Component数据。销毁所有已注册的System。释放BlobAssetStore。清理内部非托管资源。我在实际项目里遇到过一个问题在播放模式下动态创建了一个World退出播放时没有Dispose结果再次进入播放模式旧的World数据残留在内存里导致同一个EntityID被两个World引用查问题查了很久。提示如果你不是自己new出来的World不要轻易Dispose——比如World.DefaultGameObjectInjectionWorld。这属于Unity管的默认World手动Dispose会让整个引擎数据损坏。3. World内部结构拆解EntityManager、Archetype与Chunk3.1 EntityManager到底管什么EntityManager是World的数据管理层。World持有EntityManager所有对Entity的创建、销毁、组件增删、查询都通过它完成。常用的操作// 获取World对应的EntityManager var entityManager world.EntityManager; // 创建一个空Entity var entity entityManager.CreateEntity(); // 添加组件 entityManager.AddComponentData(entity, new Translation { Value float3.zero }); // 创建带Archetype的Entity var archetype entityManager.CreateArchetype(typeof(Translation), typeof(LocalToWorld)); var entity2 entityManager.CreateEntity(archetype); // 实例化Entity var clone entityManager.Instantiate(entity);EntityManager之所以在World里地位特殊是因为它直接管理底层的数据存储。所有增删操作都会引发“结构性变更”Structural Change结构性变更会导致Chunk内存重新排列所以频繁增删Entity/Component是一个性能大坑。3.2 Archetype与ChunkWorld里的数据如何存储World里存储Entity数据时并不是每个Entity单独一个对象而是按Archetype分组以Chunk为单位连续存储。Archetype是“组件类型组合”的唯一标识。比如TranslationRotation是一个ArchetypeTranslationVelocity是另一个Archetype。同一Archetype的Entity会存储在同一个Chunk数组里。Chunk是一块固定大小的内存块默认16KB。一个Chunk可以容纳多个Entity的组件数据且这些数据是紧凑排列的。比如一个Chunk存了100个Translation那么遍历这100个Translation时CPU缓存友好度极高。这就解释了为什么DOTS在某些场景下比传统MonoBehaviour快很多因为数据天然按“同构批量”排布System遍历时不用到处找内存。但是代价也明显当你执行结构性变更比如给一个Entity新加一个组件这个Entity会被移到另一个对应新Archetype的Chunk去原Chunk需要做数据的移除和迁移。如果频繁增删组件整体性能会非常难看。3.3 EntityQuery如何从World里查数据System要读取World里的数据不能直接拿到全量实体列表然后一个个if判断那样效率太低。正确姿势是构造EntityQuery让框架直接根据Archetype匹配结果。var query entityManager.CreateEntityQuery(typeof(Translation), typeof(Velocity));这条语句的意思是从World里筛选出“同时拥有Translation和Velocity组件”的Entity集合。EntityQuery内部会维护Archetype的匹配表查询的时候直接跳过不匹配的Chunk所以性能极高。在ISystem里通常用SystemAPI.Query来写更简洁public partial struct MoveSystem : ISystem { public void OnUpdate(ref SystemState state) { foreach (var (translation, velocity) in SystemAPI.QueryRefRWLocalTransform, RefROVelocity()) { translation.ValueRW.Position velocity.ValueRO.Value * SystemAPI.Time.DeltaTime; } } }这段代码背后的逻辑是SystemAPI.Query会根据World里的Archetype自动匹配数据把符合条件的所有实体分组遍历。实际操作中的体会EntityQuery的匹配很严格。你要是多查一个组件结果集会大不一样少查一个组件可能把不该处理的实体也卷进来。写Query前先用Entities窗口看清楚当前World里有哪些Archetype组合能省去大量调试时间。4. World与System的运行机制System到底在哪个世界跑4.1 System注册进World的两种方式System不是自己独立运行的它必须注册到某个World里由World的SystemGroup调度。Entities 1.0时代推荐用ISystem值类型System代替ComponentSystem类System。ISystem性能更好、更符合DOTS设计哲学。注册方式有两种自动注册通过标记特性Unity会把它加到默认World。[UpdateInGroup(typeof(SimulationSystemGroup))] public partial struct MySystem : ISystem { public void OnUpdate(ref SystemState state) { // 每帧由SimulationSystemGroup调度执行 } }手动注册创建自定义World后手动AddSystem。var world new World(EditorSimulationWorld); world.CreateSystemManagedSimulationSystemGroup();这里要特别留意ISystem的OnCreate、OnUpdate里拿到的SystemState包含了当前World的引用。你不需要自己全局缓存World直接用state.World即可。public void OnCreate(ref SystemState state) { var world state.World; var entityManager world.EntityManager; }4.2 System更新顺序由SystemGroup控制World里跑System不是乱序的而是通过SystemGroup组织成树状结构。默认分三大组InitializationSystemGroup先执行处理初始化逻辑。SimulationSystemGroup主循环逻辑比如移动、战斗。PresentationSystemGroup最后执行处理渲染相关。每个组里还可以继续嵌套子系统。System的执行顺序决定了数据的一致性。比如移动系统必须先于碰撞检测系统执行否则碰撞检测用的位移是上一帧的。调整执行顺序的经典做法[UpdateAfter(typeof(PlayerInputSystem))] [UpdateBefore(typeof(CollisionSystem))] public partial struct MoveSystem : ISystem { }这套机制是World内部维护的。World每帧调用UpdateAllSystems时从根SystemGroup开始递归更新。4.3 多World场景下System怎么隔离既然World是独立的那多World意味着同一套System逻辑可以跑多份吗答案是默认情况下System只会被自动注册到默认World。如果你在代码里sync World或创建自定义World需要显式地添加系统到那个World。典型例子是服务器客户端分离你不想让渲染系统在服务器World里跑也不想让网络同步系统在编辑器World里跑。实现方式有几种条件编译。#if UNITY_SERVER // 只在服务器端添加的System #else // 客户端System #endif根据World名称或WorldType判断。[UpdateInGroup(typeof(SimulationSystemGroup))] public partial struct NetworkSyncSystem : ISystem { public void OnUpdate(ref SystemState state) { if (state.World.Name ! ClientWorld) return; // 只在客户端World执行 } }多World的System执行顺序管理确实麻烦但它带来的数据隔离和职责边界很清晰。我在一个模拟项目中就拆了“渲染World”和“逻辑World”渲染World只处理表现层数据逻辑World专职做帧步进同步问题从根上少了大半。5. DOTS的World与场景加载SubScene是怎么融入World的5.1 SubScene烘焙过程与World的关系在DOTS工作流里美术和策划在普通场景里摆放GameObject然后用SubScene把场景内容“烘焙”成Entity。烘焙产物最终会加载进World里。烘焙的流程如下编辑器中把GameObject放入SubScene。通过Baking过程BakingSystem将GameObjectComponent转换为EntityComponent。烘焙结果生成EntityScene数据运行时由SceneSystem加载进目标World。所以场景里的GameObject并不会直接出现在World里。SubScene只是一个编辑器层面的容器真正的运行时数据是EntityScene。你在World里看到的是烘焙后的纯ECS数据。这里有一个重要概念GameObject里的MonoBehaviour组件可以转换成IComponentData。比如自定义一个HealthComponent挂在GameObject上Baking系统识别后生成Entity的HealthComponent数据。5.2 关卡的World切换实践单关卡游戏用默认World一条路走到黑问题不大。但多关卡游戏或者类似大世界分区块加载的场景World的切换设计就变得关键。我做过的一个原型里每个关卡对应一个独立Worldpublic sealed class LevelWorldManager : IDisposable { private World currentWorld; public void LoadLevel(string levelName) { UnloadCurrent(); currentWorld new World(levelName); var systemGroup currentWorld.CreateSystemManagedSimulationSystemGroup(); currentWorld.AddSystemManaged(systemGroup); // 加载这个World对应的场景数据 var sceneSystem currentWorld.GetExistingSystemManagedSceneSystem(); // 通过SceneSystem.LoadSceneAsync加载烘焙好的场景 } public void UnloadCurrent() { if (currentWorld null) return; currentWorld.Dispose(); currentWorld null; } public void Dispose() { UnloadCurrent(); } }这种方案的最大好处是每个关卡的Entity、System、BlobAsset都随World一起创建和销毁。切关卡时不需要手动一个个清理Entity直接Dispose整个World干净利落。但同时也有代价World的创建和销毁本身有开销如果关卡很小频繁切换反而有性能损耗。建议在重资产场景、需要严格隔离数据时用独立World普通小关卡用默认World加Entity清理就够了。5.3 多World的数据交互方案多World不是完全隔离的二进制开关。很多时候需要跨World传数据。比如逻辑World算出的位置要同步给渲染World的Entity。跨World传数据的常用手段通过SystemAPI的ExternalWorld访问。var renderWorld World.DefaultGameObjectInjectionWorld; var renderEntity renderWorld.EntityManager.CreateEntity();把数据写入共享的BlobAsset或者非托管数组另一边的System去读取。事件队列。比如逻辑World产生一个伤害事件渲染World订阅这个事件播放特效。用SharedData或者跨World直接拿EntityManager操作注意线程安全问题。DOTS的线程安全上下文是World级别的跨World写数据时如果同时跑Job需要用EntityCommandBuffer或专门的同步点来保证正确性。6. 调试World内部状态的实用技巧与常见问题6.1 用Entities窗口看World内部在Unity编辑器里打开菜单栏Window Entities Hierarchy就能看到当前所有World、每个World里的Entity列表、Archetype组合以及各类组件数据。这是调试World内部状态的第一入口。System执行情况在Window Entities System Schedule里查看。你能看到每个System属于哪个World、当前帧是否被调度、耗时多少。我个人调试习惯是先看World列表确认有几个World在跑再看目标World里的Archetype组合有没有异常最后看SystemSchedule定位哪个System没执行。6.2 World相关高频问题排查表底下这张表是我在实际项目里最容易踩到的World相关问题和排查思路可以直接收藏。现象可能原因排查和处理方式创建了Entity但查询查不到EntityQuery的组件条件不匹配或Entity在另一个World确认查询的组件类型是否与Archetype完全一致用Entities窗口查看目标WorldSystem没执行System没被注册进当前World或SystemGroup顺序不对检查System特性是否匹配当前World查看SystemSchedule窗口场景里的GameObject烘焙后不显示SubScene未加载或烘焙的World不是当前渲染World确认SubScene加载状态检查SceneSystem在哪个WorldWorld.Dispose后其他代码还在引用EntityManagerWorld的引用没有清空在Dispose后置空World引用后续代码使用前先判空结构性变更导致严重卡顿在Update里大量CreateEntity/AddComponent用EntityCommandBuffer缓冲结构性变更合并到帧末批量执行多World中System互相干扰System在多个World都被注册且执行了不期望的逻辑用World名字或WorldType条件过滤在System代码开头加World判断旧World数据残留播放模式退出时没有Dispose自定义World在OnDisable或OnDestroy里释放World用World.Dispose6.3 结构性变更卡顿的优化心得最后分享一个实战里最常见的性能坑结构性变更导致World卡顿。这个问题不是World设计问题而是对World内数据存储方式理解不深导致的。每次AddComponent/RemoveComponent都会让Entity从一个Chunk迁移到另一个Chunk迁移过程涉及数据的拷贝和新旧内存的整理。如果10000个实体同时AddComponent那画面就会卡一下。优化思路总结成三句话批量操作前先想清楚是否需要频繁增删组件尽量让Entity生命周期稳定。如果必须频繁增删用EntityCommandBuffer把结构性变更延后到帧末统一执行。考虑用EnableableComponent代替删除组件。DOTS支持组件开关比如需要“暂时失效”的数据用SetComponentEnabled而不是RemoveComponent性能会好很多。// 用Enableable组件避免结构性变更 entityManager.SetComponentEnabledHealth(entity, false);这条经验在实际大项目里价值很高。因为World内部的数据迁移越少Chunk的连续性就越稳System遍历性能就越接近极致。7. 写在最后的World使用建议World这套概念在DOTS里是地基中的地基。理解越深后面写System、调Job、做Baking就越顺手。我的建议是不要一上来就尝试多World或者复杂SubScene流程。先用默认World把Entity、Component、System的循环跑通再开一个独立World跑一份纯粹的计算任务对比两个World的数据隔离效果。在这个过程里你对“World到底管了什么”会有切身体感。我在做DOTS项目时发现World其实是整个数据驱动架构的“边界感”来源。它把庞大的实体数据切分成多个可独立管理的封闭空间每块空间有自己的规则、自己的生命周期最终让复杂系统变得可以控制。理解World之后再看Entities包源码里的EntityManager、SystemGroup、SceneSystem就不再是孤立概念而是一个完整闭环的一部分。