ECS即Entity-Component-System，实体-组件系统的意思，是一套游戏层的架构，是基于属性的游戏架构.出现很早，随着《守望先锋》架构设计与网络同步 – GDC2017 而进入大众视野，unity2018版本直接内置了ecs,同时新起来的开源游戏引擎CLEngine也内置了ecs。google开源的https://github.com/sschmid/Entitas-CSharp/wiki也是一套ecs框架
 
基本思想
 
Entity
代表一个独立的个体。
Component
一个个体某方面的数据，以及它与游戏世界的交互方法。
System
持续地对Entity上与System对应的Component进行处理，每个System都有独立的更新
Entity : 无数据无逻辑，单纯是一个实例，拥有若干Component
Component：只有数据没有逻辑，可以被Entity动态添加和移除
System：只有逻辑，只关心Component不关心Entity
World：缓存所有Entity与Component，并对System进行轮询，负责整个系统的运转
 
ECS系统与传统OOP的区别
 
在OOP系统中，对象的状态是封装到个体中的，对象会提供一些手段来间接操作这些状态（
 
这样的系统其实并没有什么问题，但从游戏开发的角度来讲，当你把一切都封装好并良构之后，游戏设计师突然表示他需要一项和之前完全不一样的功能，而一般灾难都是从这里开始的。
 
我们现在知道ECS系统的特征是将状态（由Component提供）与行为（由System系统）进行分离，而Component之间是独立的，我们完全可以通过单独添加新的Component和System来添加新的功能而不修改任何代码，而这也是设计模式中策略模式的思想。
 
实例
 
Entity
 
// AddComponent的功能是在world中创建Component并且添加到该Entity的Component集合中。
public Entity bullet = new Entity(_entityID);
bullet.AddComponent(new TransformComponent());
bullet.AddComponent(new MoveComponent());
 
Component
 
class TransformComponent
｛
    Vector3 position;
    Vector3 rotation;
｝
class MoveComponent
｛
    Vector3 speed;
｝
 
System
 
class MoveSystem
｛
    public void Update(float time)
    ｛
        foreach(var movecomponent in movecomponents)
        ｛
            // 查找该Entity是否拥有TransformComponent
            var transformcomponent = movecomponent.sibling(TransformComponent())
            if(transformcomponent != null)
                transformcomponent.position += movecomponent.speed * time;
        ｝
    ｝
｝
 
ECS 模型的结构是非常简洁明晰的，而且由于Component 中只有状态没有逻辑，可以很大的提高 Component 的复用度，以及同类 Component 在内存中是连续分布的，可以很大的提高缓存命中率（关于这点还在想该如何设计数据结构才能达到目的）
对于System需要使用的（整个 world 中唯一的）状态，遵循 System 中无状态的原则，使用 SingletonComponent 的方式去实现（参考 OW ECS 架构中的 SingletonComponent 部分）
将共享的 System 函数分解成 Utility ，减少调用，整合调用点
延迟执行（Deferment）的使用，即先缓存需要执行的状态，在更好的时间点集中调用（这点有很广泛的应用价值）
 
例子2
 
假设我们有一个绘制函数，这个绘制函数就是一个System，它去会遍历所有带有physical和visible组件的entity，然后利用提供的信息来绘制。
 
visible组件内包含有“entity看起来应该是什么样”的信息，而physical组件提供绘制的位置。
 
再以碰撞检测为例子。System会遍历所有拥有物理Component的entity，然后对碰撞进行检测并在需要的时候产生对应的事件。
 
为Unity设计的ECS系统（Entitas）
 
在Unity传统编程中，我们利用MonoBehavior来编写游戏
 
核心思想：将数据和行为分开。
 
在Unity中，我们将MonoBehavior组件放到GameObject中。但Entity系统中不同，Component被设计为附加到Entity上。
使用一个pool来包含所有Entity。通过pool我们可以看到所有的entity。
我们可以对entity进行分组，分组叫做group。之后我们可以通过指定的规则来区分不同的group，
这个规则叫做matcher，通过matcher可以方便地快速获得指定类型的entity。
 
cocos使用ecs
 
https://www.cnblogs.com/FuTaimeng/p/5572190.html

简介：
 
提一下Unity中的Update方法，相信很多开发者都深有体会，引擎中所有的Update是每帧遍历执行的，引擎中的模块多，很多模块我们往往并不使用，此时带来了很大的消耗，可以考虑使用一下ECS框架，可以完美解决这个问题，《守望先锋》游戏正是使用该框架设计。
 
ECS编程思想
 
这种编程思想很早前就已经提出,ECS分别是Entity,Component,System的缩写. 
 - Entity是实例,作为承载组件的载体,也是框架中维护对象的实体. 
 - Component只包含数据,具备这个组件便具有这个功能. 
 - System作为逻辑维护,维护对应的组件执行相关操作.
 
ECS和传统的OOP相比更看重的是组件,附加组件即具备功能.
 
C#是面向对象语言,从语言层面上就支持面向对象的编程思想:集成封装和多态.
 
 
面向对象:我是什么,我有属性,我有方法,我要继承然后重写成自己独有的.
 
 
面向组件:我有什么,我有组件便具备这个功能,我由很多组件组成了实体.
 
按照ECS的思路,功能拆分成组件,然后把这些细小的组件组合便组成了具备所需功能的对象.实际上Unity也是这种实现思路,但是它的组件式属性和逻辑的合集.
 
最近看了ECS编程思想,看了Entitas逻辑,写了小Demo,感觉:
 
编程思路/框架没有最好只有更合适,可能A框架适合RPG游戏,B框架更适合FPS游戏.
 
 
Entity的时序
 
开发中经常会遇到控制时序的逻辑,比如某个Entity必须在另一个Entity逻辑完成后再执行,当然可以通过添加组件标识来控制时序执行,但是如果存在大量这种逻辑势必会增加很多对应的组件作为标识.
 
 
System时序
 
同样可以添加Component作为控制标识作为过滤条件,A系统要在B系统结束之后,C系统启动之前,D系统挂起时…开发到后期怎么办.(待机,前摇,蓄能,施法,表现,结束,)太多太多状态一帧/分帧维护起来估计也会乱吧.
 
 
System更合适维护一组Entity
 
  
 
比如FPS游戏,MOBA游戏用ECS思想拆分合适,每个玩家的角色功能对等(都是人物,都在移动,战斗)不同的角色的技能枪支拆分单独实现.
 
 
如果是大型RPG游戏,每个门派角色,大厅npc,商城商人,敌人角色的状态动作各不相同,这种ECS当然能实现,每个功能,拆分成细小组件,创建对应System类维护,但是这样归根到底一个System经过遍历筛选其实只维护了一个Entity上面的组件.因为角色功能独有,以后这个组件也不会被其他Entity组合使用.
 
 
功能解耦
 
功能之间解耦,对应的组件和系统只关心本身的功能,不会对其他功能造成影响.
 
 
重构
 
不方便重构
 
 
数据维护
 
数据分散到对应的组件,比如服务器下发一份最新数据,需要一一维护对应组件的属性,数据收集也是如此.
 
 
客户端服务器共享代码
 
客户端拆分表现组件后,只包含纯逻辑功能.
 
 
数据层表现层分离
 
在不同的组件和系统中维护,不必像oop再拆分表现逻辑.
 
 
方便扩展
 
如果设计合理,可以通过现有组件组合新的Entity. 
 1- 性能
 
数据在内存中线性存在,Entity复用.
 
ECS框架:Entitas
 
基于ECS的框架有很多,Entitas便是其中一个.
 
官方的ECS也会在2018.1beta版本中推出.
 
根据wiki很容易就能够搭建起项目,运行起工程,但是有些也需要开发者注意,比如Component作为标识还是作为数据存储;Component生成代码后改变类型或者删除字段后的生成报错,Group/Feature/Unit使用等等.
 
关于代码生成,它提供两个版本: 
 - 免费版 
 - 收费版
 
免费版根据反射生成代码,需要无编译错误下运行;收费版不需要,即使有代码报错也可以生成代码.
 
自己扩展的代码可以分为两部分: 
 - Components 
 - 其他代码(System,Service…等其他逻辑)
 
这样做的好处是重新生成代码时,方便的把这两个目录移除项目(或者StreamingAssets),生成基础代码,然后移回Component代码,然后生成组件代码,然后移回其他代码.
 
Entitas实践
 
最简单的输出hello world
 
创建一个Component:
 
public class HelloWorldComponent : IComponent
{
    public string s;
}
 
生成代码后创建两个system,一个用来创建entity并附加组件,另一个用来输出日志:
 
public class CreatSystem : IInitializeSystem
{
    private Contexts _contexts;
    public CreatSystem(Contexts contexts)
    {
        _contexts = contexts;
    }
    public void Initialize()
    {
        var e = _contexts.game.CreateEntity();
        e.AddHelloWorld("hello world");
    }
}
 
public class HelloWorldSystem : ReactiveSystem<GameEntity>
{
    private Contexts _contexts;

    public HelloWorldSystem(Contexts contexts) : base(contexts.game){
    }

    protected override ICollector<GameEntity> GetTrigger(IContext<GameEntity> context)
    {
        return context.CreateCollector(GameMatcher.HelloWorld);
    }
    protected override bool Filter(GameEntity entity)
    {
        return entity.hasHelloWorld;
    }
    protected override void Execute(List<GameEntity> entities)
    {
        foreach (var e in entities)
        {
            Debug.Log(e.helloWorld.s);
        }
    }
}
 
上面的代码已经实现了输出功能,但是为了方便管理上面的这两个System,我们添加一个RootSystems专门管理游戏中的各种System:
 
public class RootSystems : Feature
{
    public RootSystems(Contexts contexts)
    {
        Add(new CreatSystem(contexts));
        Add(new HelloWorldSystem(contexts));
    }
}
 
所有的功能都实现了,在unity工程中添加一个入口方法挂载到场景中,Main.cs:
 
public class Main : MonoBehaviour
{
    private RootSystems s;
    // Use this for initialization
    void Start()
    {
        s = new RootSystems(Contexts.sharedInstance);
        s.Initialize();
    }
    // Update is called once per frame
    void Update()
    {
        s.Execute();
    }
}
 
运行,正常输出,因为输出实现的是reactivesystem,当值发生变化时便会输出.

说起来比较汗颜，自从掌握了PureMVC并基于此思想搭建了一个自己的PureMVC框架后就再没碰过其他框架了，后来听说StrangeIOC框架用的比较多一直打算学习一下，结果后面忙于各种事一直没有时间，最终unity推出了ECS框架，据说对性能方面有了非常大的提升，所以不得不学一下新框架了。
 
简介（来源：https://www.bilibili.com/read/cv6312903）：
 
ECS，即Entity（实体） Component（组件） System（系统），是Unity以“面向数据”为理念（DOTS）构建的另一个新核心。此技术能大幅增加CPU利用效率以及简化多核处理的繁琐编程，相比“面向对象”的设计模式能快一个数量级以上。
 
实体（Entity） -这里实体只是一个索引，一个整数，或是可以理解为一个空箱子，类似一个连Transform都没有的Empty Object。它存在的目的就是去给数据打包贴标签，这样一大片数据里能分清谁是谁的。
组件（Component）-组件是结构体，类似于一个个安静的数据盒子，里面可以存位置、速度等各种常数向量，或是材质、Mesh等更复杂的数据。这些数据会根据内容被集中存放，这样之后大规模处理起来会很效率。
系统（System） -系统就是用来改变数据的静态方法。一个系统一般偏向只针对几个类型的数据，也就是说一个实体往往会被很多系统影响，例如一个方块边跑边转可能需要MoveSystem和RotateSystem。当然合并写成一个System并不是不可以，只是不利于测试和效率。System默认是影响全局的，例如在没有指定过滤条件的情况下一个“移动系统”会让所有带有“位置组件”的实体同时移动。
一.环境：unity 2018及以上版本，本文基于unity 2020.2.3f1c1版本
 
二.导入框架：
 
1.新建一个工程
 
2.在菜单栏通过Window->Package Manager打开资源包管理窗口
 
 
3.2018版在资源包管理窗口中点击"All"，从中找到Entities包并通过右上角的Install导入
 
 
此处容易出现以下问题：
 
 
解决方法：在PlayerSettings面板中将Scripting Runtime Version修改为.NET 4.x Equivalent便可解决
 
2020版通过点击左上方的+—>Add pakage from git URL，在搜索框中输入com.unity.entities 点击Add之后等一会便可以将Entities添加入项目
 
 
此时菜单栏应该会出现Jobs选项，至此ECS框架便宣告导入成功
 

ECS框架
 
Entity（实体）
Component（组件）
System（系统）
 
ECS框架是一个为了迎合游戏开发，在进几年开始慢慢被推荐熟知的框架，最有代表性的作品就是《守望先锋》 ，其对传统的面向对象设计，组件化思维做了进一步的拆解，分成了Entity,Component,System3个部分，三者关系如图：
 
 
下面具体说一下这3个部分的功能和特性。
 
Entity
 
Entity就是我们的游戏世界的各个实体，如人物、枪支、建筑等等最直接的物体原型。无数个Entity构成勒我们整个游戏世界，同样，我们的游戏世界，也就是安装各个规则去运营各个Entity。在传统的面向对象中，一个实体一般是有各种属性，各种功能函数，各种继承、联合等关联的繁杂存在，在ECS框架中，Entity的作品相对简单，ECS会把各种数据拆分对应到各个Component中，Entity根据需求仅需挂载对应属性的Component，而不用关系具体的数据，且各种Component的逻辑处理拆分到对应各个System中，这样，Entity仅是一个包含多个Component的载体。
 
举个例子，游戏世界中一辆车，它是一个Entity，它能移动、碰撞、买卖，我们只需挂载对应moveComponent、crashComponent、tradeComponent组件即可，至于各个Component到底存了什么数据，怎么维护的，这都不是Entity需要考虑的，我们只要指定其能移动、碰撞、交易就好了，是不是很简单。
 
Component
 
做游戏开发的同学肯定对组件比较熟悉，Component是指具有某一个特定功能特性的组件，传统框架中，我们给一个对象挂载一个组件，通常是对对象附加对应的逻辑处理，从而来让对象具有对应的功能，而在ECS中，则把特定的功能特性划分得更彻底，更加强调解耦。对应这个思路，ECS中的Component可理解为专门存储对应特性的数据集合，而对应特性的逻辑，则放到对应的System中去处理。
 
仍然以上面的汽车的例子来讨论，汽车要移动，移动的这个特性对应游戏的实现其实是坐标的变化，那对应的数据就有position(x, y)，这里我们以二维坐标为例，moveComponent则存放position数据，具体的position的坐标变化逻辑，则放到对应的moveSystem中去处理，我们给汽车挂载moveComponent，这样汽车就能移动勒。
 
这里另外要强调一点，在ECS的框架中，特定的Component是要整合到一起的，Component中通常会有一个所有component实例化对象的集合，这样处理的好处就是能达到功能解耦，也能做到利用内存cache，达到更好的性能。后文会再去强调这一点。
 
System
 
游戏世界中，肯定会有各种各样的规则，我们把各种规则，再细分成各个系统，划分依据是系统最好是功能专一，与其它系统不能耦合，ECS中把这些成为System，且与Component能对应，System主要处理对应Component的逻辑。
 
如上面汽车的例子，可能游戏世界，不止汽车会移动，玩家也能奔跑，其也能移动，总之，游戏世界中，所有挂载勒moveComponent的Entity都具有移动的功能，所有的moveComponent的移动逻辑，都归到moveSystem中去处理。
 
代码实例
 
有了以上的一些初步了解，那对比传统的面向对象，我们剖析一个案例，然后给出大致的代码框架，来更直接对比。
 案例：一个简单的竞速比赛，参数的载具有汽车、摩托车，且每个选手之间能发生碰撞，并掉血，若血量为0，则直接出局。
 
传统OOB设计
 
class Racer {
  hp: number; // 血量
  crashDecHp: number; // 碰撞扣除血量
  maxSpeed: number; // 最大速度
  accSpeed: number; // 加速度
  posX: number; // 横坐标
  posY: number; // 纵坐标
  // 处理碰撞逻辑
  checkCrash(){ ...}
  // 处理血量逻辑
  updateHp() { ...}
    // 处理移动逻辑
  updatePos() { ...}
}

class GameManager {
  allRacer: Racer[];

  updateGameLogic() {
    allRacer.forEach((racer) => {
      racer.updatePos();
      racer.checkCrash();
      racer.updateHp();
    });
  }
}
 
ECS
 
// entity和component的映射关系，可以根据自己需求去设计，这里只给出最简单的设计，仅供参考
class Racer {
	id: number
}

class MoveComponent: {
  static allMoveCom: MoveComponent[]; // 所有移动组件集合
  // 在entity上挂载component
  static registerCom(entity: Racer) {
    let newCom = new MoveComponent();
    this.allMoveCom.push(newCom);
  }
  // 销毁整个Component
  static destory();

  target: Racer; // 挂载的Entity对象，可根据自己需求设计entity和component的映射关系
  posX: number; // 横坐标
  posY: number; // 纵坐标
  speed: number; // 当前速度

  // 注销组件
  cancelComponent();
}

class MoveSystem {
  static Instance(): MoveSystem;
  updatePos(dt) {
    MoveComponent.allMoveCom.forEach((com) => {
      com.posX += com.speed * dt;
      // ...
    });
  }
}

class GameManager {
  // 注册System
  registerSystem();
  // 注销System
  cancelSystem();

  updateGameLogic() {
    MoveSystem.Instance.updatePos();
    // HPSystem,CrashSystem 类比MoveSystem
  }
}
 
ECS的优势
 
将数据更有效的组织，提高CPU cache利用率
 关于cache的利用率的好处，更多信息大家可以参考ECS 真的是「未来主流」的架构吗？的各位大牛的探讨。
逻辑更彻底的解耦，便于并行、扩展、整合
 逻辑解耦是所以框架都希望的解决的。传统的框架也是力求将游戏能拆分更好更干净的模块。
 
总结
 
ECS的并不是一个突如其来的框架，其思想在传统的游戏开发中多少都会运用到，比如“输入指令”，“网络模块”，各种单例的Manager类等等，其思想很接近ECS，只不过他们更多的吧ECS整合到一个类中，即保存数据，又处理逻辑，能完成单一独立的逻辑。ECS的思想则是看到这种设计的好处，把其严格的扩展到项目的所有逻辑处理中，所有的逻辑都拆分成System，需要参与其中的Entity挂载对应Component，这样项目的逻辑就非常解耦，便于扩充，维护。
 
一个东西出现，很容易被其亮眼的地方所吸引，但同时我们也要多思考其是否真的那么完美，这里推荐大家阅读下《ECS 真的是「未来主流」的架构吗？》，不一定要为了ECS就强行套用，等自己发现项目的System逻辑臃肿，自己也分不清怎么去解耦时，给自己带来的反而是困扰。
 
ECS本人并没有实际的项目经验，对其的理解可能也是停留在很肤浅的表面，本文的论述仅供参考，欢迎探讨指正。
 
参考资料
 
ECS 真的是「未来主流」的架构吗？
 浅谈《守望先锋》中的 ECS 构架
 游戏开发中的ECS 架构概述