1. 项目概述为什么我们需要共享组件在Unity ECS的世界里我们一直在和ComponentData打交道它让每个实体都拥有自己独立的数据副本比如位置、速度、生命值。这种设计在绝大多数情况下都非常高效因为它完美契合了面向数据的设计思想让CPU可以高速地、连续地处理大批量数据。但实际开发中我们总会遇到一些“特殊”情况比如场景里有成百上千个士兵他们都穿着同一种款式的盔甲或者一片森林里所有橡树都共享着完全相同的树叶模型和材质。如果给每个士兵实体都复制一份完全相同的盔甲数据或者给每棵橡树实体都复制一份完全相同的树叶网格和材质引用这无疑是一种巨大的内存浪费也与我们追求极致性能的初衷背道而驰。这时ISharedComponentData共享组件就该登场了。你可以把它理解为一个“标签”或“引用”它本身不存储大量重复的实例数据而是存储一个指向公共数据的“钥匙”。所有使用同一把“钥匙”的实体在内存中实际上共享着同一份底层数据。这就像在现实世界的工厂里生产同一型号的手机所有手机共享同一份设计图纸而不是每台手机都复印一份图纸放在自己盒子里。共享组件的核心价值就是在不破坏ECS数据局部性的前提下优雅地解决数据冗余问题尤其适用于那些大量实体共享相同、且不常变化的配置数据或资源引用。2. 核心概念与设计思路拆解2.1 ISharedComponentData 与 IComponentData 的本质区别理解共享组件首先要把它和普通的IComponentData组件彻底区分开。这不仅仅是两个不同的接口更代表了两种截然不同的数据存储和访问模式。IComponentData普通组件存储方式数据是“值类型”通常是struct直接存储在实体的Archetype原型内存块中。每个实体都拥有自己独立的一份数据副本。内存布局属于同一Archetype的所有实体的同类型组件数据在内存中是连续排列的。这是ECS高性能查询和批量处理的基石。变化频率适合频繁变化的数据如每帧更新的Translation位置、Rotation旋转、Velocity速度。类比就像每个人的身份证号每个人都是独一无二的且信息直接印在个人档案里。ISharedComponentData共享组件存储方式数据也是struct但它内部存储的通常是一个索引SharedComponentIndex或一个引用如BlobAssetReference指向一份存储在别处的共享数据。实体本身不存储实际数据只存储这个“钥匙”。内存布局共享组件是ECS中划分Archetype原型的关键因素。拥有不同共享组件值的实体会被分配到不同的Archetype中。例如所有“红色材质”的实体在一个Archetype所有“蓝色材质”的实体在另一个Archetype。变化频率适合极少变化或只读的配置数据、资源引用。比如RenderMesh渲染网格、Material材质引用。改变一个实体的共享组件值意味着它需要从一个Archetype迁移到另一个这是一个相对昂贵的操作。类比就像图书馆的借书卡。卡本身只记录了一个图书编号共享索引成百上千的人可以借阅同一本书共享数据。书存放在图书馆的特定书架共享数据存储区而不是每个人家里都有一本。注意这个“划分Archetype”的特性是一把双刃剑。它让拥有相同共享数据的实体在内存中自然聚集查询效率高但如果你有大量不同的共享值例如为每个实体分配一个唯一的材质就会创建出海量的Archetype导致内存碎片化和查询性能下降。因此共享组件必须谨慎用于“真正被大量实体共享”的数据。2.2 共享组件的典型应用场景理解了区别我们就能更准确地使用它。以下是几个最适合使用ISharedComponentData的场景渲染批处理Rendering Batching这是最经典的应用。通过一个共享组件如MaterialMeshInfo来引用材质和网格。所有使用相同材质和网格的实体会被系统自动批量渲染极大减少Draw Call。这是Unity ECS实现高性能渲染的核心机制之一。配置数据共享游戏中有多种敌人类型如“步兵”、“弓箭手”、“骑兵”。每种类型有固定的基础生命值、攻击力、移动速度。你可以定义一个EnemyConfigSharedData共享组件包含这些基础属性。所有“步兵”实体共享同一个配置实例。标签或分类虽然不是最佳实践更推荐使用ISystemStateComponentData或EnableableComponent做标签但有时也可以用共享组件来对实体进行粗略分类例如TeamSharedData队伍、FactionSharedData阵营。前提是分类数量有限且稳定。引用大型只读数据例如一个复杂的技能配置表SkillConfigBlob包含技能名称、伤害公式、效果列表等。使用BlobAssetReference配合共享组件可以让所有释放同一技能的实体安全、高效地读取这份配置。3. 核心细节解析与实操要点3.1 定义共享组件结构体定义一个共享组件和定义普通组件非常相似但有一些关键约束。using Unity.Entities; // 示例1一个简单的共享配置 public struct UnitConfigSharedData : ISharedComponentData { public float BaseHealth; public float BaseDamage; public float MoveSpeed; // 注意共享组件内可以包含引用类型但必须是可序列化的且需谨慎处理。 // public string UnitName; // 字符串是引用类型可以用但要注意内存和序列化。 } // 示例2用于渲染的共享组件通常与Hybrid Renderer或Entities Graphics配合 public struct RenderMeshSharedData : ISharedComponentData, IEquatableRenderMeshSharedData { public Mesh Mesh; public Material Material; // 通常还需要实现 IEquatable 接口以便ECS内部正确比较和哈希 public bool Equals(RenderMeshSharedData other) { return Mesh other.Mesh Material other.Material; } public override int GetHashCode() { unchecked { int hash 17; hash hash * 23 (Mesh ! null ? Mesh.GetHashCode() : 0); hash hash * 23 (Material ! null ? Material.GetHashCode() : 0); return hash; } } }关键约束与要点必须是struct和IComponentData一样。实现ISharedComponentData接口这是标识。重写Equals和GetHashCode强烈建议因为ECS需要根据共享组件的值来区分不同的Archetype。如果两个共享组件实例被认为是“相等的”它们对应的实体就属于同一个Archetype。默认的Equals比较的是引用对于包含UnityEngine.Object如Mesh, Material引用的共享组件这通常没问题。但如果你自定义的结构体包含多个值类型字段你必须重写这两个方法确保逻辑相等性判断正确。上面的RenderMeshSharedData是一个标准示例。避免包含频繁变化的数据共享组件值的变化会导致实体Archetype迁移成本高。谨慎使用引用类型字段如string、数组、List。它们虽然可以编译通过但会带来序列化、内存管理和线程安全方面的复杂性。对于配置数据更推荐使用BlobAsset。3.2 实体创建与共享组件管理为实体添加、设置、移除共享组件需要使用EntityManager提供的特定API。using Unity.Entities; using UnityEngine; public class SharedComponentDemo : MonoBehaviour { public Mesh sharedMesh; public Material sharedMaterial; public float sharedHealth 100f; private World _world; private EntityManager _entityManager; private EntityArchetype _archetype; void Start() { _world World.DefaultGameObjectInjectionWorld; _entityManager _world.EntityManager; // 1. 创建一个包含共享组件的原型Archetype // 原型定义了一个实体“可以有”哪些组件类型但共享组件的具体值是在实体层面设置的。 _archetype _entityManager.CreateArchetype( typeof(Translation), typeof(Rotation), typeof(RenderMeshSharedData), // 共享组件类型 typeof(UnitConfigSharedData) // 另一个共享组件类型 ); // 2. 创建多个实体并为它们设置共享的组件值 RenderMeshSharedData renderData new RenderMeshSharedData { Mesh sharedMesh, Material sharedMaterial }; UnitConfigSharedData configData new UnitConfigSharedData { BaseHealth sharedHealth, BaseDamage 20f, MoveSpeed 5f }; for (int i 0; i 100; i) { Entity entity _entityManager.CreateEntity(_archetype); // 使用 SetSharedComponentData 设置共享组件值 _entityManager.SetSharedComponentData(entity, renderData); _entityManager.SetSharedComponentData(entity, configData); // 设置普通组件值 _entityManager.SetComponentData(entity, new Translation { Value new float3(i * 2, 0, 0) }); } Debug.Log($创建了100个共享相同网格、材质和配置的实体。); } }核心API解析EntityManager.SetSharedComponentDataT(Entity entity, T sharedData)这是为实体设置共享组件值的主要方法。如果实体之前没有该类型的共享组件此方法会添加它如果已有则更新其值。更新值会导致实体Archetype变更。EntityManager.AddSharedComponentDataT(Entity entity, T sharedData)也可以用于添加但更常见的做法是使用SetSharedComponentData因为它同时涵盖了添加和更新的情况。EntityManager.RemoveComponentT(Entity entity)用于移除共享组件。移除共享组件也会改变实体的Archetype。EntityManager.GetSharedComponentDataT(Entity entity)获取实体上特定类型的共享组件数据。EntityManager.GetAllUniqueSharedComponentsT这是一个非常有用的方法可以获取世界中所有被实体使用的、不同的T类型共享组件值的列表。常用于批量处理或调试。3.3 在System中查询与使用共享组件在System中处理带有共享组件的实体查询方式与普通组件类似但有一些特殊之处。using Unity.Entities; using Unity.Transforms; using UnityEngine; // 假设我们有一个根据队伍共享组件来更新颜色的系统 public struct TeamSharedData : ISharedComponentData, IEquatableTeamSharedData { public Color TeamColor; public bool Equals(TeamSharedData other) TeamColor.Equals(other.TeamColor); public override int GetHashCode() TeamColor.GetHashCode(); } // 一个需要渲染的组件假设 public struct CustomRenderer : IComponentData { public Color CurrentColor; } // 系统根据队伍共享组件初始化或更新实体的颜色 [UpdateInGroup(typeof(SimulationSystemGroup))] public partial class TeamColorSystem : SystemBase { protected override void OnUpdate() { // 方式一在查询中直接包含共享组件最常见 // 这个查询会匹配所有拥有 TeamSharedData 和 CustomRenderer 的实体。 // 注意共享组件作为查询过滤器不会出现在 in 参数中供直接读取。 Entities .WithSharedComponentFilterTeamSharedData() // 关键使用共享组件过滤 .ForEach((ref CustomRenderer renderer, in TeamSharedData teamData) { // 在这里teamData 就是该实体对应的共享组件数据。 // 所有拥有相同 TeamSharedData 值的实体在这个Job中都会访问到同一份数据。 renderer.CurrentColor teamData.TeamColor; }).ScheduleParallel(); // 方式二通过 EntityQuery 手动构建更复杂的查询例如查询特定值的共享组件 EntityQuery query GetEntityQuery( ComponentType.ReadOnlyTeamSharedData(), ComponentType.ReadWriteCustomRenderer() ); // 获取查询中所有不同的 TeamSharedData 值 var allTeamData query.GetSharedComponentTypesTeamSharedData(); // 或者如果你知道具体的共享值可以设置过滤器 TeamSharedData redTeamData new TeamSharedData { TeamColor Color.red }; query.SetSharedComponentFilter(redTeamData); // 现在 query 只匹配队伍颜色为红色的实体 // 然后可以基于过滤后的query进行操作 Entities.WithStoreEntityQueryInField(ref query).ForEach(...).ScheduleParallel(); } }关键点WithSharedComponentFilterT()这是在Entities.ForEach中使用共享组件进行过滤的标准方式。它确保了Job只处理具有该共享组件且通常是在后续代码中通过in参数访问其值的实体。重要即使你在ForEach的签名中包含了in TeamSharedData teamData你也必须使用WithSharedComponentFilter否则查询可能无法正确过滤或导致未定义行为。共享组件在Job中的访问在ForEach的Lambda参数中共享组件通常以in只读方式传入因为修改共享组件值是一个结构性变更会改变Archetype不能在并行Job中直接进行。如果你需要修改通常需要在一个单线程的EntityCommandBuffer操作中安排SetSharedComponentData。性能提示由于共享组件划分了Archetype一个包含共享组件过滤的查询其内部实体在内存中是连续存放的这有利于CPU缓存能提升迭代速度。4. 实操过程与核心环节实现构建一个共享配置的敌人生成系统让我们通过一个更完整的例子将理论付诸实践。我们将创建一个系统它根据不同的敌人配置共享组件EnemyConfigShared来批量生成和初始化敌人实体。4.1 步骤一定义共享组件与普通组件// EnemyConfigShared.cs using Unity.Entities; using UnityEngine; public struct EnemyConfigShared : ISharedComponentData, IEquatableEnemyConfigShared { public GameObject Prefab; // 注意这是MonoBehaviour Prefab用于Hybrid方式实例化。纯ECS模式应用Prefab Entity。 public float SpawnHealth; public float DamagePerHit; public float AttackRange; public float MoveSpeed; // 实现相等比较和哈希确保相同配置的实体被分到同一Archetype public bool Equals(EnemyConfigShared other) { return Prefab other.Prefab Mathf.Approximately(SpawnHealth, other.SpawnHealth) Mathf.Approximately(DamagePerHit, other.DamagePerHit) Mathf.Approximately(AttackRange, other.AttackRange) Mathf.Approximately(MoveSpeed, other.MoveSpeed); } public override int GetHashCode() { unchecked { int hash 17; hash hash * 23 (Prefab ! null ? Prefab.GetHashCode() : 0); hash hash * 23 SpawnHealth.GetHashCode(); hash hash * 23 DamagePerHit.GetHashCode(); hash hash * 23 AttackRange.GetHashCode(); hash hash * 23 MoveSpeed.GetHashCode(); return hash; } } } // EnemyData.cs - 每个敌人实例独有的数据 using Unity.Entities; public struct EnemyData : IComponentData { public float CurrentHealth; public float CurrentDamage; // 可能受Buff影响不同于配置的基础值 }4.2 步骤二创建敌人生成器与初始化系统// EnemySpawnerAuthoring.cs - 一个MonoBehaviour用于在Inspector中配置生成参数 using Unity.Entities; using UnityEngine; public class EnemySpawnerAuthoring : MonoBehaviour { public GameObject[] EnemyPrefabs; // 不同类型的敌人Prefab public int SpawnCountPerType 10; public Transform[] SpawnPoints; // 为每个Prefab定义一个配置这里简化了实际可能从ScriptableObject读取 [System.Serializable] public class EnemyConfig { public float Health; public float Damage; public float Range; public float Speed; } public EnemyConfig[] Configs; // 确保长度与EnemyPrefabs一致 class Baker : BakerEnemySpawnerAuthoring { public override void Bake(EnemySpawnerAuthoring authoring) { var entity GetEntity(TransformUsageFlags.None); // 这里我们选择不生成实体而是由另一个System读取这个MonoBehaviour的数据来生成ECS实体。 // 更ECS的方式是创建一个SpawnRequest组件但为了演示共享组件我们简化流程。 // 实际项目可能会把配置数据转换为BlobAsset或直接作为ComponentData。 } } } // EnemySpawnSystem.cs - 负责读取生成器配置并创建实体 using Unity.Entities; using Unity.Collections; using Unity.Mathematics; using UnityEngine; [UpdateInGroup(typeof(InitializationSystemGroup))] public partial struct EnemySpawnSystem : ISystem { public void OnCreate(ref SystemState state) { // 可以在这里添加一些初始化的RequireForUpdate查询 } public void OnDestroy(ref SystemState state) { } public void OnUpdate(ref SystemState state) { // 此系统只运行一次生成敌人后即禁用自身 state.Enabled false; var entityManager state.EntityManager; var enemySpawners Object.FindObjectsOfTypeEnemySpawnerAuthoring(); if (enemySpawners.Length 0) return; var spawner enemySpawners[0]; // 假设只有一个生成器 if (spawner.EnemyPrefabs.Length ! spawner.Configs.Length) { Debug.LogError(EnemyPrefabs and Configs length mismatch!); return; } // 为每种敌人类型创建一个原型Archetype // 原型包含LocalTransform或Translation/RotationEnemyData以及EnemyConfigShared EntityArchetype enemyArchetype entityManager.CreateArchetype( typeof(LocalTransform), typeof(EnemyData), typeof(EnemyConfigShared) ); // 使用随机数生成位置 Unity.Mathematics.Random random new Unity.Mathematics.Random((uint)System.DateTime.Now.Millisecond); for (int typeIndex 0; typeIndex spawner.EnemyPrefabs.Length; typeIndex) { var prefab spawner.EnemyPrefabs[typeIndex]; var config spawner.Configs[typeIndex]; // 创建共享组件数据实例 EnemyConfigShared sharedConfig new EnemyConfigShared { Prefab prefab, SpawnHealth config.Health, DamagePerHit config.Damage, AttackRange config.Range, MoveSpeed config.Speed }; // 生成该类型的所有敌人实体 for (int i 0; i spawner.SpawnCountPerType; i) { Entity enemyEntity entityManager.CreateEntity(enemyArchetype); // 1. 设置共享组件决定了这个实体属于哪个“配置组” entityManager.SetSharedComponentData(enemyEntity, sharedConfig); // 2. 设置实例数据每个敌人独有 entityManager.SetComponentData(enemyEntity, new EnemyData { CurrentHealth sharedConfig.SpawnHealth, CurrentDamage sharedConfig.DamagePerHit }); // 3. 设置位置随机在生成点附近 float3 spawnPos float3.zero; if (spawner.SpawnPoints.Length 0) { Transform point spawner.SpawnPoints[random.NextInt(0, spawner.SpawnPoints.Length)]; spawnPos point.position; // 添加一些随机偏移 spawnPos new float3(random.NextFloat(-5, 5), 0, random.NextFloat(-5, 5)); } entityManager.SetComponentData(enemyEntity, LocalTransform.FromPosition(spawnPos)); } Debug.Log($已生成 {spawner.SpawnCountPerType} 个类型为 {prefab.name} 的敌人。); } Debug.Log($敌人生成完毕总计 {spawner.EnemyPrefabs.Length * spawner.SpawnCountPerType} 个实体。); } }4.3 步骤三创建使用共享组件数据的逻辑系统现在我们创建一个战斗系统它利用共享组件中的配置数据如攻击范围来驱动敌人的行为。// EnemyAttackSystem.cs using Unity.Entities; using Unity.Mathematics; using Unity.Transforms; using UnityEngine; [UpdateInGroup(typeof(SimulationSystemGroup))] [UpdateAfter(typeof(TransformSystemGroup))] // 确保位置已更新 public partial struct EnemyAttackSystem : ISystem { public void OnCreate(ref SystemState state) { // 此系统需要EntityQuery来查找玩家这里简化为查找有PlayerTag的实体 } public void OnUpdate(ref SystemState state) { // 假设玩家实体有一个PlayerTag组件 Entity playerEntity SystemAPI.GetSingletonEntityPlayerTag(); LocalTransform playerTransform SystemAPI.GetComponentLocalTransform(playerEntity); // 关键查询遍历所有敌人并使用共享组件过滤。 // 注意虽然这里我们没有用不同的共享值进行过滤但查询仍然会按共享值分组迭代效率更高。 foreach (var (enemyData, enemyTransform, configShared) in SystemAPI.QueryRefRWEnemyData, LocalTransform, EnemyConfigShared()) { // 计算与玩家的距离 float distance math.distance(enemyTransform.Position, playerTransform.Position); // 从共享组件中读取该类型敌人的攻击范围 float attackRange configShared.AttackRange; if (distance attackRange) { // 在攻击范围内执行攻击逻辑 // 例如减少玩家生命值这里省略玩家生命值组件 // Debug.Log(${configShared.Prefab.name} 在攻击); // 也可以根据共享组件中的伤害值来应用伤害 // float damageToApply configShared.DamagePerHit; // ... } else { // 不在范围内可以移动移动速度也来自共享组件 configShared.MoveSpeed // ... 移动逻辑 ... } } // 更高效的写法是使用SystemAPI.Query().ScheduleParallel()进行并行处理 // 但这里为了演示清晰使用了主线程遍历。 // 注意在并行Job中共享组件数据是只读的这完全符合我们的需求。 } }5. 常见问题与排查技巧实录在实际项目中使用ISharedComponentData你几乎一定会遇到下面这些问题。我把踩过的坑和解决方案整理出来希望能帮你节省大量调试时间。5.1 问题一修改共享组件值后实体“消失”了或行为异常现象你在运行时用SetSharedComponentData修改了一个实体的共享组件值比如把材质从红色换成蓝色然后发现这个实体不再被原来的系统查询所处理或者渲染不见了。根因这是共享组件最核心的特性也是最容易误解的地方。修改共享组件的值会改变实体所属的Archetype。实体会被从旧的Archetype块中移除并添加到新的或新建的Archetype块中。如果你的系统查询EntityQuery没有包含新的共享组件值或者查询是在修改之前缓存的那么自然就查不到这个实体了。排查与解决检查系统查询确保你的系统查询条件足够宽泛或者能动态适应变化。例如使用WithAnyISharedComponentData来查询所有拥有某种共享组件的实体而不是用WithSharedComponentFilter过滤特定值除非你确定值不会变。理解操作时机在Entities.ForEach内部尤其是在并行Job中绝对不能直接调用SetSharedComponentData或AddComponent等会引起结构变化的操作。这类操作必须通过EntityCommandBufferECB来记录并在主线程上执行。使用调试工具在Unity编辑器的Entities窗口Window Analysis Entities中你可以查看所有Archetype和实体。修改共享值后观察实体是否移动到了新的Archetype下。这是最直观的调试方法。正确做法示例// 在System中通过ECB安全地修改共享组件 public partial struct ChangeTeamSystem : ISystem { private EntityQuery _unitsToChangeQuery; public void OnCreate(ref SystemState state) { // 查询所有有TeamSharedData但需要改变队伍的实体例如有一个ChangeTeamRequest组件 _unitsToChangeQuery state.GetEntityQuery( ComponentType.ReadWriteTeamSharedData(), ComponentType.ReadOnlyChangeTeamRequest() ); } public void OnUpdate(ref SystemState state) { var ecb new EntityCommandBuffer(Allocator.TempJob); // 必须运行在主线程因为涉及结构变更 foreach (var (teamData, request, entity) in SystemAPI.QueryTeamSharedData, ChangeTeamRequest().WithEntityAccess()) { TeamSharedData newTeamData new TeamSharedData { TeamColor request.NewColor }; // 通过ECB安排共享组件的修改 ecb.SetSharedComponent(entity, newTeamData); ecb.RemoveComponentChangeTeamRequest(entity); // 移除请求 } ecb.Playback(state.EntityManager); ecb.Dispose(); } }5.2 问题二使用了共享组件后内存或性能反而变差了现象引入了共享组件来优化但通过Profiler发现Archetype数量激增Chunk利用率下降甚至出现了卡顿。根因共享组件被滥用了。如果你为大量实体设置了唯一的共享组件值例如每个实体都有一个不同的随机颜色材质引用那么每个唯一的共享值都会创建一个新的Archetype。如果有1万个实体每个颜色都不同就会产生1万个Archetype每个Archetype可能只包含一个实体一个Chunk这完全破坏了ECS的内存连续性和批处理优势。排查与解决审查共享组件的使用场景问自己这个数据是否真的被大量实体共享如果共享的实体数量很少比如少于10个或者每个实体值都不同那么绝对不应该使用共享组件。改用普通IComponentData或DynamicBuffer。监控Archetype数量在Entities窗口中关注Archetype的数量。如果某个共享组件导致了成百上千个Archetype就需要重新设计。考虑使用“分类索引”如果确实需要很多不同的“类别”但每个类别内实体数很多可以这样做// 不好的做法直接存储Material引用在共享组件中且每个实体不同。 // 好的做法使用一个枚举或整数ID作为共享组件值。 public struct MaterialIDShared : ISharedComponentData { public int ID; // 0Red, 1Blue, 2Green... } // 然后在某个系统或Singleton中维护一个从ID到实际Material的映射表。 // 这样即使有100种材质也最多只有100个Archetype而不是每个实体一个。5.3 问题三共享组件中包含引用类型字段导致序列化或烘焙错误现象在Baker中尝试为共享组件设置一个GameObject或Material字段或者尝试序列化包含复杂引用类型的共享组件时编辑器报错或构建后数据丢失。根因共享组件需要被序列化到SubScene或Prefab中。Unity的序列化系统对引用类型尤其是UnityEngine.Object子类的处理有特定规则。并非所有引用类型都能被正确序列化和在运行时访问。排查与解决优先使用Entity或BlobAssetReference对于纯ECS架构最佳实践是使用Entity引用Prefab或者使用BlobAssetReference来存储复杂的只读配置数据。BlobAsset是ECS原生、线程安全且高效的数据容器。如果必须使用GameObject/MonoBehaviour引用确保该引用对象本身也被烘焙到了SubScene中即它也是一个Entity或存在于被烘焙的GameObject上。在Baker中使用GetComponent、GetEntity等方法正确获取引用。理解这属于Hybrid ECS模式会引入GameObject到Entity的转换层性能上不如纯ECS。避免在共享组件中使用string、普通数组或List这些很难被ECS序列化系统正确处理。对于字符串考虑使用FixedString来自Unity.Collections对于数组使用BlobArray在BlobAsset中。BlobAsset最佳实践示例// 1. 定义Blob数据结构 public struct EnemyConfigBlob { public float SpawnHealth; public float DamagePerHit; public BlobString Name; // 使用BlobString代替string } // 2. 在Baker中创建BlobAsset public class EnemyConfigBaker : BakerEnemyConfigAuthoring { public override void Bake(EnemyConfigAuthoring authoring) { var builder new BlobBuilder(Allocator.Temp); ref EnemyConfigBlob config ref builder.ConstructRootEnemyConfigBlob(); config.SpawnHealth authoring.Health; config.DamagePerHit authoring.Damage; builder.AllocateString(ref config.Name, authoring.Name); BlobAssetReferenceEnemyConfigBlob blobRef builder.CreateBlobAssetReferenceEnemyConfigBlob(Allocator.Persistent); builder.Dispose(); // 3. 将BlobAssetReference添加到一个共享组件或普通组件中 var entity GetEntity(TransformUsageFlags.None); AddComponent(entity, new EnemyConfigReference { Value blobRef }); // 或者如果你希望多个实体共享可以创建一个Singleton实体存储这个引用或者使用共享组件。 } } // 4. 在System中通过Dereference读取 var configRef SystemAPI.GetSingletonEnemyConfigReference().Value; ref EnemyConfigBlob config ref configRef.Value; // 注意这是ref引用非常高效 float health config.SpawnHealth;共享组件是ECS工具箱中一把强大但需要谨慎使用的利器。用得好它能大幅降低内存占用、提升渲染效率用不好则会引入性能陷阱和复杂性。核心原则始终是仅将那些真正被大量实体共享、且几乎不变的数据放入共享组件。在不确定时先从普通组件开始在性能分析数据的指导下再考虑是否引入共享组件进行优化。