Unity DOTS

Unity的数据导向技术栈（Data-Oriented Technology Stack，DOTS）是一组相互配合的技术。Entities包提供实体组件系统（Entity Component System，ECS），C# Job System把工作调度到工作线程，Burst Compiler则把兼容的 .NET IL编译成针对目标CPU优化的机器码。三者可以一起使用，但Burst和Job System并不依赖ECS才能工作。

实体组件系统（Entity Component System） 把标识、数据和行为分开。实体（entity）是带版本信息的句柄；组件（component）保存状态；系统（system）查询特定组件组合并执行逻辑。实体不是一个装着所有字段和方法的对象，也不能简化成“只是一个整数”。

DOTS解决的是批量数据处理问题。传统MonoBehaviour对象可能把同一类字段分散在许多托管对象中，并通过大量独立回调更新；Entities按组件组合组织数据，让系统遍历紧密排列的组件数组。这种布局更适合缓存友好的顺序访问，也让读写集合能够被调度器分析。

这不表示每个Unity项目都应改成ECS。界面、少量独特对象、编辑器工具和以对象关系为主的逻辑，往往继续使用GameObject与MonoBehaviour更清楚。DOTS适合数量多、形状相似、能以数据变换表达的CPU工作；是否值得迁移，要由目标设备上的Profiler数据决定。

一个World拥有实体、组件存储和系统。每种唯一的组件类型组合对应一个 原型（archetype） ；同一原型中的实体存放在一个或多个 块（chunk） 中。Entities 1.4的每个chunk为16 KiB，内部为每种组件类型保存一个紧密排列的数组，另有一个实体ID数组。

系统通过查询声明需要读写哪些组件。SystemAPI.Query<RefRW<A>, RefRO<B>>()表示读取并写入A、只读B；WithAll<T>()、WithNone<T>()等条件进一步缩小匹配集合。查询找到的是符合条件的原型与chunk，不是先扫描每个实体再逐个检查类型。

实体、组件与系统

常见的运行时组件是实现IComponentData的非托管struct。小组件不是目的本身；边界应反映系统实际一起读取和写入的数据。把从不同时访问的字段塞进一个大组件，会增加无关数据传输；把每个标量都拆成一种组件，则会增加原型和查询的复杂度。

ISystem是非托管系统接口，生命周期回调接收ref SystemState。OnUpdate中的普通foreach仍由调用该系统的线程同步执行；只有显式调度Job，工作才可能进入工作线程。给系统加上[BurstCompile]也不会自动把循环并行化。

SystemAPI依赖源码生成，因此包含查询的系统和IJobEntity类型要写成partial。源码生成器会建立查询和访问句柄，编译错误有时会出现在Temp/GeneratedCode下。排查时仍应回到声明的组件访问方式，而不是编辑生成文件。

Job调度与依赖

IJobEntity.Execute的参数定义查询与访问模式：ref是读写，in是只读，值传递的Entity提供当前实体句柄。源码生成器把IJobEntity转换为按chunk工作的Job。ScheduleParallel可以把匹配的chunk分给多个工作线程，但实际并行度仍取决于实体数量、chunk数量、批次和其他依赖。

Job返回的JobHandle是正确性契约。若本系统写入的数据可能与前序Job重叠，新Job必须依赖state.Dependency；调度后又要把返回句柄写回state.Dependency。漏掉任一边都会让后续系统看不见真实依赖，安全检查可能报错，关闭检查后则可能变成竞态条件。

在每帧中途调用Complete()会让主线程等待。同步有时不可避免，例如主线程马上需要Job结果，但机械地完成每个句柄会破坏调度器重叠工作的机会。先把依赖链传下去，只在确实消费结果的边界完成。

Burst编译边界

Burst Compiler 处理High-Performance C#子集。它适合值类型、NativeArray等原生容器以及Unity.Mathematics运算；一般的托管对象、托管数组和任意虚调用不能进入这条编译路径。[BurstCompile]是请求，不是性能证明。

Editor播放模式与Player构建的编译路径不同。开发时还可能暂时执行托管回退版本，因此“能运行”不等于目标构建已使用Burst。应检查Burst Inspector、编译日志和目标Player的Profiler数据，并确认代码没有因托管字段或不支持的调用退出Burst路径。

结构变更与命令缓冲区

添加或移除组件、创建或销毁实体属于 结构变更（structural change） 。组件组合改变后，EntityManager必须把实体移到另一个原型，并可能创建或释放chunk。直接遍历查询时不能随意执行会使查询存储失效的结构变更。

实体命令缓冲区（EntityCommandBuffer，ECB） 先记录命令，之后在指定系统更新时回放。Job可以通过EntityCommandBuffer.ParallelWriter并行记录命令，而回放负责真正修改实体存储。ECB解决了修改时机与线程安全问题，却不会消除结构变更本身的搬移成本。

频繁切换但组件形状不变的状态可以考虑IEnableableComponent。启用或禁用这类组件不会改变实体的原型，查询会按启用位决定是否匹配。不过，低频且持续时间较长的状态仍可能更适合添加或移除组件，不能把所有标签都机械改成可启用组件。

烘焙把编辑数据变成运行时数据

场景中的MonoBehaviour authoring组件适合给设计师编辑，Baker则把它转换成实体组件。烘焙（baking）发生在导入与构建数据流程中，不是每帧把GameObject同步成Entity。运行时系统应读取烘焙结果，而不是依赖authoring对象继续存在。

Baker需要声明它读取的Unity对象和资源依赖，才能在输入变化时正确重新烘焙。生成代码常把旧版ConvertToEntity工作流与当前Baker API混在一起，这类代码即使看起来像Unity C#，也不属于Entities 1.4的当前工作流。

下面四个示例从烘焙数据开始，依次加入同步查询、并行Job和延迟结构变更。它们需要Unity Editor、Entities与Burst包。当前本地工具链没有Unity Editor，也没有这些程序集，因此按约定标记为未执行，没有伪造控制台输出。

定义组件并烘焙authoring数据

UnitAuthoring只负责编辑时输入。Baker取得动态变换实体，并把速度与可切换的移动状态写入运行时组件。

Moving没有字段，但它的启用位有意义。系统可以暂停某个单位而不移除组件，因此暂停与恢复不会把实体搬到不同原型。若状态几乎不改变，普通标签组件也可能更合适。

在ISystem中同步查询

这个系统在自己的OnUpdate中直接遍历查询。RefRW<LocalTransform>声明写入变换，RefRO<MoveSpeed>声明只读速度；禁用Moving的实体不会匹配默认查询。

// # not executed here: Unity Editor 6.6 and Entities 1.4.8 are unavailable.
using Unity.Burst;
using Unity.Entities;
using Unity.Mathematics;
using Unity.Transforms;

[BurstCompile]
public partial struct MovementSystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        var deltaTime = SystemAPI.Time.DeltaTime;

        foreach (var (transform, speed) in
                 SystemAPI.Query<RefRW<LocalTransform>, RefRO<MoveSpeed>>()
                     .WithAll<Moving>())
        {
            transform.ValueRW.Position += new float3(
                0f,
                0f,
                speed.ValueRO.MetersPerSecond * deltaTime);
        }
    }
}

# not executed here: Unity Editor 6.6 and Entities 1.4.8 are unavailable.

这段循环是否需要改成Job，不能从语法判断。实体数量少时，调度开销可能抵消收益；主线程已经超预算、工作量足够大且访问模式允许并行时，才值得调度并测量。

调度并保留依赖

速度积分可以写成IJobEntity。系统把已有依赖传入ScheduleParallel，并保存新句柄，使下一项有冲突的工作能等待它。

// # not executed here: Unity Editor 6.6 and Entities 1.4.8 are unavailable.
using Unity.Burst;
using Unity.Entities;
using Unity.Mathematics;
using Unity.Transforms;

public struct Velocity : IComponentData
{
    public float3 MetersPerSecond;
}

[BurstCompile]
public partial struct IntegrateVelocityJob : IJobEntity
{
    public float DeltaTime;

    private void Execute(ref LocalTransform transform, in Velocity velocity)
    {
        transform.Position += velocity.MetersPerSecond * DeltaTime;
    }
}

[BurstCompile]
public partial struct VelocitySystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        state.Dependency = new IntegrateVelocityJob
        {
            DeltaTime = SystemAPI.Time.DeltaTime
        }.ScheduleParallel(state.Dependency);
    }
}

# not executed here: Unity Editor 6.6 and Entities 1.4.8 are unavailable.

这里没有调用Complete()。只要后续访问也通过ECS依赖系统声明，调度器会在真正需要时建立等待关系。若主线程代码立即读取这些变换，读取边界才需要完成对应依赖。

从并行Job记录结构变更

死亡标记会改变组件组合，因此Job不直接调用EntityManager。它用ECB的并行写入器记录命令，并把chunk查询索引作为排序键；EndSimulationEntityCommandBufferSystem随后回放这些命令。

// # not executed here: Unity Editor 6.6 and Entities 1.4.8 are unavailable.
using Unity.Burst;
using Unity.Entities;

public struct Health : IComponentData
{
    public float Value;
}

public struct Dead : IComponentData
{
}

[BurstCompile]
[WithNone(typeof(Dead))]
public partial struct MarkDeadJob : IJobEntity
{
    public EntityCommandBuffer.ParallelWriter Commands;

    private void Execute(
        [ChunkIndexInQuery] int chunkIndex,
        Entity entity,
        in Health health)
    {
        if (health.Value <= 0f)
            Commands.AddComponent<Dead>(chunkIndex, entity);
    }
}

[BurstCompile]
public partial struct DeathSystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        var commands = SystemAPI
            .GetSingleton<EndSimulationEntityCommandBufferSystem.Singleton>()
            .CreateCommandBuffer(state.WorldUnmanaged)
            .AsParallelWriter();

        state.Dependency = new MarkDeadJob { Commands = commands }
            .ScheduleParallel(state.Dependency);
    }
}

# not executed here: Unity Editor 6.6 and Entities 1.4.8 are unavailable.

回放合并并行命令流时，排序键才决定命令顺序。它不是实体ID，也不保证跨帧稳定。业务逻辑若依赖确定顺序，应使用明确且稳定的数据键，而不是把ChunkIndexInQuery当成身份。

修复方法： 先用Unity Profiler找到具体的CPU、同步或分配热点。保留同一工作负载与目标设备，对比修改前后的Player构建；没有数据时只描述访问模式，不写倍数或帧率。

修复方法： Job或遍历期间用ECB延迟结构变更。高频开关状态评估IEnableableComponent，低频持久状态再保留普通添加与移除，并在Profiler中检查结构变更成本。

修复方法： 把前序依赖传给调度调用，再把结果写回state.Dependency。只有立即消费结果时才Complete()，不要用每帧同步来掩盖缺失的依赖声明。

修复方法： 把Burst边界放在非托管数据变换周围，使用合适的原生容器。把日志、对象查找和其他托管工作留在边界外，并在目标构建中确认Burst实际启用。

修复方法： 写清楚生产命令的系统、回放系统和首次消费结果的系统。ECB创建的临时实体只能在同一个缓冲区的后续命令中安全引用，回放后再通过运行时数据取得真实状态。

修复方法： 要求代码明确目标为Entities 1.4.8，并逐个在该版本API或官方样例中核对符号。迁移旧代码时按升级指南处理，不要只替换类型名后期待行为不变。

• Unity官方示例：项目设置
• Unity官方示例：实体与组件
• Unity官方示例：系统
• Unity官方示例：实体与作业
• Unity官方示例：实体命令缓冲区
• Unity官方示例：烘焙