ECS，Entity(实体) Component(组件) System(系统)，是一个gameplay层面的框架，它是建立在渲染引擎，物理引擎之上的，主要解决的问题是如何建立一个模型来处理游戏对象的更新操作，是对数据集合的操作。

• Entity（实体），有点类似于Unity中的Game Object，在ECS中，它仅仅是一个Component（组件）的组合，不具有任何代表意义，它的意义就在于对其上的Component（组件）进行生命周期管理。
• Component（组件）是一个只包含数据的组件，将每个可能单独使用的对象属性归纳，里面只有数据没有任何方法，如角色的生命值蓝量就是一个Component（组件），每个Entity（实体）是由多个Component（组件）组合而成，共享一个生命周期。
• System（系统）则是用来处理数据的系统，里面只有方法，没有任何数据，每个System只关注于干好一件事情，它只关心那件事作用于游戏世界里同类的一组对象的每单个个体，或是这类对象的某种特定的交互行为。

ECS的作用

在System（系统）之间不用相互调用（减少相互耦合），是由游戏外部框架来驱动若干System（系统）的。这样一来每个System（系统）都可以独立开发，它只需要遍历框架提供给他的组件集合，做出正确的处理，更新组件状态就够了。

而编写Gamplay的人只需要清楚每个System（系统）到底做了什么，操作本身对哪些Component（组件）产生影响，正确书写System（系统）的更新次序就可以了。这样一来容易管理复杂度，二来给并行处理留下了优化空间

ECS的优劣

相比于传统的OOP，ECS在写法上要复杂很多，一个对象可以集中的数据来用多个Component（组件）来管理，还要额外的System（系统）来处理逻辑。但是，ECS它做到让设计分离了，由此的影响如下：

1. 减少多人开发时出问题的概率

如果有一个非常复杂的对象，许多人的工作都和这个对象有牵连，当A在进行逻辑处理时，他不得不传整个对象，还要考虑修改对其他人的影响；但是拆离后，A可以把自己的数据封在特殊的Component（组件）里，用自己的System（系统）处理，减少出问题概率（但是这样会增加代码复杂度）；

2. 基于组合优于继承原则

组合优于继承，这是设计层面上的原则，而ECS的Entity（实体）则是Component（组件）的组合，提高了复用性，也方便我们只关注处理对下对象的某个局部；且当我们对某个功能进行拓展时，几乎不会影响到其它功能模块，因为每个部分都是几乎不关联的；

为什么组合优先于继承_Hopefully Sky的博客-CSDN博客_组合优于继承 

3. 容易预测和回滚

ECS的初衷就是为解决预测和回滚的，因为数据和状态都存储在Component（组件）里面，因此记录关键帧的数据和状态非常方便，这就使得实现预测和回滚容易许多；

4. 适合游戏开发层面做逻辑表现分离

同一套逻辑处理系统，加了表现组件就有了表现，可以放在客户端，不加的话就是纯逻辑，放在服务端确认客户端回传的数据。一套代码又能做服务器又能做客户端；

5. 提升性能

ECS这种面向数据的方式，使得内存排列天然紧密，非常适合现代CPU的缓存机制，极大增加了CPU的缓存命中率，大幅提升了性能。

6. ECS的劣势

ECS在处理大批量数据上有明显的优势，但是在处理小数据上如UI层面，网络层面上等就不太适合使用。而且Component（组件）本身不知道哪些System（系统）关注它，System（系统）也不知道什么时候关注的Component（组件）发生改变，即无法做到自驱动，必须有外部的东西来驱动这些System（系统）去工作，其实还需要许多Utility来辅助工作。