Flux 架构简析

摘要

Flux 架构最初被 Facebook 使用来构建他们的客户端 web 应用。2015 年时有人提出了 Flux 架构在 Android 中的应用：

flux-architecture 原文链接

泡在网上的日子 曾翻译过这篇文章：

flux-architecture 译文地址

也推荐大家也看上面的文章，真真是极好的。

我的另一篇博客：

Flux Demo 源码解析

Flux 架构抽象

下图是最简单的 Flux 架构抽象图，与其他主流架构不同，Flux 架构最明显的两个特点是：

• 单向数据流
• 闭环

私以为 Flux 架构的核心是 Action，而一次完整的 Flux 闭环要经过下面 5 个步骤：

1. View 的交互/响应发出特定的 Action
2. Dispatcher 将 Action 分发至 Store
3. Store 响应 Action，作出相应的数据更新
4. Store 通知 View 数据变动
5. View 刷新

我们用 创建一个妹子 的过程来举例：

1. 点击 创建按钮，发送 Action : 添加一个妹子
2. Dispatcher 将 Action : 添加一个妹子 分发至 Store
3. Store 向数据集中添加一个 妹子
4. Store 通知 View 更新
5. View 出现一个 妹子

相信上面的过程很好理解，而 Flux 架构也真的就这么简单易懂，只是在实现时我们要考虑下面两点：

• 数据流如何传递
• Action 如何定义与发送

Flux 架构详解

我们先看一张更加完整的 Flux 架构实现图，相比于简单的抽象图，这张图里添加了：

• User Interaction : View 的用户交互事件，交付至 Actions Creator 生成不同的 Action
• Actions Creator : Action 生成器，响应用户交互，生成对应的 Action
• Change Event : Store 通知 View 的媒介

这里有一点疑问，依前文所说，View 的交互触发 Action 的发送，那么这个 Actions Creator 是作什么用的。我们还是通过 创建一个妹子 的过程举例说明：

可以看到，最终发送的是 Action : 创建一个妹子成功 或 Action : 创建一个妹子失败，而非 View 发出的 创建一个妹子 这个请求，即 Action 并不由 View 直接发送，而是由 Actions Creator 响应 View 操作，做出 API 请求等操作，根据操作结果发送相应的 Action

最后提一点，为了方便 View 直接获取数据（非修改数据），Store 会暴漏一些数据接口供以 View 调用，参加下图：