ECS架构笔记

ECS的介绍 云风写的非常好: https://blog.codingnow.com/2017/06/overwatch_ecs.html#more

ECS不是银弹，但在3D引擎领域是一个比较合适的框架, 目前的大多数现代3D引擎，或多或少都采用这种设计思想，比如Unity, UnReal。当然后面应该会有更为先进的框架出现。

在这近一年的工作中，我基本经历了从传统渲染树到ECS架构的变化，感受到ECS在这个领域的相对先进性，记录一下。就自己之前做Android的经历，很多人只能接触到MVC/MVP/MVVM(因为它们够简单直白)，架构思想被限制在一个界限内。ECS是不适合UI层设计的，但是它提供了一种新的视角和理念。

1. ECS是一个典型设计思想的体现: 组合大于继承，Entity在这个体系里完全被剥离成一个最纯粹的锚点，他的属性只有一个：存在性。所有的功能都由Component和System协同来完成。Entity只提供了Component锚定和组织作用(组织作用其实也被极度弱化，可以理解为一个最简单直白的集合)。Component和System可以自由靠挂，扩展性很强。
2. System和Component体现了单一职责的设计理念: 每种类型的System和对应的Component高度契合，两者结合在一起实现了某一类的特定功能(当然，一对一的关系不是绝对的，某些Component可能和会复数的System交互，这是合理的，Component是数据，而数据是中性的)。
3. System和Component的协同关系某种意义上不是OOP，而是AOP。System是无状态的功能切片，而Component则作为数据和状态的被动维护者。System只处理自己对应的Component，对其他的Component和System基本保持一个不可知状态(在ECS中，System之间协作应该是需要被克制的)，保证了功能之间的隔离性。
4. ECS相较之前传统3D引擎设计思路的一个最明显的区别是: 连”位置”这个概念都会被处理为一个Component。而不是传统思路中，基于位置关系来构造整个场景树。是Entity纯粹存在性的一个体现。ECS是一个集合，而非一棵树，树关系体现通过位置Component之间的串接来体现。
5. 个人认为ECS在隔离性上做的很好，但是高隔离的代价是通信和数据汇总会相对困难，不过前者一般是由引擎的调用者来实现的业务逻辑。后者，Entity作为一个锚点，完全可以基于这个锚点将其靠挂的Component全部获取，来得到汇总的数据，这个操作是外面逻辑进行，还是引擎提供便利化封装，甚至专门做一个汇总型的Component(不过已经破坏了ECS的隔离性，一种类型的Component会感知到其他类型的Component，甚至了解其细节)，应该有一定的选择自由度。
6. ECS处理的是这样一个场景: 有一堆实体的集合，每个实体有一些共性，但是也会有自己的特殊性和处理逻辑。后期新实体和新特性的引入要对旧逻辑造成最小的影响。