当前位置：首页 > news >正文

Unity面试进阶：10个源码级深度问题解析与性能优化实战

news 2026/8/4 14:24:27

1. 项目概述：为什么我们需要基于源码的面试准备？

如果你正在准备Unity开发岗位的面试，并且已经刷遍了网上那些“Unity面试100题”，感觉答案千篇一律，心里还是没底，那这篇文章就是为你准备的。常规的面试题，比如“Unity的生命周期函数有哪些”、“协程和线程的区别是什么”，考察的是基础知识的记忆。但在一线大厂或者对技术深度有要求的团队面试中，尤其是中高级岗位，面试官更想看到的是你“知其然，知其所以然”的能力。他们不满足于你背出了答案，而是想探究你是否真的理解Unity引擎底层是如何运作的，遇到复杂问题时能否从原理层面进行分析和解决。

“基于源码的10个关键问题解析”这个标题，其核心价值就在于将面试准备从“记忆答案”提升到“理解原理”的维度。它瞄准的是那些希望突破瓶颈、在技术深度上建立壁垒的开发者。通过剖析Unity引擎源码（主要是C#部分的托管源码，而非C++核心引擎），我们可以一窥Unity内部的设计思想、性能优化机制和潜在陷阱。这不仅能让你在面试中对答如流，展现出远超同侪的思考深度，更能从根本上提升你日常开发中排查诡异Bug、进行高性能优化的能力。无论是面对“为什么我的协程在场景切换后不执行了”这样的具体问题，还是“如何设计一个万人同屏的渲染方案”这样的架构挑战，源码层面的理解都能给你提供坚实的理论依据和解决思路。

2. 核心问题解析：从现象到本质的十次深度穿越

接下来，我们将深入十个在面试中高频出现且极具深度的关键问题。我不会仅仅给出标准答案，而是会结合Unity源码（以公开的托管源码和官方文档为依据）和实际开发场景，拆解其背后的运行机制、设计考量以及可能遇到的坑。

2.1 问题一：GameObject.SetActive(false) 与 enabled = false 的本质区别是什么？

这是一个经典的“陷阱题”。表面上看，两者都能让一个物体或组件“失效”，但底层逻辑天差地别。

GameObject.SetActive(false)：这是对游戏对象根节点的操作。在源码层面，调用这个方法会触发一系列连锁反应。首先，该GameObject及其所有子物体在场景层次结构中的“激活”状态被设置为false。紧接着，引擎会遍历该物体上所有的组件（MonoBehaviour），并调用它们的OnDisable()方法。最关键的一点是，被SetActive(false)的物体将完全脱离游戏循环。它的Update、FixedUpdate等生命周期函数不会再被调用，渲染器也会被禁用，碰撞体也不再参与物理计算。它相当于被“冷冻”了起来，几乎不消耗任何更新和渲染性能。
component.enabled = false：这只影响单个组件。以MonoBehaviour为例，将其enabled设为false，仅仅意味着该脚本的Update、FixedUpdate、OnTriggerStay等依赖于启用状态的回调函数不会再被调用。但是，游戏对象本身依然是激活的。对象上的其他组件（如渲染器、碰撞器）依然正常工作，物体依然会被渲染，并参与物理碰撞检测。如果你只想禁用某个脚本的逻辑，而不想影响物体的显示和物理交互，这就是正确的选择。

面试深度追问点：面试官可能会接着问：“如果一个父物体被SetActive(false)，其子物体上的脚本，enabled为true，那么子物体脚本的Update会执行吗？” 答案是不会。因为父物体的失活导致整个子树脱离了更新循环，子物体组件自身的enabled状态在此时已无关紧要。这体现了Unity状态检查的层级顺序：先看对象是否激活，再看组件是否启用。

实操心得：

性能优化时，对于暂时不需要但后续可能用到的复杂物体（比如一个带有大量粒子特效和AI逻辑的Boss），优先使用SetActive(false)来彻底节省性能。而对于需要频繁切换显示/隐藏的UI元素，如果其上绑定的脚本有初始化成本，可以考虑使用CanvasGroup的alpha和interactable属性来控制“可见不可交互”，而非反复SetActive，以避免不必要的组件唤醒和休眠开销。

2.2 问题二：Coroutine（协程）真的是在子线程中运行的吗？yield return null 和 yield return WaitForSeconds 底层有何不同？

这是对Unity异步编程核心机制的拷问。很多初学者误以为协程能用来处理耗时计算以避免卡顿，这是一个危险的误解。

线程归属：协程全部在主线程中执行。Unity的协程本质上是一个基于迭代器（IEnumerator）的状态机。当你调用StartCoroutine时，引擎只是将这个迭代器对象注册到了主线程的更新管理器中。每一帧，更新管理器会检查各个协程的“等待条件”是否满足。因此，在协程里执行while(true)或者复杂的数学计算，会直接阻塞主线程，导致游戏卡顿。
yield 指令解析：
- yield return null：这意味着“在下一帧继续执行本协程中后面的代码”。在源码层面，协程管理器会在当前帧结束时，将此协程标记为“可恢复”，并在下一帧的更新周期内（在Update之后，LateUpdate之前）恢复其执行。
- yield return new WaitForSeconds(2f)：这创建了一个基于游戏时间的等待器。引擎内部会记录一个目标时间（Time.time + 2f）。在每一帧，协程管理器会检查Time.time是否已达到或超过目标时间。只有条件满足，协程才会在下一帧恢复。这里有个关键点：WaitForSeconds受Time.timeScale影响。如果你需要不受时间缩放影响的等待，应使用WaitForSecondsRealtime。

面试深度追问点：面试官可能会问：“如何实现一个自定义的 YieldInstruction，比如 WaitUntilAnimationEnd？” 这考察了你对协程机制的理解深度。你需要创建一个继承自CustomYieldInstruction的类，并重写其keepWaiting属性。在这个属性中，你返回true表示继续等待，返回false表示协程可以继续执行。这样你就将协程的恢复条件与自定义的游戏逻辑（如动画状态、网络回调）绑定在了一起。

常见坑点：

协程在所属的GameObject被SetActive(false)或Destroy时，会自动停止。但如果你在协程中引用了其他可能被销毁的对象，需要手动进行空引用检查，否则会抛出MissingReferenceException。一个良好的实践是，在协程开始时用局部变量缓存关键组件引用，并在关键步骤前检查this（对于MonoBehaviour协程）或缓存的对象是否为null。

2.3 问题三：Unity的垃圾回收（GC）主要来自哪里？如何有效避免GC Alloc？

对于追求性能，特别是面向移动设备或VR/AR开发的项目，GC引发的卡顿是头号敌人。理解GC Alloc的来源是优化的第一步。

主要来源：
1. 字符串操作：在C#中，字符串是不可变的。任何拼接（+、String.Concat）、格式化（string.Format）、或调用返回新字符串的方法（如Substring在某些 .NET 版本中）都会产生新的字符串对象，从而引发GC Alloc。在频繁调用的代码路径（如Update、OnGUI）中进行字符串操作是性能杀手。
2. 装箱（Boxing）：将值类型（如int, float, struct）赋值给object类型或接口时，会发生装箱，在堆上创建新对象。常见的陷阱包括在集合（如ArrayList，非泛型）、Dictionary<object, ...>中使用值类型，或者在某些委托和事件回调中。
3. Lambda表达式与闭包：匿名方法和Lambda表达式如果捕获了外部变量（形成闭包），编译器会生成一个隐藏的类来存储这些变量，每次调用都可能实例化这个类，导致分配。
4. LINQ查询：大部分LINQ操作（如Where,Select,ToList）都会在背后创建迭代器对象和中间集合，产生分配。
5. Unity API 调用：一些Unity API本身就会产生分配，例如GetComponent<T>()（在旧版本Unity或某些情况下）、Camera.main（每次调用都会查找Tag为MainCamera的物体）、某些物理查询的返回数组等。
优化策略：
- 字符串：使用StringBuilder进行复杂的字符串构建；对于频繁更新的UI文本（如分数、血量），考虑使用TextMeshPro，它提供了更高效的文本渲染和修改接口。
- 避免装箱：使用泛型集合（List<T>,Dictionary<TKey, TValue>）；为自定义值类型实现IEquatable<T>接口以避免在字典中比较时装箱。
- 小心Lambda：在热路径（频繁执行的代码）中，尽量避免使用捕获外部变量的Lambda。可以考虑将重复使用的委托缓存为静态或成员变量。
- 慎用LINQ：在性能关键的循环中，用传统的for或foreach循环代替LINQ。
- 缓存Unity对象：将GetComponent的结果在Awake或Start中缓存起来；避免在Update中调用Camera.main或Find系列方法。

实操心得：

利用Unity Profiler的Deep Profile模式是定位GC Alloc来源的利器。你可以清晰地看到每一帧的内存分配来自哪一行代码。一个高级技巧是：对于必须频繁创建和销毁的小型对象（如子弹、特效参数），使用对象池（Object Pooling）是根治GC问题的终极方案之一。通过复用对象，你将“分配/销毁”的循环转变为“激活/禁用”，从而将堆内存分配降至几乎为零。

2.4 问题四：ScriptableObject 与 MonoBehaviour 在设计模式上的根本区别是什么？各自最佳应用场景是？

这个问题考察你对Unity数据和行为分离架构的理解。

MonoBehaviour：行为的载体。它必须挂载在GameObject上，与游戏对象生命周期强绑定。它的核心作用是定义游戏对象在运行时的行为逻辑（如移动、攻击、响应输入）。MonoBehaviour拥有完整的生命周期钩子，可以方便地与Unity引擎的各种系统（物理、渲染、UI）进行交互。
ScriptableObject：数据的容器。它是一种独立于游戏场景存在的资源文件（.asset）。它不依赖于GameObject，也不能直接挂载。其核心优势在于：
1. 数据共享与复用：一个ScriptableObject资产可以被多个游戏对象、甚至多个场景引用。修改资产文件，所有引用处同步更新。这非常适合配置游戏参数（如角色属性表、武器数据、关卡配置）。
2. 减少场景依赖：将数据从Prefab或场景中剥离出来，使得Prefab更加轻量，也便于进行版本管理和批量修改。
3. 运行时内存优化：作为资源，ScriptableObject的数据在内存中通常只有一份实例（如果被多个对象引用），避免了数据冗余。
最佳应用场景对比：

特性	MonoBehaviour	ScriptableObject
存在形式	必须依附于GameObject	独立的.asset资源文件
核心用途	定义对象行为、游戏逻辑	存储配置数据、共享参数
生命周期	与GameObject绑定，有Awake/Start/Update等	独立，通常由Unity资源系统管理
数据存储	数据保存在场景或Prefab中	数据保存在项目Assets文件夹内
多对象共享	每个对象实例拥有独立数据副本	多个对象可引用同一份数据资产

面试深度追问点：面试官可能会让你设计一个技能系统。你可以回答：使用ScriptableObject来定义每个技能的静态数据（如技能名称、伤害系数、冷却时间、特效Prefab引用、音效等）。然后，创建一个MonoBehaviour脚本“SkillExecutor”挂在玩家身上，它持有当前可用的技能ScriptableObject列表，并在运行时根据这些数据来实例化特效、计算伤害、管理冷却。这样，策划人员可以在不修改代码的情况下，直接在Unity编辑器中创建和调整上百种技能。

2.5 问题五：Unity的序列化系统是如何工作的？为什么说 public 字段不一定总被序列化？

理解序列化是理解Unity编辑器如何保存数据、Prefab如何工作以及一些诡异Bug来源的关键。

序列化机制：Unity使用了一个自定义的序列化系统（而非标准的.NET序列化），来将脚本中的字段值保存到场景（.unity）和预制体（.prefab）文件中。当你在Inspector窗口中修改一个字段的值，这个值并不是直接保存在脚本里，而是被Unity的序列化系统记录在了场景或预制体资源中。
序列化规则：
1. 默认规则：非静态、非常量的public字段会被序列化。标记了[SerializeField]属性的 private/protected 字段也会被序列化。
2. 不序列化的情况：
  - 标记了[NonSerialized]属性的字段。
  - 静态（static）字段。
  - 属性（Property）。
  - 只读（readonly）字段（在C#中）。
  - 某些复杂类型，如果Unity没有为其提供序列化支持（如多维数组、非[Serializable]标记的自定义类/结构体）。
“public字段不一定总被序列化”的深层原因：这句话通常指向一种特殊情况：对引用类型对象的序列化是“浅”序列化。假设你有一个public的MyClass字段，其中MyClass是一个自定义的类。Unity会序列化这个字段的引用（即，是否为空，或者是否引用了另一个UnityEngine.Object派生类的对象）。但是，MyClass内部的各个字段（比如int hp,string name）默认不会被自动序列化，除非你给MyClass加上[System.Serializable]特性。这就是为什么你有时在Inspector里给一个类赋值，运行后值却“丢失”了的原因。

实操心得：

在设计需要显示在Inspector中并保存的数据结构时，牢记以下两点：
对于简单的配置数据，优先使用[System.Serializable]的结构体（struct），因为结构体是值类型，其所有内容会被完整序列化。
对于复杂的、需要引用其他Unity资源（如Prefab、Material）的数据，可以创建一个继承自ScriptableObject的类来管理，这样数据独立且功能强大。
养成好习惯：不需要在Inspector中显示的字段，尽量用private并配合[SerializeField]仅在必要时使用；需要显示的字段，想清楚它应该是public还是[SerializeField] private，后者能更好地封装数据。

2.6 问题六：Addressable Assets System 与 Resources 文件夹加载资源的本质区别与优劣？

资源管理是大型Unity项目的基石。这个问题考察你对现代Unity资源管理方案的理解。

Resources 系统：
- 本质：这是一个静态的打包系统。构建项目时，所有放在名为“Resources”文件夹及其子文件夹下的资源，会被打包进一个或多个巨大的.resources文件中。运行时通过Resources.LoadAPI，根据资源路径从这些大文件中查找并加载。
- 优点：使用简单，无需额外配置。
- 致命缺点：
  1. 不可变：构建后无法动态更新资源。
  2. 内存膨胀：所有Resources下的资源都会被打包进安装包，导致初始包体巨大。
  3. 依赖管理弱：容易产生冗余，且卸载资源需要小心管理引用，否则容易内存泄漏。
  4. 路径硬编码：字符串路径容易出错，且重构不便。
Addressable Assets System：
- 本质：这是一个动态的、基于地址的资源管理系统。它为每个资源分配一个唯一的“地址”（可以是一个字符串或AssetReference），而不是文件路径。在构建时，你可以按需将资源分组，打包成多个独立的AssetBundle。这些AssetBundle可以放在本地，也可以放在远程服务器（CDN）上。
- 核心优势：
  1. 动态更新：远程AssetBundle可以实现热更新，无需重新发布应用商店版本。
  2. 按需加载：玩家只需要下载和加载当前需要的资源，大幅减少初始包体大小和内存占用。
  3. 强大的依赖管理：系统自动处理资源之间的依赖关系，确保加载一个Prefab时，其关联的材质、贴图、模型等都会被正确加载。
  4. 内存管理自动化：提供了完善的引用计数和自动卸载机制，大大降低了内存泄漏的风险。
  5. 异步加载友好：所有加载操作都基于异步模式设计，配合AsyncOperationHandle可以方便地管理加载状态、进度和结果。

面试深度追问点：面试官可能会问：“Addressables如何解决资源依赖和冗余问题？” 你可以回答：在Addressables的构建过程中，系统会分析资源之间的引用关系，自动将共享的依赖资源提取出来，放入独立的“共享资源包”中。这样，多个主资源包可以引用同一个共享包，避免了同一份资源（如通用材质、字体）在多个包中重复存在，既优化了下载大小，也保证了运行时内存中只有一份实例。

迁移建议：

对于新项目，强烈建议直接使用Addressables。对于老项目迁移，可以采用渐进式策略：先将新的、需要热更的资源用Addressables管理，老的Resources资源暂时不动，逐步替换。Addressables的学习曲线初期较陡，但其带来的长期维护性和灵活性收益是巨大的。

2.7 问题七：Unity的物理更新（FixedUpdate）与帧更新（Update）是如何协调的？为什么FixedUpdate里用Time.deltaTime不对？

这个问题直指Unity引擎循环的核心机制，是区分初级和中级开发者的重要标尺。

双循环机制：Unity主循环包含两个独立但又相互关联的循环：
1. 帧循环（Frame Loop）：以设备屏幕刷新率（如60Hz）为目标频率执行。每帧调用一次Update、LateUpdate等。Time.deltaTime表示的是上一帧到当前帧的实际时间间隔，是可变的。
2. 固定时间步长循环（Fixed Timestep Loop）：以固定的时间间隔（默认为0.02秒，即50Hz）执行。每达到一个固定时间步长，就调用一次FixedUpdate，并进行物理模拟（如刚体运动、碰撞检测）。这个间隔是恒定的，由Time.fixedDeltaTime定义。
协调方式：在一帧（Frame）的时间内，引擎可能会执行零次、一次或多次FixedUpdate。例如，如果游戏运行缓慢，一帧实际耗时0.1秒，而fixedDeltaTime是0.02秒，那么在这一帧里，引擎会连续执行5次FixedUpdate，以确保物理模拟的准确性，然后再执行一次Update。这就是为什么FixedUpdate的调用频率可能与帧率不同步。
为什么在FixedUpdate里用Time.deltaTime是错的？因为Time.deltaTime是帧间时间，是变化的。而物理模拟需要在一个稳定的时间基础上进行，才能保证模拟的可重复性和准确性（比如抛物线轨迹的计算）。在FixedUpdate中，你应该使用恒定的Time.fixedDeltaTime。如果你错误地使用了Time.deltaTime，当游戏帧率波动时，你的物理相关计算（例如在FixedUpdate里对刚体施加力）就会变得不稳定，导致物体运动抖动或速度异常。

高级话题：累积误差与补偿有时，即使固定时间步长很稳定，由于浮点数精度或复杂的交互，物理状态仍可能产生微小误差。Unity的物理引擎（如NVIDIA PhysX）内部会使用一种称为“子步进（Sub-stepping）”的技术来进行更精确的碰撞检测和求解。作为应用层开发者，理解FixedUpdate的确定性特性，是编写网络同步游戏（尤其是状态同步）和复杂物理交互逻辑的基础。

实操心得：

一个常见的模式是：在Update中接收玩家输入（因为输入是每帧采样的），然后将输入指令缓存起来。在接下来的FixedUpdate中，读取缓存的输入，并应用到物理计算中（如给角色刚体添加力）。这样可以确保物理模拟基于稳定的时间间隔，同时又对玩家输入有及时的响应。

2.8 问题八：Shader中，顶点着色器（Vertex Shader）与片元着色器（Fragment Shader）的职责边界在哪里？什么是插值器？

这个问题考察你对渲染管线的理解，是图形面试的必考题。

顶点着色器（Vertex Shader）：
- 输入：单个顶点的属性数据（位置、法线、纹理坐标、颜色等）。
- 核心职责：坐标变换。将顶点的模型空间坐标，经过模型矩阵（Model）、视图矩阵（View）、投影矩阵（Projection）变换，最终输出到齐次裁剪空间（Homogeneous Clip Space）。此外，它还可以计算并输出一些需要传递给片元着色器的数据，如世界空间法线、视线方向等。
- 输出：变换后的顶点齐次坐标，以及一系列需要传递给片元着色器的变量（这些变量会被光栅化阶段插值）。
片元着色器（Fragment/Pixel Shader）：
- 输入：经过光栅化插值后的顶点着色器输出数据。注意，它接收的不是原始顶点数据，而是每个像素点（片元）上插值得到的数据。
- 核心职责：决定像素颜色。基于插值后的数据（如纹理坐标、法线、光照信息），进行纹理采样、光照计算等，最终输出该像素的颜色值（可能包含透明度）。
- 输出：片元的最终颜色（RGBA）。
插值器（Varyings/Interpolators）：这是连接顶点和片元着色器的桥梁。在顶点着色器中，你会计算一些需要用于后续光照或着色的数据（如世界空间法线worldNormal、纹理坐标uv），并将它们输出到特定的变量中（在Unity ShaderLab中，通常放在一个结构体里，如v2f）。光栅化阶段会为每个三角形覆盖的像素，根据三个顶点的输出值，进行重心坐标插值，生成每个像素对应的值，然后传递给片元着色器。这就是为什么在片元着色器中，你能获得平滑变化的法线或纹理坐标。

面试深度追问点：面试官可能会问：“为什么在顶点着色器里计算光照（Gouraud Shading）和片元着色器里计算光照（Phong Shading）效果不同？” 这正体现了插值的作用。顶点着色器计算光照，结果只在顶点处是精确的，颜色在三角形内部只是简单插值，会导致棱角感（马赫带）。而片元着色器计算光照，法线等信息被插值到每个像素，光照计算在每个像素上进行，结果更加平滑精细，当然计算开销也更大。

2.9 问题九：Unity的委托与事件（UnityEvent）在底层是如何实现的？与C#原生event有何异同？

这个问题考察你对Unity事件系统的底层认知，这对于构建灵活、解耦的游戏架构至关重要。

C# 原生 event：
- 本质：是一个语法糖，背后是委托（delegate）类型和多播委托（MulticastDelegate）的实例。event关键字主要作用是封装，在类外部它只允许进行+=（订阅）和-=（取消订阅）操作，不能直接=赋值或invoke，这提供了更好的封装性和安全性。
- 特点：纯代码驱动，性能高，类型安全。但无法在Unity Inspector中可视化配置。

UnityEvent：

本质：是一个继承自UnityEngine.Events.UnityEventBase的类。它是Unity为了支持编辑器序列化和可视化而创建的一套独立的事件系统。
底层实现：UnityEvent内部维护了一个调用列表（Invocation List），这个列表可以被序列化。当你在Inspector中拖拽一个游戏对象和方法时，Unity实际上是在序列化“目标对象”的引用和“方法名”的字符串。在运行时，通过反射（早期）或预编译的委托（较新版本优化后）来调用这些方法。

与C# event的异同：

特性	C# 原生 event	UnityEvent
编辑器支持	无，纯代码	有，可在Inspector中可视化配置
序列化	否	是，可保存在Prefab/场景中
性能	高（直接委托调用）	较低（涉及序列化数据查找和调用，但有优化）
动态监听	代码中`+=`/`-=`	代码中`AddListener()`/`RemoveListener()`
触发	类内部`eventName?.Invoke(args)`	`Invoke()`
参数传递	支持自定义多参数委托	有泛型版本（如`UnityEvent<float>`），但Inspector支持有限

面试深度追问点：面试官可能会问：“UnityEvent在性能敏感处大量使用会有问题吗？如何优化？” 答案是肯定的。频繁调用UnityEvent.Invoke()，尤其是带参数的泛型版本，其开销高于C#原生事件。优化方法包括：

在热路径中，考虑改用C#原生event，或者直接调用缓存的方法委托。
如果必须用UnityEvent，尽量减少其触发频率。
注意在对象销毁时（OnDestroy）移除所有监听，避免引用残留导致的内存泄漏或错误调用。

架构选择：

对于需要在编辑器中方便地让策划或美术进行配置的、相对低频的事件（如UI按钮点击、动画事件、触发器回调），UnityEvent是绝佳选择。对于系统内部模块间高频、性能关键的通信（如每帧的输入事件、状态机切换），应优先使用C#原生event或更高效的消息/观察者模式实现。

2.10 问题十：如何从零实现一个简单的ECS（实体组件系统）架构？其与GameObject/Component模式的核心思想差异在哪？

ECS是Unity主推的面向数据的技术栈（DOTS）的核心架构，理解它代表了你对高性能游戏编程前沿的认知。

核心思想差异：
- 传统GameObject/Component模式：是面向对象的设计。一个GameObject是一个容器，挂载多个Component（MonoBehaviour）。数据（字段）和行为（方法）耦合在同一个Component类中。CPU访问内存时，由于对象分散在堆内存各处，缓存不友好（Cache Unfriendly）。更新逻辑时，需要遍历所有GameObject，再调用其Component的Update，虚函数调用、条件判断等开销较大。
- ECS架构：是面向数据的设计。它明确地将数据（Component，现在是纯结构体）、行为（System，处理数据的逻辑）和实体（Entity，一个轻量ID，用于关联一组Component）分离开。
  - Entity：仅仅是一个ID，没有其他数据。
  - Component：纯数据（struct），不包含任何方法。
  - System：纯逻辑，它遍历所有拥有特定Component组合（Archetype）的Entity，并以高效的方式（通常是连续内存块）处理这些Component数据。
手动实现一个简易ECS框架：虽然Unity的Entities包非常复杂，但我们可以勾勒出其核心原理：
1. 定义Component：使用结构体（struct）定义纯数据，如PositionComponent,VelocityComponent。
```
public struct PositionComponent { public float x, y, z; } public struct VelocityComponent { public float dx, dy, dz; }
```
1. 管理Archetype与Chunk：
  - 将拥有完全相同Component组合的Entity归为同一个Archetype。
  - 每个Archetype管理多个固定大小的内存块（Chunk）。每个Chunk内，同类型Component的数据被连续存储（SoA - Structure of Arrays）。这是ECS性能的关键，极大地提高了CPU缓存命中率。
2. 实现System：
  - System定义一个它关心的Component组合（Query）。
  - 在更新时，System遍历所有匹配的Archetype，获取其Chunk，然后直接对连续内存中的Component数组进行操作。这避免了虚函数调用和间接寻址。
```
// 伪代码概念 public class MovementSystem : SystemBase { protected override void OnUpdate() { // 查询所有同时拥有Position和Velocity的Entity Entities.ForEach((ref PositionComponent pos, in VelocityComponent vel) => { pos.x += vel.dx * deltaTime; pos.y += vel.dy * deltaTime; pos.z += vel.dz * deltaTime; }).ScheduleParallel(); // 甚至可以并行调度 } }
```
1. 实体管理：提供一个EntityManager来创建/销毁Entity，以及添加/移除Component。当Component变化时，Entity需要从一个Archetype迁移到另一个Archetype。