企业官网建设流程全解析

Unity ECS 实战指南：基于 agents24 仓库 unity-ecs-patterns 技能的 DOTS、Jobs 与 Burst 高性能游戏开发模式

【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents

本篇技术指南以 agents24 仓库中 plugins/game-development/skills/unity-ecs-patterns/SKILL.md 及其 references/details.md 为主体，系统讲解 Unity 面向数据技术栈（DOTS）中 ECS、Job System 与 Burst Compiler 的生产级实践模式。读完本文，你将掌握从 ECS 组件设计、ISystem 系统编写、实体查询、命令缓冲、Aspect 分组、单例组件、GameObject 烘焙到 Native 集合并行 Job 的完整落地方案，可直接用于大规模实体数量场景的 CPU 性能优化与 OOP 代码到 ECS 的迁移。

技能背景：插件市场中的渐进式披露设计

unity-ecs-patterns是 agents24 仓库「多工具链 Agent 插件市场」中 game-development 插件 下的一枚技能包，与 unity-developer.md（Unity 开发者 Agent）和godot-gdscript-patterns技能同属游戏开发领域。该仓库面向 Claude Code、Codex、Cursor、OpenCode、GitHub Copilot 与 Google Antigravity 等多种工具链分发 Agent 技能，在 docs/agent-skills.md 的 Game Development 分类中登记为「为高性能游戏系统实现 Unity ECS」。

该技能采用了文档体系中推荐的**渐进式披露（progressive disclosure）**结构，见 docs/authoring.md：SKILL.md作为导航层与快速上手入口，控制体积（Codex 会硬截断超过 8 KB 的技能正文），而完整的模式与可运行示例下沉到references/details.md，由 Agent 按需加载。因此本指南在讲解时，导航层的核心概念（ECS vs OOP、DOTS 组件）与深度层的 8 个实战模式会一并展开，保证信息密度不低于原文。

何时使用本技能

• 构建需要高帧率与大批量实体管理的高性能 Unity 游戏；
• 管理成千上万个实体（敌人、子弹、粒子等）并保持线性扩展；
• 采用数据导向架构设计游戏系统，摆脱面向对象的内存碎片；
• 优化 CPU 密集型的游戏逻辑（碰撞、空间哈希、寻路、战斗结算）；
• 将传统 OOP 游戏代码迁移到 ECS 架构；
• 使用 Job System 与 Burst Compiler 实现多核并行化。

核心概念一：ECS 与 OOP 的本质差异

SKILL.md用一张对比表直接点明两种范式的关键差异，这也是理解整个技能体系的出发点：

传统 OOP 将数据与行为封装在对象中，对象在堆上散布，缓存不友好，实体数量增长后性能急剧下降；ECS 将数据按组件类型连续排列在 Chunk 内存块中，系统以批处理方式遍历同构数据，配合多线程与 Burst 编译可达到随实体数量线性扩展的性能。因此 ECS 的最优适用场景是「大规模模拟」，而复杂对象行为交互仍可保留 OOP 的组织方式。

核心概念二：DOTS 五大构件

SKILL.md用一段简洁的代码块概括了 DOTS 的核心抽象，逐条拆解如下：

Entity: Lightweight ID (no data) // 实体：仅是一个轻量 ID，本身不携带数据 Component: Pure data (no behavior) // 组件：纯数据，不含行为 System: Logic that processes components // 系统：处理组件的逻辑 World: Container for entities // 世界：实体的容器 Archetype: Unique combination of components // 原型：组件的唯一组合 Chunk: Memory block for same-archetype entities // Chunk：同原型实体的连续内存块

• Entity只是指向原型与 Chunk 内部索引的轻量标识，创建和销毁的成本极低；
• Component是结构体（struct）形式的纯数据，这是 Burst 能否优化的关键前提；
• System负责以查询（Query）方式批量处理组件数据，不直接持有实体引用；
• World在 DOTS 1.0 中通常是默认的单例世界，通过state.WorldUnmanaged访问；
• Archetype决定实体在哪个 Chunk 中存储，相同组件组合的实体共享同一 Archetype；
• Chunk是固定容量的内存块，同 Archetype 的实体数据在其中连续排列，实现缓存友好的顺序遍历。这也是后续「chunk 利用率」最佳实践的底层依据。

实战模式一：基础 ECS 设置（组件族谱）

来自 references/details.md 的 Pattern 1 展示了 ECS 中全部四种核心组件类型的定义方式，这是所有后续模式的地基：

using Unity.Entities; using Unity.Mathematics; using Unity.Transforms; using Unity.Burst; using Unity.Collections; // Component: Pure data, no methods public struct Speed : IComponentData { public float Value; } public struct Health : IComponentData { public float Current; public float Max; } public struct Target : IComponentData { public Entity Value; } // Tag component (zero-size marker) public struct EnemyTag : IComponentData { } public struct PlayerTag : IComponentData { } // Buffer component (variable-size array) [InternalBufferCapacity(8)] public struct InventoryItem : IBufferElementData { public int ItemId; public int Quantity; } // Shared component (grouped entities) public struct TeamId : ISharedComponentData { public int Value; }

要点解读：

• IComponentData是 ECS 的基本组件，必须是struct（值类型），Value字段直接以原始值存储，Burst 可完全内联优化；
• Tag 组件（EnemyTag、PlayerTag）是零大小的标记组件，专用于查询筛选（如WithAll<EnemyTag>()），不占用额外内存；
• Buffer 组件（IBufferElementData）表示变长数组，[InternalBufferCapacity(8)]指定内联缓冲区容量——前 8 个元素直接存储在 Chunk 内，超出部分才走外部堆分配，可显著减少小数组的内存分配开销；
• Shared 组件（ISharedComponentData）使拥有相同值的实体在 Chunk 中彼此相邻存放，适合按队伍（TeamId）、LOD 层级、动画状态等分组批量处理的场景。注意 Shared 组件的值是引用类型语义，Equals/GetHashCode实现会影响分组粒度。

实战模式二：用 ISystem 编写系统（官方推荐）

Pattern 2 给出了两种系统写法。第一种是ISystem+SystemAPI.Query的 foreach 简化写法，编译器自动为循环生成 Job；第二种是显式声明IJobEntityJob 以获得更细粒度的控制：

using Unity.Entities; using Unity.Transforms; using Unity.Mathematics; using Unity.Burst; // ISystem: Unmanaged, Burst-compatible, highest performance [BurstCompile] public partial struct MovementSystem : ISystem { [BurstCompile] public void OnCreate(ref SystemState state) { // Require components before system runs state.RequireForUpdate<Speed>(); } [BurstCompile] public void OnUpdate(ref SystemState state) { float deltaTime = SystemAPI.Time.DeltaTime; // Simple foreach - auto-generates job foreach (var (transform, speed) in SystemAPI.Query<RefRW<LocalTransform>, RefRO<Speed>>()) { transform.ValueRW.Position += new float3(0, 0, speed.ValueRO.Value * deltaTime); } } [BurstCompile] public void OnDestroy(ref SystemState state) { } } // With explicit job for more control [BurstCompile] public partial struct MovementJobSystem : ISystem { [BurstCompile] public void OnUpdate(ref SystemState state) { var job = new MoveJob { DeltaTime = SystemAPI.Time.DeltaTime }; state.Dependency = job.ScheduleParallel(state.Dependency); } } [BurstCompile] public partial struct MoveJob : IJobEntity { public float DeltaTime; void Execute(ref LocalTransform transform, in Speed speed) { transform.Position += new float3(0, 0, speed.Value * DeltaTime); } }

关键设计决策：

• ISystem 优于 SystemBase：ISystem是struct类型的非托管系统，生命周期由 World 管理，天然支持 Burst 编译，且无托管对象开销，性能显著高于基于类的SystemBase；
• RefRW<T>/RefRO<T>语义：明确标注「读写」与「只读」，让 Job Scheduler 能安全地进行读写依赖分析与并行调度——只读组件之间可以完全并行；
• state.RequireForUpdate<Speed>()：在没有匹配实体时跳过整个系统更新，避免空循环开销；
• ScheduleParallel与state.Dependency：Job 链通过JobHandle传递依赖，保证跨系统的数据安全，同时最大化多核利用率。

实战模式三：实体查询（Entity Query）

Pattern 3 展示了查询的两种用法——声明式的EntityQueryBuilder与简洁的SystemAPI.Query：

[BurstCompile] public partial struct QueryExamplesSystem : ISystem { private EntityQuery _enemyQuery; public void OnCreate(ref SystemState state) { // Build query manually for complex cases _enemyQuery = new EntityQueryBuilder(Allocator.Temp) .WithAll<EnemyTag, Health, LocalTransform>() .WithNone<Dead>() .WithOptions(EntityQueryOptions.FilterWriteGroup) .Build(ref state); } [BurstCompile] public void OnUpdate(ref SystemState state) { // SystemAPI.Query - simplest approach foreach (var (health, entity) in SystemAPI.Query<RefRW<Health>>() .WithAll<EnemyTag>() .WithEntityAccess()) { if (health.ValueRO.Current <= 0) { // Mark for destruction SystemAPI.GetSingleton<EndSimulationEntityCommandBufferSystem.Singleton>() .CreateCommandBuffer(state.WorldUnmanaged) .DestroyEntity(entity); } } // Get count int enemyCount = _enemyQuery.CalculateEntityCount(); // Get all entities var enemies = _enemyQuery.ToEntityArray(Allocator.Temp); // Get component arrays var healths = _enemyQuery.ToComponentDataArray<Health>(Allocator.Temp); } }

要点：

• WithAll/WithNone：分别表示「必须包含」与「必须不包含」的组件集合，组合使用可以精确圈定查询范围；
• EntityQueryOptions.FilterWriteGroup：启用 WriteGroup 过滤，用于解决多个系统写同一组件时的语义冲突（如位置被移动系统与物理系统共同修改时，显式声明所有权）；
• WithEntityAccess()：在迭代时同时拿到Entity句柄，便于将实体交给 ECB 延迟销毁；
• 临时数组的 Allocator：Allocator.Temp是栈上/每帧临时分配，帧末自动回收，适合每帧查询；跨帧持久的数组应改用Allocator.Persistent并手动Dispose。

实战模式四：Entity Command Buffers（结构变更）

Pattern 4 是全套模式中最重要的并发安全知识点。创建/销毁实体、增删组件属于结构性变更（structural change），会触发同步点（sync point），绝不允许在 Job 内直接执行——必须通过实体命令缓冲（ECB）延迟到帧末统一应用：

// Structural changes (create/destroy/add/remove) require command buffers [BurstCompile] [UpdateInGroup(typeof(SimulationSystemGroup))] public partial struct SpawnSystem : ISystem { [BurstCompile] public void OnUpdate(ref SystemState state) { var ecbSingleton = SystemAPI.GetSingleton<BeginSimulationEntityCommandBufferSystem.Singleton>(); var ecb = ecbSingleton.CreateCommandBuffer(state.WorldUnmanaged); foreach (var (spawner, transform) in SystemAPI.Query<RefRW<Spawner>, RefRO<LocalTransform>>()) { spawner.ValueRW.Timer -= SystemAPI.Time.DeltaTime; if (spawner.ValueRO.Timer <= 0) { spawner.ValueRW.Timer = spawner.ValueRO.Interval; // Create entity (deferred until sync point) Entity newEntity = ecb.Instantiate(spawner.ValueRO.Prefab); // Set component values ecb.SetComponent(newEntity, new LocalTransform { Position = transform.ValueRO.Position, Rotation = quaternion.identity, Scale = 1f }); // Add component ecb.AddComponent(newEntity, new Speed { Value = 5f }); } } } } // Parallel ECB usage [BurstCompile] public partial struct ParallelSpawnJob : IJobEntity { public EntityCommandBuffer.ParallelWriter ECB; void Execute([EntityIndexInQuery] int index, in Spawner spawner) { Entity e = ECB.Instantiate(index, spawner.Prefab); ECB.AddComponent(index, e, new Speed { Value = 5f }); } }

要点：

• ECB 的获取方式：通过SystemAPI.GetSingleton<BeginSimulationEntityCommandBufferSystem.Singleton>()（帧开始）或EndSimulationEntityCommandBufferSystem.Singleton（帧结束，Pattern 3 的销毁逻辑即使用它），在系统更新循环外获取，循环内复用同一个 ECB；
• EntityCommandBuffer.ParallelWriter：并行 Job 中必须使用ParallelWriter并把 Job 内的实体索引index作为第一个参数传入所有 ECB 方法，保证多线程写入 ECB 内部缓冲的顺序安全；
• 延迟语义：Instantiate/AddComponent/DestroyEntity只是记录命令，真正执行发生在同步点，因此循环内反复生成实体不会破坏当前查询的 Chunk 迭代。

实战模式五：Aspect（组件分组与领域接口）

Pattern 5 用IAspect把相关联的组件封装为面向领域语义的只读视图，是「Clean component grouping」最佳实践的落地形态：

using Unity.Entities; using Unity.Transforms; using Unity.Mathematics; // Aspect: Groups related components for cleaner code public readonly partial struct CharacterAspect : IAspect { public readonly Entity Entity; private readonly RefRW<LocalTransform> _transform; private readonly RefRO<Speed> _speed; private readonly RefRW<Health> _health; // Optional component [Optional] private readonly RefRO<Shield> _shield; // Buffer private readonly DynamicBuffer<InventoryItem> _inventory; public float3 Position { get => _transform.ValueRO.Position; set => _transform.ValueRW.Position = value; } public float CurrentHealth => _health.ValueRO.Current; public float MaxHealth => _health.ValueRO.Max; public float MoveSpeed => _speed.ValueRO.Value; public bool HasShield => _shield.IsValid; public float ShieldAmount => HasShield ? _shield.ValueRO.Amount : 0f; public void TakeDamage(float amount) { float remaining = amount; if (HasShield && _shield.ValueRO.Amount > 0) { // Shield absorbs damage first remaining = math.max(0, amount - _shield.ValueRO.Amount); } _health.ValueRW.Current = math.max(0, _health.ValueRO.Current - remaining); } public void Move(float3 direction, float deltaTime) { _transform.ValueRW.Position += direction * _speed.ValueRO.Value * deltaTime; } public void AddItem(int itemId, int quantity) { _inventory.Add(new InventoryItem { ItemId = itemId, Quantity = quantity }); } } // Using aspect in system [BurstCompile] public partial struct CharacterSystem : ISystem { [BurstCompile] public void OnUpdate(ref SystemState state) { float dt = SystemAPI.Time.DeltaTime; foreach (var character in SystemAPI.Query<CharacterAspect>()) { character.Move(new float3(1, 0, 0), dt); if (character.CurrentHealth < character.MaxHealth * 0.5f) { // Low health logic } } } }

设计价值：

• readonly partial struct：Aspect 必须是只读结构体，其字段为RefRW/RefRO/DynamicBuffer包装，编译器据此生成查询与访问代码；
• [Optional]组件：用特性标记的组件在实体缺失时IsValid为 false，调用方可用HasShield安全降级，避免为「可有可无」的数据强行拆分系统；
• 领域方法收敛：TakeDamage、Move、AddItem把组件读写封装成语义操作，系统内迭代代码变得极简（如character.Move(...)），同时仍完全保留 Burst 内联优化能力——Aspect 是纯编译期抽象，零运行时开销。

实战模式六：Singleton 组件（全局配置与状态）

Pattern 6 解决「全局唯一的游戏配置/状态」问题。任何IComponentData都可以通过确保全 World 只有一个实体携带它来充当单例：

// Singleton: Exactly one entity with this component public struct GameConfig : IComponentData { public float DifficultyMultiplier; public int MaxEnemies; public float SpawnRate; } public struct GameState : IComponentData { public int Score; public int Wave; public float TimeRemaining; } // Create singleton on world creation public partial struct GameInitSystem : ISystem { public void OnCreate(ref SystemState state) { var entity = state.EntityManager.CreateEntity(); state.EntityManager.AddComponentData(entity, new GameConfig { DifficultyMultiplier = 1.0f, MaxEnemies = 100, SpawnRate = 2.0f }); state.EntityManager.AddComponentData(entity, new GameState { Score = 0, Wave = 1, TimeRemaining = 120f }); } } // Access singleton in system [BurstCompile] public partial struct ScoreSystem : ISystem { [BurstCompile] public void OnUpdate(ref SystemState state) { // Read singleton var config = SystemAPI.GetSingleton<GameConfig>(); // Write singleton ref var gameState = ref SystemAPI.GetSingletonRW<GameState>().ValueRW; gameState.TimeRemaining -= SystemAPI.Time.DeltaTime; // Check exists if (SystemAPI.HasSingleton<GameConfig>()) { // ... } } }

要点：

• GetSingleton<T>()读取、GetSingletonRW<T>()写：写访问返回ref引用，注意GetSingletonRW会引入与其他系统的写冲突依赖，频繁写入的单例应尽量拆分到独立系统处理；
• HasSingleton<T>()用于在单例可能尚未创建（例如系统更新顺序早于初始化系统）时做防御性判断；
• 初始化时机：GameInitSystem.OnCreate在世界创建阶段调用EntityManager直接创建实体并添加组件，后续所有系统即可安全GetSingleton。

实战模式七：Baking（GameObject 到 ECS 的转换）

Pattern 7 覆盖了 DOTS 1.0 的子场景（SubScene）工作流：美术/策划在场景中用 MonoBehaviour 配置数据，编译期由 Baker 转换为 ECS 组件。EnemyAuthoring是编辑器侧的 Authoring 组件，内嵌Baker<EnemyAuthoring>定义转换逻辑：

using Unity.Entities; using UnityEngine; // Authoring component (MonoBehaviour in Editor) public class EnemyAuthoring : MonoBehaviour { public float Speed = 5f; public float Health = 100f; public GameObject ProjectilePrefab; class Baker : Baker<EnemyAuthoring> { public override void Bake(EnemyAuthoring authoring) { var entity = GetEntity(TransformUsageFlags.Dynamic); AddComponent(entity, new Speed { Value = authoring.Speed }); AddComponent(entity, new Health { Current = authoring.Health, Max = authoring.Health }); AddComponent(entity, new EnemyTag()); if (authoring.ProjectilePrefab != null) { AddComponent(entity, new ProjectilePrefab { Value = GetEntity(authoring.ProjectilePrefab, TransformUsageFlags.Dynamic) }); } } } } // Complex baking with dependencies public class SpawnerAuthoring : MonoBehaviour { public GameObject[] Prefabs; public float Interval = 1f; class Baker : Baker<SpawnerAuthoring> { public override void Bake(SpawnerAuthoring authoring) { var entity = GetEntity(TransformUsageFlags.Dynamic); AddComponent(entity, new Spawner { Interval = authoring.Interval, Timer = 0f }); // Bake buffer of prefabs var buffer = AddBuffer<SpawnPrefabElement>(entity); foreach (var prefab in authoring.Prefabs) { buffer.Add(new SpawnPrefabElement { Prefab = GetEntity(prefab, TransformUsageFlags.Dynamic) }); } // Declare dependencies DependsOn(authoring.Prefabs); } } }

要点：

• TransformUsageFlags.Dynamic：声明实体的 Transform 是动态变换的，Baker 据此决定是否附加LocalTransform等内置组件；
• GetEntity(引用)：把场景/预制体引用转换为实体引用，多个 Authoring 通过它建立实体间关联；
• AddBuffer<T>(entity)烘焙缓冲组件：把数组字段烘焙为IBufferElementData缓冲，与运行时 Pattern 1 的InventoryItem用法对应；
• DependsOn声明依赖：当 Baker 读取了其他 GameObject 时，必须调用DependsOn，否则变更这些对象不会触发正确重烘焙。

实战模式八：Jobs 与 Native 集合（空间哈希实战）

Pattern 8 是一个完整的「空间哈希」多线程并行化示例，将前面的知识点串联成一个可落地的性能优化场景——例如用于万级单位的邻近查询或碰撞粗筛：

using Unity.Jobs; using Unity.Collections; using Unity.Burst; using Unity.Mathematics; [BurstCompile] public struct SpatialHashJob : IJobParallelFor { [ReadOnly] public NativeArray<float3> Positions; // Thread-safe write to hash map public NativeParallelMultiHashMap<int, int>.ParallelWriter HashMap; public float CellSize; public void Execute(int index) { float3 pos = Positions[index]; int hash = GetHash(pos); HashMap.Add(hash, index); } int GetHash(float3 pos) { int x = (int)math.floor(pos.x / CellSize); int y = (int)math.floor(pos.y / CellSize); int z = (int)math.floor(pos.z / CellSize); return x * 73856093 ^ y * 19349663 ^ z * 83492791; } } [BurstCompile] public partial struct SpatialHashSystem : ISystem { private NativeParallelMultiHashMap<int, int> _hashMap; public void OnCreate(ref SystemState state) { _hashMap = new NativeParallelMultiHashMap<int, int>(10000, Allocator.Persistent); } public void OnDestroy(ref SystemState state) { _hashMap.Dispose(); } [BurstCompile] public void OnUpdate(ref SystemState state) { var query = SystemAPI.QueryBuilder() .WithAll<LocalTransform>() .Build(); int count = query.CalculateEntityCount(); // Resize if needed if (_hashMap.Capacity < count) { _hashMap.Capacity = count * 2; } _hashMap.Clear(); // Get positions var positions = query.ToComponentDataArray<LocalTransform>(Allocator.TempJob); var posFloat3 = new NativeArray<float3>(count, Allocator.TempJob); for (int i = 0; i < count; i++) { posFloat3[i] = positions[i].Position; } // Build hash map var hashJob = new SpatialHashJob { Positions = posFloat3, HashMap = _hashMap.AsParallelWriter(), CellSize = 10f }; state.Dependency = hashJob.Schedule(count, 64, state.Dependency); // Cleanup positions.Dispose(state.Dependency); posFloat3.Dispose(state.Dependency); } }

工程要点：

• NativeParallelMultiHashMap<int,int>：一对多的并行安全哈希表，ParallelWriter让多个工作线程并发写入同一哈希桶；
• [ReadOnly]标记：声明Positions只读，使 Job Scheduler 允许该 Job 与其他只读 Job 并行执行；
• [EntityIndexInQuery]/IJobParallelFor索引：Execute(int index)由调度器以批次（batch，Schedule(count, 64, ...)中 64 为每批元素数）分发到线程；
• 生命周期纪律：Allocator.Persistent的字段在OnCreate分配、OnDestroy释放；每帧的临时数组在Schedule后通过Dispose(state.Dependency)挂到 Job 依赖链上，确保 Job 完成后才回收——这正是SKILL.md「Don't forget disposal」规则的直接体现；
• 容量动态调整：实体数量超过当前容量时先扩容（count * 2）再Clear()复用，避免每帧重新分配。

性能优化要点与最佳实践

details.md末尾的性能建议与SKILL.md的 Do's/Don'ts 互为表里，归纳为以下可执行清单：

// 1. Use Burst everywhere [BurstCompile] public partial struct MySystem : ISystem { } // 2. Prefer IJobEntity over manual iteration [BurstCompile] partial struct OptimizedJob : IJobEntity { void Execute(ref LocalTransform transform) { } } // 3. Schedule parallel when possible state.Dependency = job.ScheduleParallel(state.Dependency); // 4. Use ScheduleParallel with chunk iteration [BurstCompile] partial struct ChunkJob : IJobChunk { public ComponentTypeHandle<Health> HealthHandle; public void Execute(in ArchetypeChunk chunk, int unfilteredChunkIndex, bool useEnabledMask, in v128 chunkEnabledMask) { var healths = chunk.GetNativeArray(ref HealthHandle); for (int i = 0; i < chunk.Count; i++) { // Process } } } // 5. Avoid structural changes in hot paths // Use enableable components instead of add/remove public struct Disabled : IComponentData, IEnableableComponent { }

Do's（应当遵循）

• ISystem 优先于 SystemBase：前者是非托管结构体系统，天然支持 Burst，性能更好；
• 全量 Burst 编译：为系统与 Job 标注[BurstCompile]，可获得数量级的指令优化（SIMD、去托管检查）；
• 批量结构变更：创建/销毁实体一律走 ECB，减少同步点次数；
• 用 Profiler 定位瓶颈：结合 Unity Profiler 与 Burst Inspector 确认热点确实在 ECS 代码中；
• 用 Aspect 做组件分组：让系统代码保持领域语义清晰，同时零运行时开销。

Don'ts（必须避免）

• 不使用托管类型（class、string、List<T>等）：托管引用会破坏 Burst 编译，迫使数据落入托管堆，拖垮缓存性能；
• 不在 Job 内做结构变更：同步点会序列化整个 Job 链，抵消并行收益，必须改用 ECB；
• 不过度架构：先以简单 foreach 起步，确认瓶颈后再引入手动 Job 与 Chunk 级优化；
• 不忽略 Chunk 利用率：Chunk 容量固定（约 128 个实体），应避免大量「半空 Chunk」——把共享同质组件（如 Shared 组件、Enableable 标记）的实体聚合，减少碎片与遍历损耗；
• 不忘记释放 Native 集合：NativeArray、NativeParallelMultiHashMap等若在OnDestroy或 Job 依赖链上漏掉Dispose，会造成无法回收的原生内存泄漏。

热点路径的结构变更替代方案

当需要在运行时大量「禁用/启用」实体时，与其反复AddComponent/RemoveComponent（每次都是结构变更），不如使用可启用组件（IEnableableComponent）：实体保留组件但被查询默认排除，切换成本远低于结构变更，且不会打断 Chunk 遍历。上述代码中的Disabled : IComponentData, IEnableableComponent正是这一模式的标注示例。

如何在多工具链环境中使用该技能

在 agents24 仓库中，技能可通过多种方式引入你的开发环境：

• 直接阅读：导航层见 SKILL.md，完整模式与可运行代码见 references/details.md；
• 配合 Agent 使用：由 unity-developer.md 定义的 Unity 开发者 Agent 会主动运用本技能，覆盖 Unity 6 LTS、URP/HDRP 渲染管线、Job System/Burst、跨平台优化等场景；
• 安装与分发：该技能遵循 Agent Skills 规范（frontmatter 含name与description的 "Use when" 激活条件），可经gh skill install/npx skills add按路径安装，并会由仓库的适配器转换为 Codex、OpenCode、Copilot、Antigravity 等工具链所需的技能格式（细节见 docs/harnesses.md 与 docs/authoring.md）。

结语

从组件类型选择、ISystem 编写、查询过滤、ECB 并发安全，到 Aspect 抽象、单例管理、GameObject 烘焙与 Native 集合并行 Job，unity-ecs-patterns提供了一条从 OOP 思维过渡到数据导向架构的完整路径。落地时始终牢记三条主线：数据要连续（Archetype/Chunk）、逻辑要并行（Job/Burst）、变更要延迟（ECB）。将导航层的设计原则与 references 层的 8 个模式配合使用，即可在数千实体规模下获得线性扩展的高性能游戏逻辑，同时保持代码的可读性与可维护性。

【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents