ECS（Entity-Component-System）模式

前言：

在使用Cocos Creator开发弹幕游戏的过程中，由于项目中出现的单位过多，导致项目的性能并不是特别理想，当时研究这个问题的时候看到用ECS可以解决这方面的问题，所以研究后将其应用进项目中，实践后发现ECS这种模式要去unity下插件配合使用效果才大，在cocos上效果甚微；不过上线后勉强还扛得住。目前使用对比：unity能抗住10000单位30帧，cocos10000单位只有20帧，啥也不用10000单位只有15帧。注：目前学习还不算完善，后续继续补充，有错误的，各位大佬受累帮小弟指正，万分感激！！！

简介：

ECS（Entity-Component-System）模式通常被归类为一种组件化设计模式，它主要用于构建游戏引擎和其他需要高度灵活性和性能的软件系统。尽管ECS模式在一些领域中非常流行，但它并不像传统的设计模式那样具有普遍性和标准化。在一些设计模式的分类中，ECS可能被归类为结构型模式或行为型模式的一种变体，具体取决于它是如何被应用和实现的。ECS模式的基本思想是将实体（Entity）分解为组件（Component），并通过系统（System）来处理这些组件。每个实体由一组组件构成，系统根据组件的类型和数据来执行特定的逻辑。这种模式的优势在于它的高度灵活性、可扩展性和性能优化，特别适用于需要处理大量实体和复杂逻辑的场景，比如游戏开发中的物体管理和行为控制。尽管ECS模式在特定领域中非常有用，但由于它的特殊性和定制性，通常不被纳入传统的设计模式范畴之中。

个人理解

E就是entity ，一个不代表任何意义的实体;

C就是各自脚本，Component 一个只包含数据的组件：（这里采用了黑板的形式来存储对应的数据，采用状态机来实现AI模块）

S就是整个游戏框架，包含所有Manager组成的游戏框架

其主要特点在于是面向数据编程，利用组合优于继承的思想，关注数据类型，关注系统的运行和状态，不关注具体某个对象的细节。数据与逻辑处理完全解耦。

优劣性：

参考文章

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

优势：

• 减少多人开发时遇到的问题

如果有一个非常复杂的对象，许多人的工作都和这个对象有牵连，当A在进行逻辑处理时，他不得不传整个对象，还要考虑修改对其他人的影响；

• 基于组合优于继承原则

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

• 容易预测和回滚

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

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

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

• 提升性能（在Cocos中的作用不是特别大）

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

劣势：

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