软件架构

接下来是按系统划分的对模拟器软件架构的介绍。文中会引用部分 SimulatorX 的源代码。

由于下文的许多分享都基于 Flux 架构的相关概念，这里先对其进行简单介绍。

Flux

在旧版模拟器 Simulator 的研发后期，由于代码耦合严重、功能划分模糊，难以加入更多新功能，甚至妨碍了已有 Bug 的修复。为了解决这一问题，SimulatorX 将前端开发中常用的 Flux 架构引入到游戏开发中，以求提高系统的可维护性和可拓展性。

（引自 阮一峰的网络日志）

我的理解，Flux 的核心就是一个简单的约定：视图层组件不允许直接修改应用状态，只能触发 action。应用的状态必须独立出来放到 store 里面统一管理，通过侦听 action 来执行具体的状态操作。

所谓的单向数据流，就是当用户进行操作的时候，会从组件发出一个 action，这个 action 流到 store 里面，触发 store 对状态进行改动，然后 store 又触发组件基于新的状态重新渲染。

作者：尤雨溪 来源：知乎

为简化架构，我们将 View 层的功能合并到了 Store 中。场景中大多数的组件以 Store 形式存在，产生并消费 Action；而所有的 Action 都通过 Dispatcher 进行分发，保证其单向流动，以此将场景中的各部分解耦。实际上 Flux 架构就是应用范围更大、流向更统一的游戏事件系统。

场景中每个实体内部状态的更改都由接收到的 Action 驱动，而非由其他实体进行直接修改，降低了实体间的耦合度。相比经常只存在于局部逻辑中的事件系统，Dispatcher 作为分发所有 Action 事件总线，有一些有趣的特性，比如大大简化了 Demo 重放功能的实现。

下面是一个 Flux 架构下工作流的例子：