1. 项目概述：为什么是DOTS与ECS？
如果你是一位Unity开发者，最近几年肯定没少被“DOTS”、“ECS”、“性能爆炸”这些词刷屏。但说实话，很多教程要么一上来就讲深奥的计算机原理，要么直接丢出一段“魔法代码”让你照抄，看完之后还是云里雾里，不知道这玩意儿到底怎么用在自己的项目里，更别提从零开始搭建了。
我最初接触DOTS（Data-Oriented Technology Stack）和ECS（Entity 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 Dictionary<Type, (int offset, int size)> _componentOffsets; public ComponentChunk(int capacity, Type[] componentTypes) { _capacity = capacity; _count = 0; _componentOffsets = new Dictionary<Type, (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 Span<T> GetComponentArray<T>() 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 Span<T>(_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 Stack<int> _recycledIds = new Stack<int>(); private Dictionary<int, int> _entityVersions = new Dictionary<int, int>(); // Archetype到Chunk列表的映射 private Dictionary<Archetype, List<ComponentChunk>> _archetypeChunks = new Dictionary<Archetype, List<ComponentChunk>>(); // 实体到其所在Archetype和Chunk的索引（简化，真实情况更复杂） private Dictionary<int, (Archetype arch, int chunkIndex, int indexInChunk)> _entityLocation = new Dictionary<int, (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 AddComponent<T>(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 IEnumerable<ComponentChunk> 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 IEnumerable<ComponentChunk> GetChunks() { return Query?.GetMatchingChunks() ?? Enumerable.Empty<ComponentChunk>(); } } // 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.GetComponentArray<Position>(); var movements = chunk.GetComponentArray<Movement>(); // 关键：这里是连续内存的循环，CPU缓存友好！ for (int i = 0; i < positions.Length; i++) { // 直接通过索引访问，无需通过实体ID查找 positions[i].value += movements[i].direction * movements[i].speed * deltaTime; } // 注意：positions是Span<Position>，是值类型，修改的是副本。 // 上述修改不会生效！这引出了ECS另一个关键：如何写回数据？ // 真实实现需要能返回可写的引用或通过Chunk直接修改内存。 } } }实操心得：上面
MovementSystem的示例暴露了一个关键问题——数据如何写回。在简化模型中，GetComponentArray<T>()返回的是数据的副本（如果是值类型）。在真实高效的ECS框架中，系统必须获得组件数据的直接引用（ref T）或通过特定API修改底层内存。这通常需要通过更底层的指针操作或使用C#的ref return特性来实现。这是手写ECS框架时的一个主要难点，也是性能优化的核心战场。
3.4 系统调度器（SystemScheduler）
最后，我们需要一个大脑来按正确顺序管理和执行所有系统。
// SystemScheduler.cs public class SystemScheduler { private List<SystemBase> _systems = new List<SystemBase>(); 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 GetComponentRef<T>(int entityIndexInChunk) where T : struct, IComponentData { // 这是一个概念性代码。实际需要复杂的指针计算和生命周期管理。 // 假设我们能通过索引获取到内存地址 // ref return ref Unsafe.AsRef<T>(_buffer + offset + size*entityIndexInChunk); throw new NotImplementedException("需要实现非安全代码获取引用"); }由于安全地实现ref return涉及大量unsafe代码，为了演示，我们换一种思路：让系统通过EntityManager和Entity来修改数据。但这会牺牲一些性能，因为需要查找实体位置。这恰恰说明了自建框架时在易用性和极致性能间的权衡。
我们调整MovementSystem：
public class MovementSystem : SystemBase { public override void OnUpdate(float deltaTime) { // 假设EntityManager提供了通过Query获取实体和组件数组的方法 var entities = EntityManager.GetEntities(Query); // 获取实体数组 var positions = EntityManager.GetComponentDataArray<Position>(Query); var movements = EntityManager.GetComponentDataArray<Movement>(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的预取器可以高效地把它们加载到缓存里，循环体内部就是简单的线性计算。
如果换成传统的OOP，List<Enemy>里每个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这些概念有恍然大悟的感觉。这套数据导向的思维模式，其价值远超框架本身，它能让你在面对任何性能敏感的系统设计时，都多一份底气和清晰的思路。
