ECS架构的思考

最近在整理Demo代码，遇到一个设计问题，这个问题是transform组件到底放到哪里比较合适？我们都知道逻辑，物理，渲染模块都会用到transform组件。比如渲染模块会将transform数据转换到instance buffer中。通常渲染模块做为底层模块会提供一个接口供上层的逻辑模块调用，也就是说将transform放到了逻辑模块中。但是对于渲染模块来说提供这个接口会影到渲染模块的设计。比如将instance buffer放到ResourceNode中(FrameGraph架构)，而ResourceNode是放到PassNode中的，这样就需要提供一系列的接口才能将transform数据设置到instance buffer中(GameObject->PassNode->ReourceNode）。我举得这个例子只是冰山一角，很多底层提供的接口都需要各种中转。因为我们的设计思路是自顶向下调用。这种设计是合理的因为我们希望底层库的设计者不被上层代码限制。但是这种设计并不优雅，为什么passnode要提供一个设置transform的接口呢？思考到这里我停留了很久，最终我发现ecs架构在处理这个问题上相当优雅。ecs将逻辑，物理， 渲染模块处理成平级的系统，它们彼此独立只关心自己system所需的数据，接口非常优雅。为此，我希望将ecs架构做为demo的核心架构。网上对ecs架构的讨论也很火热，褒贬不一，说一下我的观点吧。

上面这段话思维混乱，主要是我当时对渲染层的逻辑还不太熟悉。现在看来，对于Transform数据来说，逻辑层包含全部的数据，而渲染层包含需要渲染的数据，Transform数据从逻辑层到渲染层需要一个筛选处理。传统的架构因为数据和逻辑没有分离，需要将数据从一个系统塞进另一个系统中，它们是上下级的关系，而ecs系统将逻辑和数据分离，这样不同系统其实是平级的，它们共同处理相同的数据，只是处理上有先后顺序，从这个角度来说ecs架构很优雅而传统架构感觉很臃肿。

ecs是值得被尝试的架构，说一句不负责任的话就是存在即合理，ecs在最近被推出，一定是传统的游戏框架出了问题，因此许多人才会不遗余力的推出一种新的架构。其实ecs架构的思想并不新颖，只是在游戏这个行业可能用的比较少。此时的C程序员可能会看着我们C++程序员笑而不语了:)

任何程序设计都离不开数据结构与函数，狭义的讲，程序设计就是使用函数来处理数据。最初的编程语言是机器码，这种语言对机器特别友好，但是人阅读起来太麻烦了。因此汇编语言诞生了，汇编语言核心就是将字母组成的指令映射成数字组成的机器码。第一款汇编语言的编译器应该是用机器码写的，有了这个编译器我们就可以使用汇编语言来写汇编语言的编译器了。汇编语言从可读性上提高了编程的效率，但是汇编语言还是太接近机器语言了，它还是太关注硬件细节了。因此前辈们创造了最伟大的语言c语言。c语言不仅更接近人类的思维，而且他还能保证运行效率，因为一款优秀的编译器生成的汇编代码往往比我们手写的更高效。C语言很单纯，它符合编程的核心思想使用函数处理数据，因此c语言编程也被称为过程式编程。c语言已经很完美了，它可以胜任任何复杂的系统，比如操作系统。有人说c语言开发效率低，这点我不敢苟同，软件开发耗时更多的是在设计迭代上跟语言关系不大。人类总是贪婪的，懒惰也是一种贪婪的表现。为了能让编程语言更加符合人类的思维，OOP诞生了。我是一名C++程序员，OOP编程对我影响最大，如今看到ecs架构真的是感慨万千。以前引以为傲的OOP编程三大核心思想封装，继承，多态，如今正在被一步一步的推翻。

上面这段话我想表达的是ecs这种优雅的架构很适合c语言的过程式编程。

封装

封装就是抽象，是对复杂功能的拆解，其实就是在做一件事情，化繁为简。因此无论你使用什么语言都会进行封装，只是封装的手法不一样，比如c语言封装可能体现在一个.c文件中，而C++则是一个class类。因此封装并不是oop独有的，oop只是将表现手法变的简单了，oop将操作和数据放到了一起。就是这么一个简单的手法，让编程更加符合人类的思维了（偷懒。。。），因此开发效率大大提高。说到这里必须要提一下c语言的结构体，结构体是对数据的封装。考虑内存布局结构体数组可以分为soa和aos两种。在c语言中这两种布局都会被经常使用。但是到了C++基本上就变成aos这种了，原因就是因为class对数据和操作的封装。而ecs则倾向于soa，因为它的内存布局对缓存命中更加友好。这里其实可以看出机器语言和人类思维是相悖的，越接近人类的思维，越会抛弃对机器语言的友好。ECS架构其实是对OOP语言封装的一次打击，也就是我们所谓的数据与逻辑分离。要怪只能怪内存不争气，读写速度怎么发展的这么慢。操作与数据分离，会让系统更加的解耦，这也是我最开始考虑ecs架构的初衷。

上面这段话基本没什么毛病，c++的封装的确很容易让我们写出aos结构的代码，但是ecs架构虽然将数据和逻辑分离，但是还有很多system内部的数据需要封装在class中，从这个角度说封装并不是c++的错，而是我们过渡使用了封装的设计思想。

继承

继承是oop里面最大的败笔，当然继承设计的初衷是好的，就是复用能力，比如人只要继承眼睛，嘴巴就可以获得视觉和味觉。其实继承的层次结构，更多的是体现在设计上和语言关系不大。但是多重继承给人的感觉就是没有安全感，阅读起来太麻烦，而且会出现菱形结构。与继承相比组件模式更符合人的思维。因此EC架构其实是对oop架构继承的一次打击。继承的设计思想没有错，只是语言的表现手法不如组合更符合人的逻辑思维。ECS是EC的进阶版，它也是摒弃了继承(多重继承)而使用组件来完成复用。

因为继承可以被组件很好的替代，所以多重继承在编程上确实很鸡肋，单继承还是很有用的，可以用来做单例，多态。

多态
多态是对接口的复用，比如speak接口可以说中文也可以说英语，这种接口的复用要依靠封装和继承。C语言也可以实现多态，但是要在结构体里面存储函数指针，咳咳这不就是c++的封装了么。多态很美好给oop长脸了。ecs框架里面system只能靠if else了吧。

其实ecs架构很像过程式编程，ecs架构用c语言写更合适。

多态很重要，ecs中的System组件就需要使用多态来调用System，但是其他地方目前我还没有用到多态。

ecs架构的优点

1.内存布局更加高效

2.模块解耦性更好

3.对多线程编程友好

4.system很适合做白盒测试

缺点

1.反人类思维开发效率低

2.多人合作，开发效率可能呈指数倍递增

最后想说的是风水轮流转，谁说c++比c高级了，是英雄还是狗熊，取决于所处的时代。

目前在使用了ecs系统之后感觉它的缺点不明显，并不反人类，开发效率也不低，但这不代表结论，因为我做的功能还太少。