接下来，我要给大家介绍一个很重要的东西——EntityCommandBufferSystem。

1.不能在Job中执行的操作

我们已经知道，JobComponentSystem配合各种Job（IJobForEach、IJobChunk等），可以方便地实现并行（多线程、多核）执行逻辑。

既然涉及到多线程，就会有一个麻烦的事情——某个线程做了破坏结构的操作，其他线程会受到影响。

这是什么意思呢？

比如，某个Job给实体删除了一个组件，会发生什么事情？

我们的实体都是按块（Chunk）存储的，一个块里的所有实体必定拥有相同数量和类型的组件，一旦某个实体的组件数量或类型改变了，它就不属于当前的块，它会被移到其他块里。

所以，回到刚刚的问题，某个Job给实体删除了一个组件，那么，这个实体就会被移到另一个块里。

那么，另外一个并行Job呢？这个并行的Job还不知道实体被移到另一个块了，也不知道这个实体被删除了某个组件，所以这个并行的Job会做出一些不太正确的操作。（操作了即将不存在的组件、操作了错误的块里的实体）

为了解决这种冲突，ECS规定，以下行为都不能在Job中处理：

创建实体（Create Entities）

销毁实体（Destroy Entities）

给实体添加组件（Add Components）

删除实体的组件（Remove Components）

2.EntityCommandBufferSystem

上面的四种行为都不能在Job中处理，但是，很多情况下，只有在Job中才能决定要不要创建实体、添加组件等，这种时候应该怎么办？

于是，就有了EntityCommandBufferSystem。

简单地说，EntityCommandBufferSystem可以让我们在Job里添加一些任务队列，然后在主线程中执行这些任务。

我们再来回忆一下，上一篇提到的System执行顺序：

我们应该能发现，每一个系统分组下都有两个EntityCommandBufferSystem，并且分别都是Begin和End对应的。

所以，实际上，ECS默认的三个系统分组，有分别都一个Begin和End的EntityCommandBufferSystem。为的是让我们可以在分组的开始或结束时作一些特定的操作。

比如，创建实体，大部分情况下就是在第一个分组的BeginInitializationEntityCommandBufferSystem里进行。

另外，和大家补充一下，System的OnUpdate函数都是在主线程调用的，Job才是在多线程中并行调用的。

所以，上图中的各个System必定是从上到下调用（每帧都调，不断循环）。

我们简单点，只看第一个分组：

InitializationSystemGroup是负责初始化工作的系统分组，假设我们想创建或销毁实体，那么，最好就是在初始化阶段进行。

BeginInitializationEntityCommandBufferSystem是在初始化阶段的第一个System，它是最先执行的，我们只要把创建实体的操作放到它里面执行，就不怕后续的逻辑出现的冲突问题了。

那么，问题就变成了—— 如何把创建实体的操作放到初始化阶段进行？

更进一步—— 如何把创建实体的操作放到 BeginInitializationEntityCommandBufferSystem 进行？

3.BeginInitializationEntityCommandBufferSystem

我来给大家演示一下，怎么把创建实体的操作放到EntityCommandBufferSystem里执行。

先看看一个System类代码：

using Unity.Collections;
using Unity.Entities;
using Unity.Jobs;
using Unity.Mathematics;
using Unity.Transforms;
/// <summary>
/// 任务组件系统（JobComponentSystems）可以在工作线程上运行，但是创建和移除实体只能在主线程上做，从而防止线程之间的竞争
/// Jobs系统使用一个实体命令缓存（EntityCommandBuffer）来延迟那些不能在任务系统内完成的任务。
/// </summary>
[UpdateInGroup(typeof(SimulationSystemGroup))] /// 标记更新组为模拟系统组
public class SpawnerSystem_FromEntity : JobComponentSystem
	/// <summary>
	/// 开始初始化实体命令缓存系统（BeginInitializationEntityCommandBufferSystem）被用来创建一个命令缓存，
	/// 这个命令缓存将在阻塞系统执行时被回放。虽然初始化命令在生成任务（SpawnJob）中被记录下来，
	/// 它并非真正地被执行（或“回放”）直到相应的实体命令缓存系统（EntityCommandBufferSystem）被更新。
	/// 为了确保transform系统有机会在新生的实体初次被渲染之前运行，SpawnerSystem_FromEntity将使用
	/// 开始模拟实体命令缓存系统（BeginSimulationEntityCommandBufferSystem）来回放其命令。
	/// 这就导致了在记录命令和初始化实体之间一帧的延迟，但是该延迟实际通常被忽略掉。
	/// </summary>
	BeginInitializationEntityCommandBufferSystem m_EntityCommandBufferSystem;
	struct SpawnerJob : IJobForEachWithEntity<Spawner_FromEntity, LocalToWorld>
		/// <summary>
		/// 当前实体命令缓存
		/// </summary>
		public EntityCommandBuffer.Concurrent m_CommandBuffer;
		/// <summary>
		/// 这里循环实例化实体
		/// </summary>
		/// <param name="entity">实体</param>
		/// <param name="index">索引</param>
		/// <param name="spawner_FromEntity">生成器实体</param>
		/// <param name="location">相对位置</param>
		public void Execute(Entity entity, int index, ref Spawner_FromEntity spawner_FromEntity, [ReadOnly] ref LocalToWorld location)
			for (var x = 0; x < spawner_FromEntity.m_CountX; x++)
				for (var y = 0; y < spawner_FromEntity.m_CountY; y++)
					var instance = m_CommandBuffer.Instantiate(index, spawner_FromEntity.m_Porfab);
					// Place the instantiated in a grid with some noise
					var position = math.transform(location.Value,
						new float3(x * 1.3F, noise.cnoise(new float2(x, y) * 0.21F) * 2, y * 1.3F));
					m_CommandBuffer.SetComponent(index, instance, new Translation { Value = position });
			m_CommandBuffer.DestroyEntity(index, entity);
	/// <summary>
	/// 在这个字段中缓存BeginInitializationEntityCommandBufferSystem，这样我们就不需要每一帧去创建
	/// </summary>
	protected override void OnCreate()
		m_EntityCommandBufferSystem = World.GetOrCreateSystem<BeginInitializationEntityCommandBufferSystem>();
	protected override JobHandle OnUpdate(JobHandle inputDeps)
		/// 取代直接执行结构的改变，一个任务可以添加一个命令到EntityCommandBuffer（实体命令缓存），从而在主线程上完成其任务后执行这些改变
		/// 命令缓存允许在工作线程上执行任何潜在消耗大的计算，同时把实际的增删排到之后
		/// 把将要添加实例化命令到EntityCommandBuffer的任务加入计划
		var job = new SpawnerJob
			m_CommandBuffer = m_EntityCommandBufferSystem.CreateCommandBuffer().ToConcurrent()
		}.Schedule(this, inputDeps);
		/// 生成任务并行且没有同步机会直到阻塞系统执行
		/// 当阻塞系统执行时，我们想完成生成任务，然后再执行那些命令（创建实体并放置到指定位置）
		/// 我们需要告诉阻塞系统哪个任务需要在它能回放命令之前完成
		m_EntityCommandBufferSystem.AddJobHandleForProducer(job);
		return job;
a.BeginInitializationEntityCommandBufferSystem 是ECS自带的System类，为了避免在每一帧都创建或获取这个类对象，我们在OnCreate函数里通过World.GetOrCreateSystem获取这个类对象。
 
b.之前已经说过，默认情况下，我们的所有System都会被添加到World里，所以从World里获取某个System就很好理解了
 
接下来，再看看OnUpdate函数的逻辑：
 
这是有点熟悉又有点陌生的代码，我们来看看它做了什么：
 
a. 通过CreateCommandBuffer().ToConcurrent()函数创建了BeginInitializationEntityCommandBufferSystem的一个Buffer对象，我们可以理解成是一个队列，用来存放我们的操作。
 
b. Execute里查找的是带有Spawner_FromEntity组件的实体，这个组件晚点再说。总之，Spawner_FromEntity组件有一个Prefab字段，它保存了一个实体对象，我们需要通过这个实体对象复制任意多个新实体，即，创建实体。为了方便理解，我这里只创建了一个实体。
 
c. 通过commandBuffer.Instantiate创建了新实体，然后通过commandBuffer.DestroyEntity删除原来的实体（这个操作很重要，之后再解释）
 
d. Schedule返回的Job添加到BeginInitializationEntityCommandBufferSystem里。换言之，这一些列的操作，实际上已经添加到BeginInitializationEntityCommandBufferSystem里了。
 
总结一下就是，创建EntityCommandBufferSystem的buffer队列，将所有涉及到新增、删除实体或者新增、删除组件的操作都加到buffer队列里，最后将Job加到EntityCommandBufferSystem。
 
（旁白：你说的我都懂，但我就是不明白，为什么这样就能把新增实体的操作放到主线程了）
 
4.细节解释
 
我知道，大家可能有点懵，用法是这么用，代码大家可能也没有什么疑惑，但心里可能还是很纠结——这一切是怎么实现的？
 
是的，如果不搞懂这个的话，大家是没法好好利用EntityCommandBufferSystem的。
 
所以，我来给大家解释一下原理，其实原理非常简单，但我仍然研究了大半天才理顺了。
 
我们来走一下代码的执行过程（当然，是简化后的）。
 
b.执行InitializationSystemGroup分组（别忘了，系统分组也是System类），发现自己还有子系统，OK，执行子系统
 
c.执行BeginInitializationEntityCommandBufferSystem，发现队列里没有任何东西，好，白干了
 
d.又执行了一大堆System
 
e.执行SimulationSystemGroup分组，发现自己还有子系统，O了个K，执行子系统
 
f.又执行了一大堆System，来到了我们的SpawnerSystem_FromEntity系统，好，执行。于是，添加了一个Job到BeginInitializationEntityCommandBufferSystem
 
g.又执行了一大堆System、执行PresentationSystemGroup分组、又执行了一大堆System
 
h.好了一轮执行完了，又回到InitializationSystemGroup分组，发现自己还有子系统，OK，执行子系统
 
i.执行BeginInitializationEntityCommandBufferSystem，发现队列里有东西了！激动！执行！于是，我们之前添加的Job成功执行了，而且是在主线程里。
 
j.执行其他System
 
k.又结束一轮
 
只要理解了，这是一个循环，那就没什么难度了。
 
5.Job会被无限添加吗？
 
细心的朋友肯定发现一个重大问题了，SpawnerSystem_FromEntity的OnUpdate函数不是每帧都执行一次吗？
 
那不就代表每帧都添加了一个Job到BeginInitializationEntityCommandBufferSystem吗？
 
那不得出问题了吗？
 
你这ECS有毒！
 
唔，是的，其实这个细心的朋友就是我，我就纠结了这个问题很久。
 
后来研究了很久，才豁然开朗。
 
答案就是：在JobComponentSystem中，如果Job没有筛选出实体数据，那么，OnUpdate是不会被调用的。
 
比如，再看一次我们的OnUpdate函数：
 
筛选了Spawner_FromEntity组件的，而我们这个程序里只有一个实体拥有这个组件，而后面又通过DestroyEntity将筛选出来的实体删除了。
 
于是，在下一轮的循环中，已经筛选不出任何实体了，于是，OnUpdate函数也不会被调用。
 
我本来想结合ECS的源码讲解的，但是有点饶，我怕自己没理清，误导大家，所以就不展开了。
 
另外，被添加到EntityCommandBufferSystem的Job会不断被执行吗？
 
答案是：不会。
 
EntityCommandBufferSystem每次执行队列的任务后，都会清空，所以不用担心。
 
好了，关于EntityCommandBufferSystem，就说这么多。
 
理解起来可能有点乱，用多几次就好了。
 
6.另一种创建实体的方式
 
等等！好像有个坑还没填——Spawner_FromEntity组件是怎么样的？
 
这就涉及到另外一种创建实体的方式的了，我们来看看组件的代码：
 
using Unity.Entities;
public struct Spawner_FromEntity : IComponentData
	public Entity m_Porfab;
	public int m_CountX;
	public int m_CountY;
好，接着看看转换实体的代码：
 
using Unity.Entities;
using System.Collections.Generic;
using UnityEngine;
/// <summary>
/// 先将自己转换成实体，再由预设生成新的实体
/// </summary>
[RequiresEntityConversion] ///必须实体转化
public class SpawnerAuthoring_FromEntity : MonoBehaviour, IDeclareReferencedPrefabs, IConvertGameObjectToEntity
	public GameObject m_Prefab;
	public int m_CountX;
	public int m_CountY;
	/// <summary>
	/// IDeclareReferencedPrefabs接口的实现，声明引用的预设，好让转化系统提前知道它们的存在
	/// </summary>
	/// <param name="referencedPrefabs">引用的预设</param>
	public void DeclareReferencedPrefabs(List<GameObject> referencedPrefabs)
		referencedPrefabs.Add(m_Prefab);
	/// <summary>
	/// 我们将编辑器的数据表述转化成实体最佳的运行时表述
	/// </summary>
	/// <param name="entity">实体</param>
	/// <param name="dstManager">目标实体管理器</param>
	/// <param name="conversionSystem">转化系统</param>
	public void Convert(Entity entity, EntityManager dstManager, GameObjectConversionSystem conversionSystem)
		var spawnerData = new Spawner_FromEntity
			/// 被引用的预设因为做了声明将被转化成实体
			/// 所以我们这里只是将游戏对象标记到一个引用该预设的实体上
			m_Porfab = conversionSystem.GetPrimaryEntity(m_Prefab),
			m_CountX = m_CountX,
			m_CountY = m_CountY
		dstManager.AddComponentData(entity, spawnerData);
这段代码大家应该有一部分是有印象的，只是，这次的复杂一点。
 
但要理解还是没问题的，仍然一步步来：
 
a.这个类继承了MonoBehaviour，所以肯定也是要挂到GameObject下的
 
b.继承了IConvertGameObjectToEntity接口，于是也要实现Convert函数，Convert函数要做的事情和以前差不多，创建一个组件，然后把组件添加到实体里。
 
c.但是，这个组件有点特别，这个组件有一个Prefab字段，是Entity类型的。于是，调用GameObjectConversionSystem的GetPrimaryEntity函数，可以将我们的GameObject对象转换为Entity对象，然后赋值给组件。
 
d.于是，我们将当前的GameObject转换为了一个包含Spawner_FromEntity组件的实体，这个实体的组件又包含了一个新创建的实体，这个新实体是通过我们的Prefab预制体创建的。
 
e.DeclareReferencedPrefabs函数是做什么用呢？是为了让GameObjectConversionSystem对象知道我们的Prefab预制体的存在，以便通过预制体创建实体。
 
有点绕是不是？实际上我们现在有了两个实体了。
 
第一个：当前MonoBehaviour转换后的实体，包含Spawner_FromEntity组件；
 
第二个：Spawner_FromEntity组件的字段引用了另外一个实体，这个是通过Prefab预制体创建的实体。
 
最后，再看一次我们的System类的OnUpdate函数：
 
a.我们通过Spawner_FromEntity类型筛选出了一个实体，也就是我们的第一个实体。
 
b.这个实体通过第一个参数【Entity entity】传递进来。
 
c.接着，通过Spawner_FromEntity组件的Prefab字段（引用了我们的第二个实体）创建了一个新的实体
 
d.调用DestoryEntity把筛选出来的实体删除（即，删除了我们的第一个实体，所以连同它的组件也消失了，于是第二个实体也消失了）
 
好了，可能大家有点绕懵了，但，这就是第二种创建实体的方式。
 
而且，比起以前介绍的方式，这反而是更加推荐的，可能更实用的。
 
然后大家创建一个空的GameObject，把SpawnerAuthoring_FromEntity挂上去，然后再给它的Prefab拖个预制体上去，然后运行：
 
7.这种创建实体的方式有什么优势？
 
“好麻烦，不实用”，大家可能心里是这么想的，说实话，我一开始也是，整这么乱做什么。
 
其实，只要大家熟悉了EntityCommandBufferSystem，就不会觉得乱了。
 
不会觉得乱之后呢，就会发现，这确实是目前为止最灵活的方式。
 
首先，我们把空的GameObject转换为了实体，但它只是一个空的实体，不会在场景里展现出来。
 
而这个空实体的组件里引用了一个真正有用的实体，但这个实体还没有添加到EntityManager中，所以它也不会展现出来。
 
于是，这就变成了，我们可以在任何时候创建这个实体，而不是在MonoBehaviour的Start函数里创建。
 
比如，我们需要点击召唤按钮才能召唤生物，这种灵活的创建方式，不就能满足我们的需求了吗？
 
不过，因为我还没有用ECS做实际开发，所以，实际当中到底怎么样，都不好说。
 
注意，本系列教程基于DOTS相关预览版的Package包，是预览版，不代表正式版的时候也适用。
 
下图出自同样不错的官方案例讲解：https://blog.csdn.net/qq_30137245/article/details/99083411
 
1.任务系统Jobs是C#为了让我们安全地使用多线程而封装的；
 2.不能滥用任务系统，否则会引起线程之间的竞争，例如你有四个线程，但是现在有三个被占用，却有五个任务要完成，这时就3会五个任务去争夺一个线程，从而造成线程安全问题；
 3.任务组件系统可以在工作线程上运行，但是创建和移除实体只能在主线程上做，从而防止线程之间的竞争；
 4.为了确保任务可以完成，这里引入了命令缓存机制，就在先把任务缓存起来，等待主线程完成工作后，再进行增删实体的操作。
 5.关于阻塞系统，是为了确保安全而生，当线程在执行任务的时候，将其阻塞起来，避免其他任务误入，等任务完成之后，再执行下一个任务，从而有序进行。
                    最近在学习unity的ecs框架，转载几篇写的比较好的文章帮助理解原文日期2019-12-5 避免误导未来使用正式版的开发者。接下来，我要给大家介绍一个很重要的东西——EntityCommandBufferSystem。1.不能在Job中执行的操作我们已经知道，JobComponentSystem配合各种Job（IJobForEach、IJobChunk等），可以方便地实现...
				
Systems
System, ECS三要素之一，负责把组件当中的数据从一个状态转换到另一个状态的逻辑, 比如，一个system可以可能会根据所有移动实体的速度乘以自上次更新以来的时间间隔来更新它们的位置。
Unity ECS 提供了多种不同的systems. main systems 主系统你可以实现转换实体数据的系统是 ComponentSystem 和JobComponentSyste.........
				
以下文档均来源于ECS官网：
https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/ecs_entities.html
Entity Command Buffer（实体命令缓存）
EntityCommandBuffer类解决了两个重要问题：
当在Job中时，无法访问EntityManager
	当您访问Entity...
				
Entity Command Buffer （ECB）
在前面的例子中，我们都是通过EntityManager来创建或销毁Entity，或者给Entity添加删除Component。但是在实际的情况中，我们可能需要在System中来做这些操作，比如一个Entity有一个存活时长的属性，我们会用一个System来计算已存活的时间，当时间到了后销毁该Entity。
根据前面的知识，我们需要一个Component来存储这个存活时长的属性，例如：
struct Lifetime : IComponentDa
				
EntityCommandBufferSystem能使我们在System中创建/销毁Entity。
利用EntityCommandBufferSystem创建Entity
其实是利用EntityCommandBufferSystem将命令队列压入主线程执行。
1、首先设计Component：
using Unity.Entities;
public struct SpawnData : IComponentData
    public int Count;
    public Entity Tem
				
Unity ECS 小知识1 - PhysicsTrigger Event ，ECS套件学习过程中会遇到各种问题，专门开辟一个专题“ECS小知识”来记录这些点滴。每个小知识文章是没有先后顺序的，这里是第一篇 - 物理触发器 。小知识的所有Demo，都是使用ECS 0.50+的版本。具体不多做阐述，具体如何安装ECS环境，可以看我之前的文章 - Unity DOTS 学习笔记1 - ECS 0.50介绍和安装那么用例开始。
				
Using Entity Command Buffers – Unite Copenhagen 2019
https://www.youtube.com/watch?v=SecJibpoTYw
https://www.slideshare.net/unity3d/using-entity-command-buffers-unite-copenhagen-2019
https://...
    新的物理系统是什么？
    Unity Physics是在ECS上运行物理的附加功能。这个物理操作并不完全是Unity过去使用的过去和安全的PhysX，而是使用C＃完全重建的物理操作。
物理学的作用如下。
搜索空间以进行碰撞...
				
学习 Unity ECS 需要先了解 Unity 游戏引擎的基本知识，然后再学习 ECS 的相关知识。推荐以下学习方式：
1. 阅读官方文档：https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/index.html
2. 完成官方提供的 ECS 教程：https://learn.unity.com/project/unity-ecs-tutorial
3. 尝试自己创建一个简单的 ECS 项目，并在此过程中查阅相关资料解决问题
4. 加入 Unity 社区，与其他开发者一起讨论 ECS 相关问题
希望这些建议能帮助你开始学习 Unity ECS。