三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Unity DOTS 2.0性能优化：规避五大架构反模式，释放Burst与Job System潜力

发布时间：2026/8/4 18:20:18 三亩地 编程学习日记
Unity DOTS 2.0性能优化：规避五大架构反模式，释放Burst与Job System潜力

1. 项目概述：DOTS 2.0性能陷阱的深度剖析

如果你正在使用Unity的DOTS（面向数据的技术栈）2.0来构建高性能应用，尤其是游戏，那么“Burst编译器失效”和“Job System卡顿”这两个词，很可能已经让你头疼不已。这不仅仅是两个孤立的问题，它们往往是更深层次架构设计缺陷的“症状”。在我过去几年深度参与多个DOTS项目的经历中，我发现超过98%的团队，包括我自己，都曾或多或少地掉进过一些极其隐蔽的陷阱里。这些陷阱不会立刻让程序崩溃，但它们会像慢性毒药一样，悄无声息地侵蚀掉DOTS带来的所有性能红利，最终让你怀疑人生：为什么用了最先进的技术栈，性能反而更差了？

这篇文章，就是一次彻底的“排雷”行动。我不会泛泛而谈DOTS的优点，而是直接切入那些最折磨人、最容易被忽视的“架构反模式”。所谓反模式，就是那些看似合理、甚至是从传统面向对象编程（OOP）经验中“自然”迁移过来的做法，但在DOTS的数据导向和并行化世界里，它们却是性能的“杀手”。我们将聚焦于五类最典型的隐蔽型反模式，它们直接关联着Burst编译器的优化失效和Job System的调度卡顿。无论你是刚刚接触DOTS 2.0的新手，还是已经踩过一些坑的老手，理解这些反模式背后的原理，都能帮你构建出真正高效、稳定的DOTS架构，让Burst和Job System发挥出它们应有的威力。

2. 核心反模式一：实体与组件布局的“内存刺客”

这是所有DOTS性能问题的根源之一，也是最基础、最隐蔽的一类。DOTS的核心思想是“数据导向”，这意味着CPU缓存命中率和内存访问模式直接决定了性能上限。错误的实体和组件布局，会让Burst编译器生成的代码效率大打折扣，甚至引发Job System内部的内存屏障和同步开销。

2.1 碎片化组件存储：缓存未命中之源

在传统MonoBehaviour中，我们把数据和行为封装在一起。在DOTS中，我们使用IComponentData。一个常见的反模式是，为一个逻辑概念创建过多细粒度的组件。例如，为一个“角色”实体分别创建HealthComponent、ManaComponent、StaminaComponent，每个组件只有一两个float字段。

为什么这是反模式？ECS（实体组件系统）的Archetype（原型）系统会根据实体拥有的组件类型组合，为其分配内存块（Chunk）。当你频繁地添加、移除这些细粒度组件时（比如角色受伤时减血，施法时减蓝），实体会在不同的Archetype之间移动。更糟糕的是，当System需要遍历处理拥有HealthComponent的所有实体时，如果这些实体的其他组件构成不同，它们可能散布在多个不同的Chunk中。Burst编译器优化的循环是顺序访问连续内存，而这种碎片化存储导致内存访问是“跳跃式”的，引发大量的CPU缓存未命中（Cache Miss）。缓存未命中的代价可能是命中情况的数十倍。

正确做法与实操要点：

  1. 组件聚合：将逻辑上紧密相关、生命周期一致的数据合并到一个组件里。例如，创建AttributesComponent，包含health，mana，stamina等字段。这确保了这些数据在内存中紧密排列。
  2. 共享组件慎用：ISharedComponentData可以用于分组，但过度使用或频繁修改共享组件值，会导致实体在Chunk间大规模重组，开销巨大。仅将其用于真正的、不常变的分类，如渲染材质ID、队伍归属等。
  3. 利用IBufferElementData：对于可变长度的数组数据（如库存物品列表、技能效果列表），使用DynamicBuffer。它作为组件的一部分存储在Chunk内，访问效率远高于在IComponentData里放一个托管数组的引用。

注意：不要为了“设计上的纯洁性”而过度拆分组件。在DOTS中，数据布局的物理特性（内存连续性）比逻辑分类的优雅性更重要。

2.2 错误的查询与遍历：隐式的性能黑洞

即使组件布局合理，在System中查询和遍历实体的方式也至关重要。反模式通常体现在Entities.ForEach或IJobEntity的查询构造上。

典型反模式示例：

// 反模式：在Job中通过EntityManager或ComponentLookup频繁获取其他实体的数据 [BurstCompile] public partial struct BadJob : IJobEntity { public ComponentLookup<TransformComponent> TransformLookup; public EntityCommandBuffer Ecb; public void Execute(Entity entity, ref DamageComponent damage) { // 假设damage.sourceEntity是造成伤害的实体 if (TransformLookup.TryGetComponent(damage.sourceEntity, out var sourceTransform)) { // ... 一些计算 } // 可能还创建/销毁实体 if (damage.health <= 0) Ecb.DestroyEntity(entity); } }

为什么这是反模式？ComponentLookup在Job中的使用本身是安全的，但频繁的TryGetComponent调用，特别是对大量实体进行随机访问，破坏了内存访问的局部性，同样导致缓存未命中。更严重的是，在Job内部使用EntityCommandBuffer进行结构性更改（创建/销毁实体、添加/移除组件）本身没问题，但如果这个Job被调度时依赖关系没处理好，或者更改过于频繁，会迫使Job System在调度帧引入同步点，可能造成主线程卡顿，等待所有相关Job完成才能进行结构性更改的合并。

正确做法与实操要点：

  1. 数据本地化：尽可能在同一个Chunk内完成计算。如果A实体的计算需要B实体的数据，考虑是否可以通过重构，将B的数据以副本或摘要的形式预先存到A的组件中（例如，将附近敌人的位置信息定期写入一个Buffer）。
  2. 批量处理结构性更改：尽量避免在遍历大量实体的核心逻辑Job中穿插零星的结构性更改。更好的模式是：核心计算Job只输出“意图”（如将需要销毁的实体ID写入一个NativeList<Entity>），然后在主线程或一个单独的、后续的Single-Threaded Job中，使用EntityCommandBuffer批量执行这些更改。
  3. 精细化依赖管理：使用Schedule或ScheduleParallel时，显式地管理JobHandle依赖关系。确保读写同类型组件的Job不能并行，必须顺序执行。错误的并行会导致竞态条件，正确的依赖管理能最大化并行度，避免不必要的阻塞。

3. 核心反模式二：Burst编译器的“沉默杀手”

Burst编译器能将C# Job代码编译成高度优化的原生代码，但它的优化能力并非无条件的。一些看似无害的代码模式，会让Burst“哑火”，或者生成非最优的代码。

3.1 托管对象与非托管代码的边界污染

这是导致Burst编译失败或优化受限的最常见原因。Burst只能编译“安全代码”子集，其核心限制之一就是不能直接访问托管对象（Managed Objects）。

隐蔽反模式示例：

public partial class BadSystem : SystemBase { private List<Vector3> _managedList = new List<Vector3>(); // 托管对象 protected override void OnUpdate() { // 反模式：在Schedule的Job中捕获或使用了托管对象的引用 Entities .ForEach((ref Translation trans) => { // 即使只是读取长度，也会阻止Burst编译！ if (_managedList.Count > 0) { // ... } }).ScheduleParallel(); // 这行可能无法被Burst编译，或者编译后性能低下 } }

为什么这是反模式？即使代码看起来只是读取了一个Count属性，Burst编译器在尝试分析时，发现该Job依赖于一个托管对象，它可能无法保证该对象在Job执行期间的内存安全性和生命周期，因此会退而求其次：要么完全拒绝编译（在Editor中你会看到警告），要么生成一个回退到Mono（非Burst）的版本，或者生成一个效率较低的Burst版本，其中包含了对托管环境的调用开销。

正确做法与实操要点：

  1. 彻底的数据迁移：将所有需要在Job中访问的数据，都转换为非托管类型。使用NativeArray<T>，NativeList<T>，BlobAssetReference等。BlobAsset尤其适合存储只读的、复杂的数据结构（如配置表、技能树）。
  2. System状态隔离：将System自身的状态（如配置、缓存）也定义为非托管结构体。如果必须使用托管对象（如从Resources加载的引用），应在OnCreate()中将其数据提取并复制到非托管容器中。
  3. 使用[BurstDiscard]属性：对于极少数必须在Job中执行，但又不得不调用托管代码的情况（如日志记录、调试断言），可以将该方法标记为[BurstDiscard]。但要注意，这会使该方法在Burst编译的Job中不被调用，或者回退到Mono执行，应极其谨慎地使用。

3.2 函数指针与虚接口的滥用

为了代码的灵活性，开发者可能会想在Job中使用委托、函数指针或接口。但在Burst语境下，这需要特别小心。

反模式：在热路径上使用非静态函数指针

// 假设我们有一个计算伤害的策略接口 public interface IDamageCalculator { float Calculate(DamageInfo info); } // 在System中 public partial class BadSystem : SystemBase { protected override void OnUpdate() { var calculator = GetSingleton<IDamageCalculator>(); // 如何存储？这是个问题 // 无法将接口直接用于Burst Job，常见的错误是尝试包装它 } }

为什么这是反模式？Burst编译器对间接调用（通过函数指针、虚方法表）的优化支持有限。动态派发（虚函数调用）会阻碍内联等关键优化。更常见的是，试图将托管接口或复杂委托传入Job会导致编译失败。

正确做法与实操要点：

  1. 优先使用结构体和方法：将算法实现为纯函数（静态方法）或值类型结构体的实例方法。Burst可以很好地内联这些调用。
  2. 使用FunctionPointer<T>：对于必须的动态行为，可以使用Unity.Burst.FunctionPointer<T>。但前提是，指向的函数本身必须是静态方法，并且可用BurstCompiler.CompileFunctionPointer编译。这通常用于插件式系统或高度可定制的算法核心。
  3. 数据驱动替代继承：用数据（组件）和简单的switch语句或查找表来替代复杂的继承层次。例如，不同的伤害类型不是通过不同的IDamageCalculator实现类，而是通过DamageComponent中的一个DamageType枚举，以及一个存储了每种类型伤害系数的BlobAsset来共同决定。

4. 核心反模式三：Job依赖与资源竞争的“死锁迷宫”

Job System的强大在于并行，但并行编程的经典难题——竞态条件、死锁、资源竞争——在DOTS中以一种更隐蔽的方式出现。不合理的Job依赖图是导致帧率卡顿、不稳定的元凶。

4.1 过度保守或过度激进的依赖声明

依赖关系通过JobHandle来管理。反模式出现在两个极端：要么过度依赖，导致并行度不足；要么依赖不足，导致数据竞争。

反模式示例：过度保守

JobHandle handle = default; foreach (var someCondition in conditions) { var job = new MyJob { ... }.Schedule(inputDeps); handle = JobHandle.CombineDependencies(handle, job); // 错误：这串行化了所有Job！ } // 正确应该是：handle = JobHandle.CombineDependencies(handle, job); 但inputDeps需要更新

实际上，如果这些MyJob实例之间没有数据依赖，它们应该并行执行。上述写法错误地将每个新Job依赖于前一个Job的合并句柄，造成了链式串行。

反模式示例：依赖不足

// System A 写入 Translation var jobA = new JobA { ... }.ScheduleParallel(); // System B 读取 Translation， 但错误地没有依赖 jobA var jobB = new JobB { ... }.ScheduleParallel(); // 数据竞争！

正确做法与实操要点：

  1. 理解读写分类：IJobEntity或IJobChunk通过Schedule或ScheduleParallel自动计算依赖。但手动IJob需要你通过[ReadOnly]或[WriteOnly]属性显式声明对NativeContainer（如NativeArray）的访问权限。读写同一容器的Job不能并行。
  2. 绘制依赖图：在复杂系统中，心里或纸上画出一个简单的有向无环图（DAG）。节点是Job，边是依赖关系（A在B之前）。确保没有循环依赖。
  3. 使用Dependency属性：在SystemBase中，正确使用this.Dependency属性。System的OnUpdate()开始时，Dependency包含了所有之前调度且尚未完成的Job。在你的代码中调度新Job后，应该更新Dependency：this.Dependency = myNewJobHandle;或this.Dependency = JobHandle.CombineDependencies(this.Dependency, myNewJobHandle);。SystemBase会在OnUpdate结束时自动将Dependency合并到主世界的依赖系统中。

4.2 主线程与Job线程的同步等待

另一个导致卡顿的常见原因是，主线程（例如在MonoBehaviour的Update中）等待一个尚未完成的Job。这完全阻塞了主线程。

反模式：在主线程中调用JobHandle.Complete()

void Update() { var heavyJob = new HeavyCalculationJob { ... }.Schedule(); // 立即等待完成，主线程卡住！ heavyJob.Complete(); // 使用结果... }

为什么这是反模式？Complete()会阻塞调用线程，直到该Job及其所有依赖的Job都执行完毕。如果在主线程的游戏循环中这样做，就等于放弃了Job System提供的异步优势，将并行计算又拉回了串行，主线程卡顿随之而来。

正确做法与实操要点：

  1. 帧异步，帧消费：标准的DOTS模式是在一帧内调度Job，让它们在帧末由Job Worker线程执行，在下一帧或更晚的帧消费结果。通过ComponentSystemGroup的更新顺序来控制。
  2. 使用EntityCommandBuffer：这是处理跨线程结构性更改的关键。Job将命令写入ECB，主线程在ECB的Playback时（通常在System的OnUpdate末尾或下一帧初）批量执行。这避免了同步等待。
  3. 必要时使用JobHandle.ScheduleBatchedJobs()：这个API会提示Job System尽快开始执行已调度的Job。但它通常不是必须的，因为Unity有自己的调度策略。滥用它可能会打乱最优调度。

5. 核心反模式四：资源管理与生命周期的“内存泄漏”

DOTS使用非托管内存（NativeContainer），这意味着没有垃圾回收器（GC）自动为你管理生命周期。内存泄漏和访问已释放内存的异常（InvalidOperationException: The NativeArray has been disposed）是家常便饭。

5.1 NativeContainer生命周期管理不当

反模式：在局部作用域创建，在Job完成后访问

public partial class LeakySystem : SystemBase { protected override void OnUpdate() { var tempArray = new NativeArray<float>(100, Allocator.Temp); var job = new MyJob { data = tempArray }.Schedule(); // 错误！Job可能还没执行完，但tempArray已经离开了作用域，理论上可以被释放。 // 实际上，Schedule会隐式增加引用计数，但依赖关系混乱时仍危险。 this.Dependency = job; // OnUpdate结束，tempArray（如果使用Allocator.Temp）应该被释放，但job还在用！ } }

为什么这是反模式？Allocator.Temp分配的内存生命周期为一帧，且在方法返回时（或通过using语句）就应释放。如果Job还在使用这块内存，就会发生访问冲突。Allocator.TempJob的生命周期稍长（4帧），但也需要精确管理。

正确做法与实操要点：

  1. 遵循分配器使用规范：
    • Allocator.Temp：用于极短生命周期的临时数据，绝对不能传递给任何可能被调度的Job。只能在当前方法栈帧内同步使用。
    • Allocator.TempJob：用于在Job中使用的数据。其生命周期为4帧。必须在用于调度的Job句柄上调用Complete()之后，才能安全地释放（Dispose()）。通常模式是：创建 -> 调度Job -> 在适当的地方（如下一帧的System或主线程）JobHandle.Complete()->Dispose()。
    • Allocator.Persistent：用于生命周期很长的数据。必须手动管理，在确定不再使用时调用Dispose()，否则就是内存泄漏。
  2. 使用DisposeOnCompletion：IJob和IJobParallelFor等Job类型支持[DeallocateOnJobCompletion]属性（对于集合类Job），但更通用的是在SystemBase中，依赖this.Dependency来自动管理。更清晰的做法是使用NativeArray等的扩展方法，或者自己严格跟踪。
  3. 依赖注入与完成：确保在释放任何NativeContainer之前，所有依赖它的Job都已经通过JobHandle.Complete()完成了。SystemBase的Dependency属性帮你管理了大部分情况，但当你自己创建临时容器时，需要格外小心。

5.2 BlobAsset的创建与引用丢失

BlobAsset是存储不可变结构化数据的强大工具，但创建和引用它也有陷阱。

反模式：每帧创建BlobAsset

protected override void OnUpdate() { var builder = new BlobBuilder(Allocator.Temp); ref var root = ref builder.ConstructRoot<MyData>(); // ... 填充数据 var blobAsset = builder.CreateBlobAssetReference<MyData>(Allocator.Persistent); // 使用blobAsset... // 忘记存储引用，并且每帧都创建新的 }

为什么这是反模式？CreateBlobAssetReference会分配持久化内存。如果每帧都创建而不释放，会造成持久化内存泄漏。此外，构建BlobBuilder本身也有开销。

正确做法与实操要点：

  1. 一次创建，多次引用：BlobAsset应该是只读的、长期存在的数据。在System的OnCreate()或某个初始化阶段创建，并将其引用存储在一个Singleton组件或System的字段中。
  2. 使用BlobAssetStore：对于从序列化数据（如JSON）动态创建BlobAsset的情况，使用BlobAssetStore来缓存和复用已创建的BlobAsset，避免重复构建。
  3. 释放责任：谁创建，谁负责释放。如果BlobAssetReference存储在Singleton中，需要在游戏状态清理时（如退出关卡）手动调用.Dispose()。

6. 核心反模式五：与Unity引擎旧世界的“低效桥梁”

DOTS 2.0并非运行在真空中，我们经常需要与GameObject、MonoBehaviour等Unity旧世界交互。这里的桥梁如果搭建不当，会成为严重的性能瓶颈。

6.1 每帧频繁的GameObject实体转换

通过EntityManager或GameObjectEntity在Entity和GameObject之间进行转换、获取组件，是非常昂贵的操作。

反模式：在Job或每帧循环中调用GetComponent<Transform>()

Entities.ForEach((Entity e) => { // 反模式：通过Entity获取GameObject再获取组件 var go = EntityManager.GetComponentObject<GameObject>(e); var transform = go.transform; // 这会产生GC Alloc和托管调用 }).Run(); // 即使是Run，在主线程，这也非常低效

为什么这是反模式？GetComponentObject涉及托管/非托管边界的互操作和查找，开销大。在性能关键的每帧循环中这样做，会抵消DOTS带来的收益。

正确做法与实操要点：

  1. 数据镜像，异步同步：为需要与GameObject同步的数据（如位置、旋转）建立专门的ECS组件（如Translation，Rotation）。创建一个System（通常用ISystem或SystemBase），它以较低频率（如每几帧）或在变化时，将ECS组件的数据批量复制到关联的GameObject的Transform上。反过来也一样。使用EntityManager的GetComponentDataFromEntity进行批量读取。
  2. 使用TransformAccess和TransformAccessArray：对于大量需要每帧同步的GameObject，Unity提供了TransformAccess和TransformAccessArray，允许在Job中安全地读写Transform。但这仍然比纯ECS的Translation慢，应仅用于必须与物理引擎、动画系统等旧系统交互的边界实体。
  3. Hybrid Renderer V2：对于渲染，务必使用Hybrid Renderer包（现在是ECS Subscene的一部分）。它自动将LocalToWorld等组件数据同步到渲染管线，完全避免了每帧对GameObject的遍历。

6.2 滥用EntityQuery与System更新频率

不是所有System都需要每帧更新。频繁执行不必要的工作是浪费。

反模式：所有System都继承SystemBase并每帧执行OnUpdate对于一些只响应事件（如玩家输入、网络消息）或低频任务（如AI决策、寻路计算）的系统，每帧空跑查询是浪费。

正确做法与实操要点：

  1. 使用ISystem和SystemAPI.Query：ISystem是DOTS 2.0更轻量级的系统接口。你可以更精细地控制其更新。结合SystemAPI.Query，可以在需要时才执行查询。
  2. 手动控制更新：在System内部维护一个计时器或条件判断。例如，一个经济系统可能只需要每秒钟更新一次。
    public partial class EconomySystem : SystemBase { private float _accumulatedTime; protected override void OnUpdate() { _accumulatedTime += Time.DeltaTime; if (_accumulatedTime >= 1.0f) // 每秒执行一次 { _accumulatedTime -= 1.0f; // ... 执行经济逻辑 } } }
  3. 基于事件的触发：使用ECS自身组件作为事件标志。例如，当一个DamageEvent组件被添加到实体时，一个专门处理伤害的System（其查询包含DamageEvent）才会执行工作，并在处理完后立即移除该组件。这实现了高效的事件驱动架构。

7. 常见问题与排查技巧实录

即使理解了所有理论，实战中依然会遇到千奇百怪的问题。下面是我在项目中积累的一些典型问题及其排查思路，希望能帮你快速定位。

7.1 Burst编译警告与错误排查

  • 问题：在Unity Editor中看到“Burst failed to compile”警告，或者Job运行速度没有预期快。
  • 排查步骤：
    1. 查看Burst日志：在Unity Console中，将日志级别切换到“Burst”。编译失败或降级的原因会详细输出在这里。最常见的原因是访问了托管对象、使用了不支持的C#特性（如try-catch、某些反射）、或函数指针使用不当。
    2. 检查Job类型：确保你的Job结构体是IJob，IJobFor，IJobEntity等，并且用[BurstCompile]装饰。IJobEntity和SystemBase的ForEach（如果返回的是JobHandle）通常会自动Burst编译，但也要检查其内部Lambda是否“纯净”。
    3. 简化复现：如果一个大Job编译失败，尝试将其逻辑逐步注释，缩小到能编译的最小代码块，从而定位到具体哪行代码或哪个调用触发了Burst的限制。
    4. 使用[BurstDiscard]：对于确实无法避免的托管调用（如复杂的调试日志），给方法加上[BurstDiscard]属性，确保它不会阻碍主体代码的编译。但需清楚这部分的性能代价。

7.2 Job System卡顿分析与性能调试

  • 问题：游戏运行时出现间歇性卡顿，Profiler显示主线程在等待Job。
  • 排查步骤：
    1. 打开Deep Profiling：在Unity Profiler中启用Deep Profiling，并切换到Timeline视图。观察主线程和Job Worker线程的时间线。
    2. 识别长尾Job：寻找那些执行时间明显长于其他同类型Job的个体。这可能是因为Job内部负载不均衡（例如，某个实体处理的计算量远大于其他实体）。考虑使用IJobParallelFor或IJobEntity时，通过chunk迭代，并确保每个chunk内的工作量大致相当。
    3. 检查依赖链：在Profiler中查看Job之间的依赖关系。是否存在一个很长的串行链？是否有很多Job在等待同一个资源？尝试重构，打破不必要的依赖，增加并行度。
    4. 使用Unity.Profiling：在代码中使用ProfilerMarker来手动标记关键代码段，在Profiler中更清晰地看到每个System和Job内部的时间分布。
    5. 警惕“结构性更改风暴”：如果Profiler显示EntityCommandBuffer.Playback或EntityManager的操作耗时很长，说明可能在同一帧有过于频繁的实体创建/销毁。考虑将结构性更改分散到多帧，或使用延迟销毁（先标记，后清理）策略。

7.3 内存访问违规与稳定性问题

  • 问题：游戏随机崩溃，报错指向NativeArray访问越界、或“已经释放”的错误。
  • 排查步骤：
    1. 检查分配器与生命周期：这是最常见的原因。回顾所有NativeArray，NativeList等的分配器（Allocator.Temp/TempJob/Persistent）是否与使用场景匹配。确保在Job完成前没有释放内存。
    2. 使用安全检查：在开发阶段，保持ENABLE_UNITY_COLLECTIONS_CHECKS定义符号开启。这会增加边界检查和线程安全检查，虽然影响性能，但能提前暴露许多隐蔽的错误。
    3. 线程竞争分析：确认读写同一数据的Job是否被正确设置了依赖关系。如果两个Job并行写入同一NativeArray，结果将是未定义的，可能导致崩溃或数据损坏。使用[NativeDisableParallelForRestriction]时要极度小心，并确保你完全理解其含义。
    4. Entity引用有效性：在Job中通过ComponentLookup访问其他实体时，要意识到这些实体可能在Job执行期间被其他Job销毁。使用HasComponent进行检查，或者设计架构来避免这种“读写-销毁”的竞态条件（例如，使用双缓冲或事件标志，在下一帧再处理销毁）。

7.4 与现有代码库集成时的陷阱

  • 问题：将DOTS逐步引入现有大型MonoBehaviour项目时，框架冲突、管理混乱。
  • 经验心得：
    1. 划清边界：不要试图将每个MonoBehaviour都一对一转换成ECS。从性能最敏感、最符合“数据驱动”特性的模块开始，例如：数千个移动的子弹/粒子、大规模单位寻路与AI决策、环境物品交互等。为非DOTS部分和DOTS部分定义清晰的通信接口。
    2. 使用“胶水”System：创建专门的“胶水”System来负责DOTS世界和GameObject世界之间的数据同步。这些System可以运行在UpdateBefore或UpdateAfter特定的ComponentSystemGroup中，以控制同步时机。
    3. 管理双世界：明确哪些实体是纯DOTS的，哪些是Hybrid的（关联GameObject）。为Hybrid实体设计稳定的Authoring工作流，使用ConvertToEntity或自定义的IConvertGameObjectToEntity。处理好场景加载、卸载时两个世界的状态同步。
    4. 心态转变：最大的挑战往往不是技术，而是思维模式的转变。从“对象做什么”转向“数据是什么，系统处理什么”。拥抱数据驱动设计，你会发现很多之前复杂的对象交互，用ECS的事件和组件状态机来表达会更加清晰和高效。

DOTS 2.0是一套强大的工具，但它要求开发者对底层的数据流动、内存管理和并发模型有更深的理解。避开这些隐蔽的架构反模式，不是靠死记硬背，而是要真正内化“数据导向”和“并行安全”的原则。每一次性能问题的排查，都是对这套心智模型的巩固。当你习惯性地思考数据如何布局、Job如何划分、依赖如何管理时，你就已经跨过了那道门槛，能够驾驭DOTS，释放出硬件真正的潜力。

编程学习 学习日记 实战经验
← 返回列表