1. 项目概述为什么是DOTS与ECS如果你是一位Unity开发者最近几年肯定没少被“DOTS”、“ECS”、“性能爆炸”这些词刷屏。但说实话很多教程要么一上来就讲深奥的计算机原理要么直接丢出一段“魔法代码”让你照抄看完之后还是云里雾里不知道这玩意儿到底怎么用在自己的项目里更别提从零开始搭建了。我最初接触DOTSData-Oriented Technology Stack和ECSEntity Component System架构时也经历过这个阶段。当时手头有个模拟大量单位比如成千上万个NPC的项目用传统的面向对象OOB方式写帧率直接跌到不能看。内存里塞满了各种GameObject、MonoBehaviour每个对象都带着一堆不一定每帧都用得上的组件CPU缓存命中率低得可怜GC垃圾回收动不动就跳出来卡你一下。那时候我就明白是时候换个思路了。所以这个“从零构建DOTS项目”的系列我想换一种讲法。我们不只讲“怎么用”Unity官方的Entities包更要深入一步用手写C#代码的方式去理解并构建一个简化但核心完整的ECS框架。这就像学开车不能只会踩油门和刹车还得懂点发动机原理真遇到问题才知道怎么修。通过自己实现一遍你会对数据布局、组件查询、系统调度这些核心概念有刻骨铭心的理解未来无论使用Unity ECS、Entitas还是其他ECS框架都能得心应手。这个框架的目标很明确极致的数据局部性Data Locality和高效的并行处理。它适合谁呢首先是遇到性能瓶颈的开发者特别是那些涉及大量相似对象单位、子弹、粒子、地图格子的游戏或模拟应用。其次是对底层架构感兴趣想提升自己代码设计能力的程序员。即使你当前项目用不上这套思想也能让你写出更高效的C#代码。2. 核心架构设计拆解ECS的三大支柱在动手写代码之前我们必须把ECS的核心思想掰开揉碎。它和我们熟悉的OOP面向对象编程有根本性的不同可以概括为三个核心概念实体Entity、组件Component、系统System。理解它们的关系和设计初衷是成功构建框架的关键。2.1 实体Entity它不是一个“对象”在OOP里一个“敌人”可能是一个Enemy类的实例这个类里封装了血量、位置、速度等数据以及移动、攻击等方法。在ECS中我们要彻底改变这种思维。实体本质上只是一个轻量级的ID标识符。它本身不包含任何数据也没有任何行为。你可以把它想象成数据库里的一张表的主键或者一个数组的索引。它的唯一作用就是作为一组相关数据的“粘合剂”。一个“敌人”在ECS中可能由三个实体ID来共同标识一个ID关联着Health血量组件一个ID关联着Position位置组件另一个ID关联着Movement移动组件。这些组件数据在内存中是分开存储的。为什么要这么做核心是为了数据局部性。当系统需要处理所有具有Position和Movement组件的实体比如移动系统时它不需要去访问那些只有Health组件的实体数据。所有Position数据连续存储在内存的一块区域所有Movement数据连续存储在另一块区域。CPU可以高效地将这些连续的数据块预加载到高速缓存Cache中进行批处理这比在内存中跳跃式地访问一个个包含所有数据的“对象”要快得多。在我们的自建框架中实体可以简单到一个整数int或一个结构体struct包含一个唯一的ID字段。我们会用一个中央注册表EntityManager来管理所有实体的生命周期创建、销毁和它们与组件之间的映射关系。2.2 组件Component纯数据无行为这是与OOP第二个巨大的区别。组件必须是纯粹的数据结构Struct它不应该包含任何方法尤其是虚方法最好连引用类型class的字段都尽量避免。为什么必须是struct因为struct是值类型在内存中通常是连续存储的这完美契合了我们对数据局部性的追求。例如一个移动组件应该长这样public struct Movement : IComponentData { public float speed; public float3 direction; // 使用数学库的向量如Unity.Mathematics.float3 }你看它只有数据字段。IComponentData是我们自定义的一个空接口主要用于标记和类型约束方便框架识别哪些是组件类型。而一个传统的OOP类可能长这样public class EnemyMovement : MonoBehaviour { public float speed; private Rigidbody rb; private void Update() { /* 移动逻辑 */ } }这个类混杂了数据speed、对其他组件的引用rb和行为逻辑Update。在ECS中这些元素被彻底分离了。设计组件的心得组件要设计得尽可能小、尽可能内聚。不要创建一个叫EnemyData的庞然大物组件把血量、攻击力、经验值全塞进去。应该拆分成Health、Attack、Experience等多个小组件。这样移动系统就只需要关心Position和Movement渲染系统只关心Position和RenderData系统之间的耦合度降到最低并行化的可能性也大大增加。2.3 系统System行为逻辑的集中营系统是ECS中所有行为逻辑发生的地方。一个系统只负责做一件事并且只操作它关心的那几种组件。系统在每一帧或按固定时间间隔被框架调度执行。例如MovementSystem的职责就是遍历所有同时拥有Position和Movement组件的实体根据Movement.direction和speed来更新Position.value。系统的关键设计在于如何高效地查询到它需要的实体。这就是EntityQuery实体查询的概念。我们的框架需要提供一种方式让系统能声明“给我所有同时拥有A、B组件但没有C组件的实体”。框架底层则通过我们精心设计的数据存储结构快速地返回符合条件的数据块供系统进行批处理。系统间的执行顺序是另一个需要框架支持的重要特性。MovementSystem显然应该在CollisionSystem之前运行吗RenderingSystem肯定要在所有逻辑系统之后运行。我们需要一个可配置的系统调度管道SystemScheduler来管理它们的依赖和顺序。3. 框架核心实现手写一个简易ECS内核理论讲完了是时候打开IDE动手实现我们框架的核心了。我们将分步构建几个核心管理器。3.1 组件存储设计Archetype与Chunk的精髓这是ECS框架中最精妙也最复杂的部分。Unity ECS的Archetype原型和Chunk块概念非常优秀我们来实现一个简化版。Archetype原型指的是一组特定组件类型的唯一组合。例如所有同时拥有Position和Movement组件的实体都属于同一个Archetype。所有同时拥有Position、Movement和Health组件的实体属于另一个Archetype。Archetype是框架内部用于分类和高效检索实体的关键。Chunk块是实际存储组件数据的连续内存块。一个Archetype下会有多个Chunk。每个Chunk大小固定例如16KB可以容纳多个实体的组件数据。同一个Chunk内的所有实体其组件类型组合完全相同并且数据在内存中是按组件类型“数组化”存储的SoA - Structure of Arrays。举个例子一个包含Position和Movement的Chunk其内存布局大致如下[Chunk 内存块] | EntityID1 | EntityID2 | ... | EntityIDN | - 实体ID数组 | Position1 | Position2 | ... | PositionN | - Position组件数组连续 | Movement1 | Movement2 | ... | MovementN | - Movement组件数组连续这种SoA布局使得系统在遍历处理Position时是在一段连续的内存上顺序访问极大提高了CPU缓存利用率。让我们开始实现首先定义组件接口和实体。// IComponentData.cs - 一个标记接口用于识别组件类型 public interface IComponentData {} // Entity.cs - 实体就是一个ID和一些元信息 public struct Entity { public int Id; public int Version; // 版本号用于检测实体是否已被销毁复用 }然后实现最核心的ComponentChunk。// ComponentChunk.cs - 一个简化版的Chunk public unsafe class ComponentChunk { // 使用非托管内存避免GC开销 private byte* _buffer; private int _capacity; // 最多能容纳的实体数 private int _count; // 当前实体数 // 每个组件类型在Chunk中的偏移量信息 private DictionaryType, (int offset, int size) _componentOffsets; public ComponentChunk(int capacity, Type[] componentTypes) { _capacity capacity; _count 0; _componentOffsets new DictionaryType, (int, int)(); // 1. 计算总内存大小 int totalSize 0; foreach (var type in componentTypes) { int size Marshal.SizeOf(type); // 获取非托管大小 _componentOffsets[type] (totalSize, size); totalSize size * capacity; // 为该类型的所有实体预留空间 } // 加上实体ID数组的空间 totalSize sizeof(int) * capacity; // 2. 分配非托管内存 _buffer (byte*)Marshal.AllocHGlobal(totalSize).ToPointer(); } // 添加一个实体及其组件数据 public bool AddEntity(Entity entity, params object[] components) { if (_count _capacity) return false; // 写入实体ID int* idPtr (int*)(_buffer (_capacity * sizeof(int) * _count)); // 注意简化计算实际更复杂 *idPtr entity.Id; // 写入每个组件的数据 foreach (var comp in components) { var type comp.GetType(); if (_componentOffsets.TryGetValue(type, out var info)) { // 计算该实体此组件数据的写入位置 byte* dest _buffer info.offset (info.size * _count); Marshal.StructureToPtr(comp, (IntPtr)dest, false); } } _count; return true; } // 获取Chunk内某个组件类型的“数组”视图用于系统批量处理 public SpanT GetComponentArrayT() where T : struct, IComponentData { if (!_componentOffsets.TryGetValue(typeof(T), out var info)) throw new InvalidOperationException($Component type {typeof(T)} not in this chunk.); // 创建一个指向该组件数据起始位置的Span长度为当前实体数 // 注意这里使用了C# 7.3的unmanaged约束和System.Memory需要项目支持 return new SpanT(_buffer info.offset, _count); } ~ComponentChunk() { // 释放非托管内存 Marshal.FreeHGlobal((IntPtr)_buffer); } }注意这是一个极度简化的教学示例用于阐明原理。真实实现需要考虑内存对齐、线程安全、更高效的类型信息存储使用TypeIndex代替Type、以及实体ID与组件数据的精确映射。直接使用Marshal和指针操作需要unsafe上下文并需谨慎处理内存安全。3.2 实体管理器EntityManager的实现EntityManager是用户与ECS框架交互的主要入口负责创建销毁实体、管理组件。// EntityManager.cs public class EntityManager { private int _nextEntityId 0; private Stackint _recycledIds new Stackint(); private Dictionaryint, int _entityVersions new Dictionaryint, int(); // Archetype到Chunk列表的映射 private DictionaryArchetype, ListComponentChunk _archetypeChunks new DictionaryArchetype, ListComponentChunk(); // 实体到其所在Archetype和Chunk的索引简化真实情况更复杂 private Dictionaryint, (Archetype arch, int chunkIndex, int indexInChunk) _entityLocation new Dictionaryint, (Archetype, int, int)(); public Entity CreateEntity() { int id; if (_recycledIds.Count 0) id _recycledIds.Pop(); else id _nextEntityId; int version _entityVersions.GetValueOrDefault(id, 0) 1; _entityVersions[id] version; return new Entity { Id id, Version version }; } public void DestroyEntity(Entity entity) { if (!IsEntityValid(entity)) return; // 1. 从Chunk中移除数据需要处理数据迁移这里简化 // 2. 回收ID _recycledIds.Push(entity.Id); _entityLocation.Remove(entity.Id); // 注意实际版本号应在复用ID时递增这里简化处理 } public bool IsEntityValid(Entity entity) { return _entityVersions.TryGetValue(entity.Id, out int currentVersion) currentVersion entity.Version; } // 为实体添加组件会改变其Archetype public void AddComponentT(Entity entity, T component) where T : struct, IComponentData { // 1. 找到实体当前所在的Archetype和Chunk // 2. 创建新的Archetype旧类型新类型 // 3. 将实体的所有组件数据拷贝到新Archetype的新Chunk中 // 4. 在旧Chunk中移除该实体可能需要整理内存 // 这是一个非常复杂的操作是ECS框架的性能关键点之一。 // 优化技巧可以延迟操作在帧末批量处理Archetype变更。 Console.WriteLine($添加组件 {typeof(T).Name} 到实体 {entity.Id} (简化实现)); } // 创建实体查询 public EntityQuery CreateQuery(params Type[] componentTypes) { return new EntityQuery(this, componentTypes); } } // Archetype.cs - 原型本质上是组件类型集合的哈希值 public struct Archetype { private readonly int _hash; private readonly Type[] _types; public Archetype(Type[] types) { _types types.OrderBy(t t.Name).ToArray(); // 排序确保顺序无关 _hash CalculateHash(_types); } private static int CalculateHash(Type[] types) { // 简单的哈希计算 int hash 17; foreach (var t in types) hash hash * 31 t.GetHashCode(); return hash; } // 重写Equals和GetHashCode... }3.3 系统System与查询EntityQuery系统需要一种方式来获取它要处理的数据。EntityQuery就是它的眼睛。// EntityQuery.cs public class EntityQuery { private EntityManager _entityManager; private Type[] _requiredComponents; public EntityQuery(EntityManager manager, Type[] componentTypes) { _entityManager manager; _requiredComponents componentTypes; } // 执行查询返回一个迭代器这里简化直接返回所有匹配的Chunk public IEnumerableComponentChunk GetMatchingChunks() { // 遍历所有Archetype找出那些包含所有_requiredComponents的Archetype // 然后返回这些Archetype下的所有Chunk // 这是一个O(n)的查找真实框架会建立更高效的索引。 yield break; // 简化返回 } } // SystemBase.cs - 所有系统的基类 public abstract class SystemBase { protected EntityManager EntityManager { get; private set; } protected EntityQuery Query { get; private set; } public virtual void OnCreate(EntityManager manager) { EntityManager manager; // 子类系统需要在这里创建自己的Query // 例如Query manager.CreateQuery(typeof(Position), typeof(Movement)); } public abstract void OnUpdate(float deltaTime); // 每帧执行的逻辑 protected IEnumerableComponentChunk GetChunks() { return Query?.GetMatchingChunks() ?? Enumerable.EmptyComponentChunk(); } } // MovementSystem.cs - 一个具体的系统实现 public class MovementSystem : SystemBase { public override void OnCreate(EntityManager manager) { base.OnCreate(manager); Query manager.CreateQuery(typeof(Position), typeof(Movement)); } public override void OnUpdate(float deltaTime) { foreach (var chunk in GetChunks()) { // 获取这个Chunk内所有Position和Movement组件的“数组” var positions chunk.GetComponentArrayPosition(); var movements chunk.GetComponentArrayMovement(); // 关键这里是连续内存的循环CPU缓存友好 for (int i 0; i positions.Length; i) { // 直接通过索引访问无需通过实体ID查找 positions[i].value movements[i].direction * movements[i].speed * deltaTime; } // 注意positions是SpanPosition是值类型修改的是副本。 // 上述修改不会生效这引出了ECS另一个关键如何写回数据 // 真实实现需要能返回可写的引用或通过Chunk直接修改内存。 } } }实操心得上面MovementSystem的示例暴露了一个关键问题——数据如何写回。在简化模型中GetComponentArrayT()返回的是数据的副本如果是值类型。在真实高效的ECS框架中系统必须获得组件数据的直接引用ref T或通过特定API修改底层内存。这通常需要通过更底层的指针操作或使用C#的ref return特性来实现。这是手写ECS框架时的一个主要难点也是性能优化的核心战场。3.4 系统调度器SystemScheduler最后我们需要一个大脑来按正确顺序管理和执行所有系统。// SystemScheduler.cs public class SystemScheduler { private ListSystemBase _systems new ListSystemBase(); private EntityManager _entityManager; public SystemScheduler(EntityManager manager) { _entityManager manager; } public void AddSystem(SystemBase system) { system.OnCreate(_entityManager); _systems.Add(system); } public void Update(float deltaTime) { // 按预设顺序更新所有系统 foreach (var system in _systems) { system.OnUpdate(deltaTime); } // 此处可以加入EntityManager的延迟操作处理如批量处理组件添加/删除 } }4. 实战演练用自建框架实现万人同屏框架的核心部分搭建完毕尽管是简化版让我们用一个经典的“万人同屏移动”Demo来验证其思想。我们不会用到任何Unity的GameObject纯粹在控制台或一个简单的图形库中模拟。4.1 定义组件与系统首先定义我们需要的组件。public struct Position : IComponentData { public float3 value; } public struct Movement : IComponentData { public float3 direction; public float speed; } public struct Color : IComponentData { public float r, g, b; } // 用于渲染然后完善我们的MovementSystem这次要解决数据写回问题。我们修改ComponentChunk提供一个获取组件数据引用的方法模拟。// 在ComponentChunk中添加 public ref T GetComponentRefT(int entityIndexInChunk) where T : struct, IComponentData { // 这是一个概念性代码。实际需要复杂的指针计算和生命周期管理。 // 假设我们能通过索引获取到内存地址 // ref return ref Unsafe.AsRefT(_buffer offset size*entityIndexInChunk); throw new NotImplementedException(需要实现非安全代码获取引用); }由于安全地实现ref return涉及大量unsafe代码为了演示我们换一种思路让系统通过EntityManager和Entity来修改数据。但这会牺牲一些性能因为需要查找实体位置。这恰恰说明了自建框架时在易用性和极致性能间的权衡。我们调整MovementSystempublic class MovementSystem : SystemBase { public override void OnUpdate(float deltaTime) { // 假设EntityManager提供了通过Query获取实体和组件数组的方法 var entities EntityManager.GetEntities(Query); // 获取实体数组 var positions EntityManager.GetComponentDataArrayPosition(Query); var movements EntityManager.GetComponentDataArrayMovement(Query); for (int i 0; i entities.Length; i) { // 这里positions[i]可能已经是ref或者是需要写回的结构。 // 我们假设有一个方法可以写回。 var newPos positions[i]; newPos.value movements[i].direction * movements[i].speed * deltaTime; EntityManager.SetComponentData(entities[i], newPos); // 写回数据 } } }4.2 初始化世界与主循环在程序入口处我们模拟一个游戏循环。class Program { static void Main(string[] args) { var entityManager new EntityManager(); var scheduler new SystemScheduler(entityManager); // 注册系统 scheduler.AddSystem(new MovementSystem()); // scheduler.AddSystem(new RenderingSystem()); // 渲染系统 // 创建10000个具有Position和Movement的实体 Random rand new Random(); for (int i 0; i 10000; i) { var entity entityManager.CreateEntity(); entityManager.AddComponent(entity, new Position { value new float3(rand.Next(-50, 50), 0, rand.Next(-50, 50)) }); entityManager.AddComponent(entity, new Movement { direction new float3((float)rand.NextDouble()-0.5f, 0, (float)rand.NextDouble()-0.5f), speed 2.0f }); } // 简单的主循环 float deltaTime 0.016f; // 模拟60帧 for (int frame 0; frame 100; frame) // 模拟运行100帧 { scheduler.Update(deltaTime); // 此处可以调用渲染系统将Position数据绘制出来 Console.WriteLine($Frame {frame} updated.); Thread.Sleep(16); // 模拟帧时间 } } }4.3 性能对比思考即使我们这个框架非常简陋但它的数据组织方式已经体现了ECS的优势。想象一下在MovementSystem的循环中positions和movements是两个连续的大数组。CPU的预取器可以高效地把它们加载到缓存里循环体内部就是简单的线性计算。如果换成传统的OOPListEnemy里每个Enemy对象在堆内存中分散存储每个对象内部还包含Position、Movement以及其他不相关的数据如Health、Inventory。CPU在遍历时需要在内存中跳来跳去产生大量的缓存未命中Cache Miss性能差距在实体数量上万时会非常明显。踩坑提醒自己实现完整的生产级ECS框架是一个巨大的工程涉及内存管理、线程安全、序列化、调试工具等诸多方面。上述代码仅用于揭示核心原理。在真实项目中强烈建议使用成熟的框架如Unity Entities、Entitas、LeoEcs等。本项目的目的是通过造轮子来深入理解轮子让你在使用现成框架时能看懂其背后的设计意图做出更优的架构决策。5. 进阶话题与常见问题当你理解了基础框架后可能会遇到以下实际问题。5.1 如何与现有Unity引擎如渲染、物理交互这是将ECS用于实际游戏开发的最大挑战。Unity的渲染器如URP/HDRP和物理引擎PhysX仍然主要基于GameObject。主流解决方案是“混合模式”渲染创建一个RenderProxySystem。该系统遍历所有包含Position和RenderMesh组件的实体然后通过Graphics.DrawMesh或使用MonoBehaviour代理一个传统的GameObject其Update方法从ECS组件读取位置并更新自己的Transform来进行渲染。Unity的Entities包提供了更官方的Hybrid Renderer来解决这个问题。物理类似地可以创建“物理代理”Entity它拥有PhysicsCollider组件。一个PhysicsSyncSystem负责根据这些组件的数据去创建、更新或销毁Unity物理世界中的Rigidbody或Collider。反之物理碰撞事件也需要写回ECS世界通常通过一个PhysicsEvent组件来传递。输入与UI这部分通常仍用传统的MonoBehaviour来处理然后通过一个单例或事件系统将输入指令、UI状态转换成ECS中的组件数据如PlayerInput组件。核心思想将引擎固有的面向对象部分视为一个“外部服务层”。ECS系统负责核心的游戏状态和逻辑计算然后通过特定的“桥梁系统”与这个服务层进行数据同步。5.2 如何组织复杂的数据依赖与系统顺序当系统数量增多它们之间可能存在依赖关系。例如InputSystem产生输入数据必须在MovementSystem之前运行。MovementSystem必须在CollisionSystem之前运行。CollisionSystem又必须在DamageSystem之前运行。在我们的简易SystemScheduler中系统顺序由添加顺序决定。这不够灵活。成熟的框架如Unity Entities使用[UpdateBefore(typeof(OtherSystem))]和[UpdateAfter]特性标签来声明依赖关系调度器会在初始化时根据这些标签拓扑排序系统执行顺序。实操技巧在设计系统时尽量让它们通过组件数据来通信而不是直接调用。系统A将结果写入组件CompData系统B读取CompData。只要调度顺序保证A在B之前依赖就自然形成了。这比系统间直接引用要清晰、解耦。5.3 如何调试与可视化ECS数据调试ECS比调试一堆GameObject要困难因为你不能简单地在场景视图中点击查看。常用方法自定义编辑器工具在Unity Editor中编写一个自定义的EditorWindow可以显示当前世界中所有Archetype、Chunk、实体及其组件数据的列表。可以搜索、筛选实体。实体调试器Unity Entities包自带了强大的Entity Debugger窗口是学习和调试的必备工具。日志与数据快照在关键系统执行前后将重要组件的数据打印到日志或保存为文件。可以编写一个DebugPrintSystem根据条件输出特定实体的状态。可视化组件添加一个DebugVisualizer组件和对应的系统。该系统为需要调试的实体在场景中生成简单的图形如Gizmos、线框直观显示其位置、速度向量、状态等。5.4 常见性能陷阱与优化点即使使用了ECS编写不当仍然会导致性能问题。Archetype频繁变化每帧都有大量实体添加或删除组件会导致实体在Archetype间频繁迁移引发大量的内存拷贝和Chunk整理。优化使用ICleanupComponent或延迟处理将组件变更操作集中到一帧的末尾批量处理。不合理的查询一个查询包含太多或太少的组件类型可能导致遍历不必要的数据或错过缓存优化机会。优化仔细设计组件让查询尽可能精准。使用EntityQuery的WithAny、WithNone等选项来精确筛选。在Job中访问非ECS数据如果你使用Unity的Job System与ECS并行这是DOTS的精华在Job中访问传统的托管对象、静态变量是非常危险的会导致竞争条件或崩溃。优化将所有需要并行访问的数据都放入IComponentData或IBufferElementData中。忽视内存布局即使使用struct如果结构体内包含引用类型如string、class或者因为字段顺序不当导致内存对齐浪费也会影响性能。优化使用Unity.Collections下的NativeString等非托管容器并注意结构体字段的排列顺序从大到小或按对齐要求。构建自己的ECS框架是一次深刻的学习之旅它强迫你思考数据如何流动、CPU如何工作。当你再回头使用Unity Entities时你会对EntityQuery、ComponentSystem、IJobChunk这些概念有恍然大悟的感觉。这套数据导向的思维模式其价值远超框架本身它能让你在面对任何性能敏感的系统设计时都多一份底气和清晰的思路。
