随着时间的流逝，我对iOS应用程序从 MVC模式带一个Storyboard 到 MVC模式待多个 Storyboards，最后到 MVVM模式 + Flow Coordinator —— 目前来说他是我们可以叫上名字的最佳实践了。MVVM模式 + Flow Coordinator 好是因为我们可以进行依赖注入，UIViewController 可复用行，可测试性。我有机会将此模式应用于生产中的大型复杂应用程序。但是最后，仍然有一些问题困扰着我：

我总是不得不一次次地写 Coordinator 模式
使用大量 delegate 模式，让 ViewModels 得到 Coordinator 回调信息
一开始我看 Redux 模式，尤其是导航状态机。我们可以有个全局导航状态，使用 RxSwift Observables暴露出来，然后监听状态驱动导航。唯一困扰我的是导航状态的唯一性，以及它可能具有不受控制的责任（以及它可以存储的海量数据）

出现了这样的一个想法：导航只是一种状态的反射，这种状态可以一步步修改。

一个状态，在整个应用程序结构中传播，不是存储在单个位置中，而是由观察者统一起来，可以对它作出反应并因此驱动导航。文章之后，这些分散在应用程序中的小状态称为“Steps”，观察者称为“Coordinator”。

RxFlow 来自经验总结，他解决了传统中仍然存在的两个主要问题;Coordinator pattern:

开发人员不必再编写Coordinator，他只需要声明导航及其所针对的状态
不需要 delegate，因为 state 是由 Loom 监听 RxSwift Observable

关键原则

要了解有关 Coordinator 模式的更多信息，我建议你开一下这篇文章 Coordinator Redux

尽管这是一个非常好的架构，但是Coordinator模式也有一些缺点：

每次引导应用程序时都必须编写协调机制
因为要使用 delegate 模式来处理与 Coordinator 之间通信，所以会有很多样板代码

RxFlow 是一个以响应式方式实现的 Coordinator 模式，它有 Coordinator 模式架构中的所有重要功能，但进行了一些改进：

使导航更具声明性
提供一个内置的协调器，用于处理你声明的导航流
使用响应式编程处理和 Coordinator 通讯的问题

必须熟悉6个术语才能理解RxFlow

Flow：每个 Flow 都在应用程序中定义了一个导航区域。这是你声明导航动作的地方
Step：每个 Step 在 App 中是一个导航状态。Flows 和 Steps 的组合描述了所有可能的导航操作。Step 甚至可以内嵌值（eg：Ids，URLs…）将会传播到 Flows 中声明的屏幕
Stepper：它可以是任何发出 Steps 的东西，Steppers 负责触发 Flows中的每个导航过程。
Presentable：它是可以呈现的事物的抽象类（基本上是UIViewController和Flow是可呈现的）。Presentables 提供响应式 Observables， Coordinator 将以兼容 UIKit 的方式，订阅这个 Observables 来控制Flow的 Steps
Flowable：它是一个结合了Presentable和Stepper的简单数据结构。它告诉 Coordinator 下一步将发生什么，这将在您的响应式机制中产生新的 Steps
Coordinator：一旦开发人员定义完代表导航可能性的流程和步骤的组合，Coordinator 的工作就是以一致的方式混合这些组合。

第一篇文章只是说明框架的概念理论，接下的文章将会从源码的角度讨论更多有关 RxFlow 的技术点。