1.什么是ECS？
- 我们先简单地介绍一下什么是ECS：
- E -- Entity 实体，本质上是存放组件的容器
- C -- Component 组件，引擎所需的所有数据结构
- S -- System 系统，根据组件数据处理逻辑状态的管理器
ECS全称Entity-Component-System，即实体-组件-系统，是一种软件架构模式。其中的Component组件用来存放数据，不能实现任何处理状态相关的函数，而System系统不可以自己去记录维护任何状态。说的通俗点，就是组件放数据，系统来处理。这么做的好处，就是为了尽可能地让数据与逻辑进行解耦，可以降低代码复杂度。与此同时，一个良好的数据结构设计，也会以增加CPU缓存命中的形式来提升性能表现。
ECS架构看起来就是这样子的。先有个场景，它是系统（system）和实体（Entity）的集合。而实体就是一个ID，对应了组件（Component）的集合。组件用来存储数据并且没有任何的行为（Behavior）。System有行为但是没有数据。
与传统的”类-继承”奉行的“我是什么”不同，基于组件化的ECS架构更强调的是“我有什么”，是一种组合优先的编程模式。使用组合而非继承，会使代码更具灵活性。
对于很多人来说，ECS只是一个可以提升性能的架构，但是我觉得ECS更强大的地方在于可以降低代码复杂度。
MVC与ECS比较：
（1）MVC也好ECS也好他们都是一种编程的范式，或者说你组织代码的方式。然而他们的层面不同，也就是说不是一个层面的东西。
（2）MVC是一种分层的针对UI交互的设计，而ECS是一种处理对象关系的方式。
- （3）ECS其实更是解耦的终极方案，处理更复杂问题的一种更好的方案。另一方面MVC并不是不关注数据驱动，想要使用好MVC数据的驱动也是必须的才能更好的解耦。只不过MVC更关于也更适用于UI方面的交互罢了，当然这也是一种经验模型，后来的MVP以及MVVM都是一种优化或者特别场合的提升。
- 这两种架构方式并不冲突，可以视情况并同时使用。MVC比较实用于UI交互的设计，ECS比较适用于处理游戏物体间的业务逻辑关系。
2.ECS框架思想
数据都放在一边，需要的时候就去用，不需要的时候不要动。ECS 的本质就是数据和操作分离。传统OOP思想常常会面临一种情况，A打了B，那么到底是A主动打了B还是B被A打了，这个函数该放在哪里。但是ECS不用纠结这个问题，数据存放到Component种，逻辑直接由System接管。借着这个思想，我们可以大幅度减少函数调用的层次，进而缩短数据流传递的深度。
3.ECS遵循原则
- 设计并不是从Entity开始的，而是应该从System抽象出Component，最后组装到Entity中。
- 设计的过程中尽量确保每个System都依赖很多Component去运行，也就是说System和Component并不是一对一的关系，而是一对多的关系。所以xxxCOM不一定有xxxSys，xxxSys不一定有xxxCOM。
- System尽量不改变Component的数据。
4.ECS的优缺点
优势
- 数据和逻辑分离，耦合度低
- 用组合代替继承，复用度高
- 较容易进行性能优化
- 由于所有的数据都在Component中，如果能够在内存中以合理的方式将所有Component聚合到连续的内存中，这样可以大幅度提升CPU缓存的命中率
- 因为System之间已经完全解耦，所以理论上可以为每个System分配一个线程来运行
劣势
- 需要一定的学习成本，需要适应ECS的思考方式
- 需要花费更多的时间在代码结构的设计上
5.总结
- 依赖于抽象而不依赖于具体
- 减少依赖、降低耦合
- 尽量使用组合而不是继承
