渲染引擎之ECS架构介绍

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的数据。