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

日记详情

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

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

Unity DOTS实现千量级粒子量子模拟：ECS、Job System与Burst性能优化实战

发布时间：2026/8/11 16:22:40 三亩地 编程学习日记
Unity DOTS实现千量级粒子量子模拟：ECS、Job System与Burst性能优化实战

1. 项目概述：当粒子模拟遇上性能瓶颈

如果你在Unity里做过稍微复杂点的粒子效果，比如烟雾、火焰或者流体，肯定遇到过那个经典的天花板：粒子数量一多，帧率就直线下降。传统的GameObject + MonoBehaviour模式，每个粒子都是一个独立的对象，带着一堆组件，Unity引擎需要一帧一帧地去遍历、更新它们。当粒子数量达到几百上千时，CPU就开始不堪重负，更别提什么“千量级”甚至“万量级”的模拟了。这不仅仅是做特效的问题，在需要大量实体进行物理或逻辑运算的领域，比如策略游戏、大规模人群模拟，或者我们今天要聊的——量子现象的视觉化模拟，性能瓶颈尤为突出。

所谓“千量级粒子量子模拟”，听起来很科幻，其实核心目标很明确：在屏幕上实时驱动成千上万个粒子，让它们按照特定的物理规则（比如量子力学中的概率云、隧穿效应、干涉等概念进行简化模拟）进行运动和交互，并且保持流畅的交互帧率。这绝不仅仅是把粒子渲染出来那么简单，背后的计算密度非常高。每个粒子可能都需要根据其周围其他粒子的状态，实时计算受力、更新位置和速度。这种O(N²)复杂度的计算，用传统方式几乎是不可能完成的任务。

这就是Unity DOTS（Data-Oriented Technology Stack，面向数据的技术栈）大显身手的地方。DOTS不是某个单一功能，而是一套旨在彻底释放多核CPU性能的编程范式和工具集，其核心三驾马车正是ECS（Entity Component System）、Job System和Burst Compiler。简单来说，ECS让你用“表格”而不是“对象”来思考数据；Job System帮你安全、高效地把计算任务拆分到多个CPU核心上；Burst Compiler则将这些任务编译成接近机器码的高效本地代码。三者结合，目标直指一个：将数据的处理方式从“面向对象”转变为“面向CPU缓存”，榨干硬件的每一分性能。接下来，我们就一层层剥开DOTS的外壳，看看它到底是如何让“千量级量子粒子舞动起来”的。

2. 核心架构解析：为什么是ECS、Job与Burst？

在动手写一行代码之前，我们必须彻底理解为什么这套组合拳能解决性能问题。这关乎底层思维模式的转变。

2.1 ECS：从“对象网络”到“数据表格”

传统OOP（面向对象编程）在游戏开发中，我们习惯把游戏世界里的每个东西都建模成一个GameObject，它挂载着各种MonoBehaviour组件。一个粒子可能是一个GameObject，上面挂着ParticleRenderer、Rigidbody（如果要做物理）和一个自定义的ParticleBehavior脚本。引擎每帧要调用成千上万个Update()方法，这些方法散布在内存各处，CPU为了执行它们，需要在内存中跳来跳去，导致大量的缓存未命中。缓存未命中是性能的头号杀手，因为从主内存读取数据比从CPU缓存读取要慢几十甚至上百倍。

ECS彻底颠覆了这一点。它的核心思想是数据与行为分离，并且数据按类型连续存储。

  • Entity（实体）：仅仅是一个ID，一个轻量级的标识符，代表游戏世界中的一个“东西”。它本身不包含任何数据或逻辑。
  • Component（组件）：纯粹的数据结构（struct），只包含状态数据。例如，一个PositionComponent只包含float3 xyz坐标；一个VelocityComponent只包含float3速度向量。
  • System（系统）：包含所有逻辑的函数。它负责处理拥有特定组件组合的实体。例如，一个MovementSystem会遍历所有同时拥有PositionComponent和VelocityComponent的实体，并更新它们的位置。

关键在于数据的组织方式。在ECS中，所有同类型的Component会被紧密地、连续地存储在内存的一块区域中，就像一个数组或数据库表格。对于我们的粒子模拟，所有粒子的位置数据在一个连续数组里，所有速度数据在另一个连续数组里。当MovementSystem运行时，它是在一个循环里，顺序地、高速地遍历这两个数组，进行简单的向量加法运算。这种顺序访问模式对CPU缓存极其友好，可以一次性将一大块数据加载到高速缓存中，后续计算几乎都在缓存中完成，速度极快。

实操心得：刚开始从MonoBehaviour转向ECS时，最大的思维障碍是“找不到对象了”。你不再是通过GameObject.Find或GetComponent来操作单个实体，而是定义一个System，让它去处理符合条件的一整批实体。这种“批处理”思维是性能优化的关键。

2.2 Job System：让多核CPU真正忙起来

现代CPU都是多核心的，但传统的Unity主线程是单线程的，大部分游戏逻辑都在这个线程上跑，其他核心可能处于“围观”状态。Job System 提供了在多个核心上安全、高效地运行代码的能力。

你可以把Job看作一个定义了Execute()方法的结构体，里面包含它需要处理的数据。Job System 的核心优势在于：

  1. 并行性：你可以创建多个相同的Job，让它们在不同的数据切片上并行执行。例如，把一万个粒子分成4份，创建4个Job，让4个CPU核心同时计算。
  2. 安全性：它通过依赖关系自动解决多线程中的数据竞争问题。你可以声明一个Job是“读”某个数据还是“写”某个数据，系统会确保有写入依赖的Job在读取该数据的Job完成后才执行。

在我们的粒子量子模拟中，最耗时的往往是粒子间相互作用力的计算。如果采用最朴素的O(N²)双循环，计算量随粒子数平方增长。利用Job System，我们可以将这个双循环拆解。例如，使用IJobParallelFor，让每个Job实例负责计算一个粒子受到的所有其他粒子的力，这些Job可以并行执行。虽然整体复杂度没变，但计算时间被平摊到了多个核心上，实际耗时大幅减少。

2.3 Burst Compiler：将C#变成“超级赛亚人”

Burst 是一个 LLVM 后端的编译器，它专门针对 Unity 的 Job System 编译代码。你写的Job代码是C#，但Burst会把它编译成高度优化的、针对当前CPU指令集（如SSE， AVX）的本地代码。这带来了几个数量级的性能提升：

  • 消除托管代码开销：.NET的垃圾回收、虚拟方法调用、数组边界检查等在Burst编译后几乎被消除或极度优化。
  • SIMD指令集优化：单指令多数据流。比如，一个普通的加法循环是逐个加，而使用SIMD指令，可以一次对4个float（SSE）或8个float（AVX）同时进行加法运算。Burst编译器能自动识别循环中的可向量化操作，并生成SIMD指令。这对于我们粒子计算中大量的向量（float3）运算是巨大的福音。

三者如何协同工作？

  1. 你用ECS组织数据（连续数组）。
  2. 你编写一个IJobParallelForJob，定义如何处理这些数据（例如，更新位置：positions[i] += velocities[i] * deltaTime）。
  3. 你调度（Schedule）这个Job，Job System 管理它的多线程执行。
  4. 在编译时，Burst介入，将这个Job的C#代码编译成极度优化的机器码。
  5. 最终，你的粒子更新逻辑以接近C++的性能、在多核上并行、以缓存友好的方式运行。

3. 量子粒子模拟的核心实现细节

理解了架构，我们来看具体怎么实现一个简化版的“量子粒子”模拟。这里的“量子”并非完全真实的物理模拟，而是借鉴一些概念（如概率幅、势场影响）来创造视觉上符合直觉的、有“量子味道”的行为。

3.1 组件设计：定义粒子的状态

首先，我们定义粒子需要哪些数据。在ECS中，这些就是Component。

using Unity.Entities; using Unity.Mathematics; // 位置组件 public struct ParticlePosition : IComponentData { public float3 Value; } // 速度（或动量）组件 public struct ParticleVelocity : IComponentData { public float3 Value; } // 为了模拟量子特性，我们可以添加一个“概率幅”或“相位”组件 // 这可以用来影响粒子的运动或渲染颜色，模拟波函数特性 public struct ParticlePhase : IComponentData { public float Value; // 范围 [0, 2*PI] } // 一个标签组件，用于标记这是我们的“量子粒子” public struct QuantumParticleTag : IComponentData {}

3.2 系统设计：编写粒子行为逻辑

系统是逻辑发生的地方。我们需要至少两个系统：一个更新粒子运动，一个处理粒子间的“量子相互作用”。

3.2.1 运动更新系统这个系统很简单，就是经典的position += velocity * time。

using Unity.Burst; using Unity.Collections; using Unity.Entities; using Unity.Jobs; using Unity.Mathematics; [BurstCompile] // 关键：启用Burst编译 public partial struct ParticleMovementSystem : ISystem { [BurstCompile] public void OnUpdate(ref SystemState state) { float deltaTime = SystemAPI.Time.DeltaTime; // 通过Job来并行更新所有粒子的位置 var job = new MovementJob { DeltaTime = deltaTime }; // 自动根据实体数量并行执行 job.ScheduleParallel(); } [BurstCompile] public partial struct MovementJob : IJobEntity { public float DeltaTime; // 这个Execute方法会对每个拥有ParticlePosition和ParticleVelocity的实体执行 private void Execute(ref ParticlePosition position, in ParticleVelocity velocity) { position.Value += velocity.Value * DeltaTime; } } }

3.2.2 量子相互作用系统（简化版）这是模拟的核心。一个非常简化的模型是：每个粒子都受到一个全局“势场”和其他粒子的“概率排斥/吸引”影响。我们可以模拟一种类似“库仑力”但带有相位干涉的效果。

[BurstCompile] public partial struct QuantumInteractionSystem : ISystem { [BurstCompile] public void OnUpdate(ref SystemState state) { // 获取所有粒子的位置、速度、相位数据 // 注意：为了在Job中访问所有数据，我们需要NativeArray var positions = SystemAPI.QueryBuilder().WithAll<ParticlePosition>().Build().ToComponentDataArray<ParticlePosition>(Allocator.TempJob); var phases = SystemAPI.QueryBuilder().WithAll<ParticlePhase>().Build().ToComponentDataArray<ParticlePhase>(Allocator.TempJob); // 创建一个NativeArray来存储计算出的加速度 var accelerations = new NativeArray<float3>(positions.Length, Allocator.TempJob); // 调度一个并行Job来计算相互作用力 var forceJob = new CalculateForceJob { Positions = positions, Phases = phases, Accelerations = accelerations }; // 我们需要获取这个Job的句柄来等待它完成 var forceHandle = forceJob.Schedule(positions.Length, 64, state.Dependency); // 每64个粒子一个批次 // 再调度一个Job，用计算出的加速度去更新速度 var updateJob = new UpdateVelocityJob { Accelerations = accelerations, DeltaTime = SystemAPI.Time.DeltaTime }; // 这个Job依赖于forceJob完成 var updateHandle = updateJob.ScheduleParallel(forceHandle); // 将依赖关系链返回给ECS系统，确保执行顺序 state.Dependency = updateHandle; // 安排数据数组在Job完成后被释放（非常重要！） positions.Dispose(updateHandle); phases.Dispose(updateHandle); accelerations.Dispose(updateHandle); } [BurstCompile] private struct CalculateForceJob : IJobParallelFor { [ReadOnly] public NativeArray<ParticlePosition> Positions; [ReadOnly] public NativeArray<ParticlePhase> Phases; [WriteOnly] public NativeArray<float3> Accelerations; public void Execute(int index) { float3 totalForce = float3.zero; float3 myPos = Positions[index].Value; float myPhase = Phases[index].Value; // 遍历所有其他粒子（这是一个O(N²)的计算，但被并行化了） for (int j = 0; j < Positions.Length; j++) { if (j == index) continue; // 排除自身 float3 otherPos = Positions[j].Value; float otherPhase = Phases[j].Value; float3 delta = otherPos - myPos; float distance = math.length(delta); float minDistance = 0.1f; // 防止除零 distance = math.max(distance, minDistance); // 一个简化的“量子”力模型： // 1. 基础排斥力，与距离平方成反比（类似电磁力） float repulsion = 1.0f / (distance * distance); // 2. 相位干涉项：如果相位接近，力增强；相位相反，力减弱。这里用余弦模拟。 float phaseDiff = math.cos(myPhase - otherPhase); float interferenceFactor = 1.0f + 0.5f * phaseDiff; // 在0.5到1.5之间变化 float3 force = math.normalize(delta) * repulsion * interferenceFactor; totalForce += force; } // 假设粒子质量为1，加速度等于力 Accelerations[index] = totalForce; } } [BurstCompile] public partial struct UpdateVelocityJob : IJobEntity { [ReadOnly] public NativeArray<float3> Accelerations; public float DeltaTime; public void Execute([EntityIndexInQuery] int index, ref ParticleVelocity velocity) { velocity.Value += Accelerations[index] * DeltaTime; } } }

注意事项：上面的CalculateForceJob是一个O(N²)的双重循环，即使并行化，在粒子数极大时（比如超过1万）也会成为瓶颈。在实际生产项目中，我们会采用更高级的优化，如：

  1. 空间分割算法：如使用Unity.Collections中的NativeMultiHashMap实现网格或四叉树/八叉树，将粒子按空间位置分组，每个粒子只与邻近网格中的粒子计算相互作用，将复杂度降至接近O(N)。
  2. 近似算法：如Barnes-Hut树（用于N体问题）或快速多极子方法，通过近似计算远距离粒子的集体效应来大幅减少计算量。
  3. GPU计算：对于超大规模模拟，最终可能需要将力计算部分通过ComputeShader转移到GPU上。DOTS可以与Unity的渲染和计算管线结合，但这需要更复杂的架构。

3.3 渲染与数据同步

ECS管理的是逻辑实体，如何让它们在屏幕上显示？这里需要用到Hybrid Renderer（现为Entities Graphics）。我们为实体添加渲染相关的组件。

// 在创建粒子实体时，除了逻辑组件，还要添加渲染组件 public partial class ParticleSpawnerSystem : SystemBase { protected override void OnUpdate() { if (/* 满足生成条件 */) { var ecb = new EntityCommandBuffer(Allocator.Temp); // 使用预制件或原型方式创建实体 var archetype = EntityManager.CreateArchetype( typeof(ParticlePosition), typeof(ParticleVelocity), typeof(ParticlePhase), typeof(QuantumParticleTag), // 以下是渲染相关组件 typeof(LocalToWorld), // 变换矩阵 typeof(RenderMesh) // 或 Renderer， 在Entities Graphics中可能是MaterialMeshInfo等 ); for (int i = 0; i < 1000; i++) { var entity = ecb.CreateEntity(archetype); ecb.SetComponent(entity, new ParticlePosition { Value = /* 随机位置 */ }); ecb.SetComponent(entity, new ParticleVelocity { Value = float3.zero }); ecb.SetComponent(entity, new ParticlePhase { Value = /* 随机相位 */ }); // 渲染组件数据也需要设置，例如共享的Mesh和Material } ecb.Playback(EntityManager); ecb.Dispose(); } } }

Entities Graphics系统会在后台自动将拥有LocalToWorld和渲染组件的实体的ParticlePosition转换为变换矩阵，并提交给Unity的渲染管线进行绘制。这个过程是高效的，因为它也是批处理的。

4. 性能优化深度剖析与实战踩坑记录

实现功能只是第一步，让千量级模拟真正流畅运行，需要深入的优化和大量的实践调试。

4.1 Burst编译优化技巧

  • 使用Mathematics库：务必使用Unity.Mathematics中的float3,quaternion,matrix等类型，而不是Unity引擎的Vector3,Quaternion。前者是struct，内存布局明确，能被Burst完美优化；后者是class，包含大量引擎关联数据，无法被Burst高效编译。
  • 避免Job内的内存分配：在Job的Execute方法中，绝对不要使用new关键字或任何会导致托管堆分配的操作。所有数据都应在Job外部通过NativeArray或NativeContainer分配好，然后以[ReadOnly]或[WriteOnly]的方式传入Job。
  • 循环向量化：Burst能自动向量化简单的循环。确保你的循环体内部是简单的数学运算，避免if分支（尤其是依赖循环变量的分支）。如果必须有分支，考虑使用math.select或位运算来替代。
  • [BurstCompile]属性：确保你的Job结构体和包含Schedule调用的方法都加上了[BurstCompile]属性。可以在Unity编辑器的Jobs -> Burst -> Enable Compilation中开启Burst，并在Jobs -> Burst -> Show Timelines中查看每个Job是否被Burst编译（显示为粉色条）。

4.2 Job System调度最佳实践

  • 选择合适的Job类型：
    • IJob：单线程任务。
    • IJobParallelFor：并行任务，适用于处理一个大的NativeArray，每个索引独立。
    • IJobEntity：最方便处理ECS实体的Job，自动生成查询和并行化。推荐优先使用。
    • IJobChunk：更底层的并行，直接处理ArchetypeChunk，灵活性最高，性能也最好，但代码更复杂。
  • 设置合理的批次大小（BatchSize）：在ScheduleParallel或IJobParallelFor.Schedule时，可以指定批次大小。太小会增加调度开销，太大会导致负载不均衡。通常从64或128开始测试，根据Profiler结果调整。
  • 正确处理依赖关系：这是Job System编程中最容易出错的地方。如果Job B需要读取Job A写入的数据，那么必须通过JobHandle建立依赖：JobHandle jobBHandle = jobB.Schedule(jobAHandle);。ECS的System基类（如SystemBase）通过Dependency属性帮你管理了大部分依赖，但在手动调度复杂Job链时需格外小心。

4.3 内存管理与数据布局

  • NativeContainer的生命周期管理：NativeArray,NativeList等必须显式地分配(Allocator.Temp,.TempJob,.Persistent)和释放(Dispose())。Allocator.TempJob分配的内存在Job结束后需要释放，通常将Dispose调用与最终JobHandle关联：myArray.Dispose(jobHandle);。
  • 组件布局策略：
    • 紧凑布局：尽量让频繁一起访问的组件在内存中靠近。ECS的Archetype机制已经帮你做了很多，但你可以通过将紧密相关的字段放在同一个Component里来进一步提升缓存局部性。
    • 避免IComponentData中的引用类型：Component必须是不可变的struct，不能包含对托管对象（如class）的引用。
  • 使用EntityCommandBuffer（ECB）：在Job或并行上下文中不能直接创建/销毁实体或修改结构化的组件数据。必须使用EntityCommandBuffer来记录这些命令，在主线程上统一回放。这是保证线程安全的关键。

4.4 常见问题与排查技巧实录

问题1：模拟运行几秒后突然崩溃，报错“InvalidOperationException: The NativeArray has been deallocated”

  • 原因：这是最典型的“Job依赖”或“内存生命周期”问题。你调度了一个Job，它引用了一个NativeArray，但在Job还没执行完时，这个数组就被释放了(Dispose)了。
  • 排查：
    1. 检查所有NativeContainer的Dispose调用，确保它们是在依赖它们的最后一个Job完成之后才执行的。正确做法是将Dispose与最终JobHandle关联。
    2. 在System的OnUpdate中，如果你创建了临时的NativeArray，确保在方法结束前安排好它的释放。使用Allocator.Temp分配的数组在方法结束时自动释放，但前提是它没有被任何未完成的Job引用。
  • 解决：仔细绘制你的Job依赖关系图。使用JobHandle.CombineDependencies来合并多个依赖。始终遵循“谁分配，谁在合适时机释放”的原则。

问题2：开启了Burst，但Profiler里看到Job还是运行在托管代码上（白色条），没有粉色条。

  • 原因：
    1. Job代码中包含了Burst不支持的操作，如调用非Burst编译的静态方法、使用Debug.Log、尝试访问托管对象等。
    2. 没有为Job结构体或调度方法添加[BurstCompile]属性。
    3. Burst编译器被全局关闭。
  • 排查：
    1. 在Burst Inspector（Window -> Analysis -> Burst -> Open Inspector）中查看该Job的编译日志，通常会有详细的错误信息告诉你哪里不支持。
    2. 检查代码，移除所有非Burst友好的代码。将必要的配置数据通过NativeArray或值类型传入。
  • 解决：将复杂的初始化逻辑移到Job外部。使用[ReadOnly] public float SomeParameter;的方式将标量参数传入Job。

问题3：粒子数量上去后（比如5000+），帧率反而没有达到预期，甚至比传统方式还慢。

  • 原因：
    1. 算法复杂度：如果你的相互作用力计算是O(N²)的，即使并行化，计算量本身也会成为瓶颈。5000个粒子就是2500万次计算每帧。
    2. 缓存颠簸：虽然ECS数据连续，但如果你的Job随机访问另一个巨大的数组（例如在力计算中随机访问所有其他粒子的位置），仍然会导致缓存效率低下。
    3. Job调度开销：如果每个Job的工作量太小（比如只计算几个粒子），那么创建和管理Job线程的开销可能超过计算本身。
  • 排查：使用Unity Profiler的Deep Profile模式，特别是Jobs和Burst采样器，查看每个Job的执行时间、线程利用率和是否有空闲。
  • 解决：
    1. 优化算法：引入空间数据结构（如网格、四叉树），将O(N²)降为O(N log N)或近似O(N)。
    2. 调整批次大小：增加ScheduleParallel的batchSize参数，让每个Job处理更多数据，减少调度次数。
    3. 数据局部性优化：在力计算Job中，考虑先将所有粒子数据复制到NativeArray中，确保在循环中顺序访问，而不是通过ComponentLookup随机访问实体组件（后者可能跳内存）。

问题4：粒子的渲染看起来“卡顿”或者位置更新不及时。

  • 原因：读写竞争。你的运动更新Job（写位置）和渲染系统（读位置）在同一帧内没有正确的依赖关系。可能渲染系统在运动Job完成之前就开始读取位置数据了。
  • 排查：检查渲染相关系统（如RenderMeshSystemV2或其变体）与你的ParticleMovementSystem在SystemOrder中的顺序，或者它们之间的JobHandle依赖。
  • 解决：在Unity的System Ordering窗口中，确保你的逻辑系统在渲染系统之前执行。更精确的做法是，如果你的渲染需要自定义数据，应继承ISystem并手动管理依赖，将你的逻辑Job的JobHandle合并到World.GetExistingSystem<RenderSimulationSystemGroup>().Dependency中。

5. 从千级到万级：进阶优化策略与扩展思路

当你成功实现了一个流畅的千级粒子模拟后，可能会想挑战更大的规模。这里有一些进阶方向：

5.1 层级化细节（LOD）并非所有粒子都需要每帧进行精确的相互作用计算。可以将粒子系统分层：

  • 近场粒子：使用高精度算法（如直接N²计算或精细网格）计算。
  • 远场粒子：使用低精度算法（如将远处粒子聚类，计算集群间的平均作用力）。 这需要动态的空间划分和粒子重要性判断。

5.2 异构计算：CPU + GPU 协同对于超大规模模拟（十万级以上），CPU即使有DOTS也可能力不从心。此时可以将最耗时的力计算部分卸载到GPU。

  1. 使用ComputeShader：将粒子位置、速度数据放入ComputeBuffer。
  2. 在ComputeShader中实现相互作用算法。GPU拥有数千个核心，非常适合这种大规模并行、计算密集型的任务。
  3. 每帧：CPU将数据上传到GPU -> GPU执行ComputeShader -> CPU将结果读回（或直接在GPU用于渲染）。
  4. 与DOTS结合：可以创建一个System，它的OnUpdate中调度一个Job，这个Job的唯一任务就是调用Graphics.ExecuteCommandBuffer来触发ComputeShader，并管理CPU与GPU之间的数据同步。这需要处理更复杂的同步和资源管理。

5.3 动态粒子数量与内存池粒子系统常常需要动态创建和销毁。频繁的实体创建销毁是昂贵的。解决方案是使用对象池思想：

  1. 初始化时创建最大数量的粒子实体，并给它们添加一个ParticleInactiveTag组件。
  2. 需要生成粒子时，从池中找一个“休眠”的实体，移除ParticleInactiveTag，并初始化其位置、速度等数据。
  3. 粒子“死亡”时，不是销毁实体，而是给它添加回ParticleInactiveTag，并将其位置移到视野外或重置状态。 这样可以完全避免运行时的内存分配和实体结构变化，保持性能稳定。

实现千量级乃至更大量级的粒子量子模拟，是一个将性能优化思维贯穿始终的实践。从抛弃传统的面向对象思维，拥抱面向数据的ECS架构；到安全地利用多核并行的Job System；再到通过Burst编译器将逻辑代码推向原生性能的极限。每一步都充满了挑战，但也带来了传统方式无法企及的性能红利。这个过程让我深刻体会到，现代高性能计算的关键，往往不在于使用更快的硬件，而在于如何以最契合硬件工作方式（尤其是CPU缓存和并行核心）的模式去组织和处理数据。DOTS正是Unity为游戏和高性能交互模拟领域提供的一套应对这一挑战的现代化答案。当你看到成千上万的粒子在屏幕上遵循着复杂的规则流畅运行，并且CPU占用还游刃有余时，那种成就感，是对所有底层优化努力的最佳回报。

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