<b>本文讲的是iOS 开发中的 Flux 架构模式，</b>
<b></b>
在半年前，我开始在 <code>PlanGrid</code> iOS 应用程序中采用 <code>Flux</code> 架构（开发）。这篇文章将会讨论我们从传统的 <code>MVC</code> 转换到<code>Flux</code>的动机，同时分享我们目前积累到的经验。
我尝试通过讨论代码来描述我们大部分的 <code>Flux</code> 实现， 它用于我们今天的产品中。 如果你只对综合结果感兴趣， 请跳过这篇文章的中间部分。
为了引入我们的决定， 我想要先谈一谈 <code>PlanGrid</code> 这个应用遇到的一些挑战。一些问题仅针对企业级应用程序，其他应该适用于大部分的 <code>iOS</code> 应用程序。
<code>PlanGrid</code> 是一个相当复杂的 <code>iOS</code> 应用程序。它允许用户能看到（设计）蓝图并且可以使用不同类型的（标记) 注释，问题和附件（和很多其他特定工业需要的知识）。
一个重要的方面是， 这个应用程序（可以）先离线使用。无论是否有英特网连接，用户可以使用所有应用程序提供的特性。这意味着我们需要在客户端存储许多数据和状态。我们也需要实施一些本地的业务规则（例如，一个注释是否可以被用户删除？）。
<code>PlanGrid</code> 可以在 <code>iPad</code> 和 <code>iPhone</code> 平台上运行，但他的 <code>UI</code> 被优化过，可以充分使用平板的屏幕。这意味着不像其他<code>iPhone</code> 应用程序，我们常常同时展现多个视图控制器。这些视图控制器常常（互相）共享着相当多的状态。
所有的这些意味着，我们的应用程序花在状态管理上费了很多努力。任何应用程序结果的变化或多或少都和以下几点相关：
更新本地对象的状态。
更新 <code>UI</code>。
更新数据库。
用队列保存变化，它将在有网络连接的情况下发送给服务器。
当状态改变时，通知其他对象
尽管我计划在之后的文章中（更新）包含我们新架构中其他的部分，我今天想把精力集中在第5个. 我们怎么在应用程序中构成状态更新（机制）？
这是我们应用程序开发中至关重要的问题（价值十亿美元
）。
大多数 <code>iOS</code> 的工程师，包括 <code>PlanGrid</code> 应用程序早些时候的开发者们，想出了以下答案：
代理机制 (<code>Delegation</code>)
键值观察策略 （<code>KVO</code>）
通知中心 （<code>NSNotificationCenter</code>）
回调代码块 （<code>Callback Blocks</code>）
使用数据库作为来源 （<code>Using the DB as source of truth</code>）
所有这些实现都在不同的情况下有效。然而，这些不同的操作是来源于很多在由发展多年以来的很大的代码库中的不一致。
经典的 <code>MVC</code> 只提倡分离数据和它的展示层。在缺少其他结构性的指导下，剩下的东西都由个别开发者们决定。
很长一段时间 <code>PlanGrid</code> 应用程序（像其他 <code>iOS</code> 应用程序）都没有一个定义好的模式去管理状态。
很多现存的状态管理工具，例如 <code>delegation</code> 和 <code>blocks</code> 常常去在组件中创建强连接（依赖），这并不令人满意 - 两个视图控制器迅速变得强耦合，在尝试互相分享更新的状态时。
其他工具，例如，<code>KVO</code> 和 <code>通知</code>， 创建无形的（程序）依赖。将他们使用在大型的代码库中，会迅速导致代码的变化，引起不可预期的副作用。对于一个控制器来说，想观察到那些本不需要关心的数据模型层的细节实在是太容易了。
完整的代码审阅和样式指导的作用有限，许多架构上的问题都从很小的不一致性开始并且花很长的时间扩展到许多严重的问题。使用意义清晰明确的模式替换，这将会很容易尽早发现差异。
在重构 <code>PlanGrid</code> 应用程序期间，我们最重要的目标是，采用一个清晰的模式和（创造）最佳实现方式。这样允许未来的新特性能以更加一致的方式写入代码库，也让更多新进的工程师提高工作效率。
在我们的应用程序中，状态管理是复杂度比较大的代码源之一，所以我们决定去定义一个模式，所有新的特性都会按照这个模式更好的前进。
在遭遇了很多我们代码中的痛苦后，更加让我们相信，那些 <code>Facebook</code> (脸书) 在第一次提出 <code>Flux</code> 模式是偶提出的问题：
不可预见性，联级状态更新
很难在（多个）组件中明白（互相）依赖关系
复杂的信息流程
不清晰的真实来源
看上去 <code>Flux</code> 将会非常适合解决很多我们现在遇到的问题。
这个模式能被下图很好的诠释，它展示了不同的 <code>Flux</code> 组件：
在 <code>Flux</code> 架构中，<code>store</code> 是应用程序某一个部分的单一真实来源。无论 <code>store</code> 中的状态何时更新，它都将发送一个变更事件给所有订阅这个 <code>store</code> （通知/消息）的视图。
状态更新（事件）只会通过 <code>actions</code> 产生。
一个 <code>action</code> 描述了一个预期的状态的变化，但它不自己实现状态的改变。所有想要改变状态的组件，都要发送一个 <code>action</code>给全局的 <code>dispatcher</code>。每当一个 <code>action</code> 被分发，所有有关系的 <code>store</code> 都会收到它。
作为对 <code>actions</code> 的响应，<code>stores</code> 会更新他们的状态并且通知和这些视图有关这个新的状态。
在上图显示了，<code>Flux</code> 架构实施的一个单向的数据流。它对以下几个点严格区分：
视图只会从 <code>stores</code> 接收数据。每当 <code>store</code> 更新的时候，在视图上的处理方法会被调用。
视图只会通过分发的 <code>actions</code> 改变状态。 因为 <code>actions</code> 只描述意图，业务逻辑从视图里隐去了。
<code>store</code> 只会更新它的状态，当它接收到 <code>action</code>的时候。
这些限制使得设计，开发和调试一些新的特性变得更加容易。
我们在 <code>PlanGrid iOS</code> 应用程序上的实现和 <code>Flux</code> （官方提供的）参考程序有些不同。我们为每一个 <code>store</code> 实施了一个看得见的 <code>state</code> 属性。不像原生的 <code>Flux</code> 实现方式，当 <code>store</code> 有更新的时候，我们不发送变更通知。而是视图观察 <code>store</code> 中的<code>state</code> 属性。每当视图观察到 <code>state</code> 属性有变化，他们按照下图响应（变化）:
对于 <code>Flux</code> 参考程序仅有细微的差别，但是提到这个有助于下来部分（的理解）。
有了对 <code>Flux</code> 架构的基本认识，让我们看看更多实现的细节，和一些当在 <code>PlanGrid</code> 应用程序中实现 <code>Flux</code> 架构，我们需要去回答的问题。
（去定义）每一个 <code>store</code> 的作用域是一个非常又去的问题，每当使用 <code>Flux</code> 模式的时候会经常发生。
由于 <code>Facebook</code> (脸书) 发布了 <code>Flux</code> 模式，不同的社区开发出了不同的版本。有一个叫做 <code>Redux</code>，通过迭代 <code>Flux</code> 实施了每一个应用程序应该只有一个 <code>store</code>。这个 <code>store</code> 存储了整个应用程序的状态（有很多其他，细微，不同的其他作用域的文章。）
<code>Redux</code> 很受大众欢迎，因为这个单个 <code>store</code> 的实现方式将大大简化很多应用程序的架构。在传统的 <code>Flux</code>，有多个<code>stores</code>，应用程序将会遭遇这个情况，当他们需要结合的状态，它被存储在了一个其他的 <code>store</code>中，为了去渲染某一个视图。这个实现常常重现 <code>Flux</code> 模式尝试去解决的问题，例如在应用程序中多个组件的复杂依赖。
对 <code>PlanGird</code> 来说，我们决定使用传统 <code>Flux</code> 而非使用 <code>Redux</code>。我们不确定怎么将单个 <code>store</code> 存储整个应用程序的状态实现到这个庞大的应用程序中。未来，我们认为，我们将使用非常少的内部存储依赖，让 <code>Redux</code> 作为一个可选项来说变得不那么重要了。
我们已经总结出一个硬性规定有关单独 <code>store</code> 的作用域。
目前，在我们的代码库中，我能识别出的两个模式:
特性／视图特定的存储: 每一个视图控制器（或者每一个相关联的视图控制器）收到它自己的 <code>store</code>。这个 <code>store</code> 模仿了视图独特的状态。
共享状态的 <code>stores</code>: 我们有 <code>stores</code> 存储和管理状态，被很多视图共享。我们尝试保持这些 <code>stores</code> 很小的数量。<code>IssueStore</code> 就是一个这样的一个 <code>store</code>。它负责管理所有问题，在当前选中的设计蓝图中可见的状态。这些形式的 <code>stores</code> 本质上来说一个实时更新的数据库查询。
我们目前在实现我们第一个_共享形状态 stores_ 的过程中，并且正在决定基于这些 <code>stores</code> 类型，模拟不同视图依赖最好的方式。
让我们深入观察下构成 <code>Flux</code> 模式特性的细节。
作为贯穿下几个部分的例子，我们将使用 <code>PlanGrid</code> 应用程序产品中的一个特性。这个特性允许用户过滤设计蓝图中的注释:
我们讨论的特性是截图上左边展示出的弹出框。
一般来说，我实现一个特性，都由通过决定与其相关的状态开始。这个状态展示了 <code>UI</code> 需要了解的所有东西，为了渲染某一个特性。
让我们深入我们的例子，看看过滤注释特性的状态
这个状态有一揽子的过滤器, 一个当前选择的过滤器组和一个布尔值标记，显示了过滤器是否是活动的。
这个状态为 <code>UI</code> 需求定做。这一揽子过滤器用表视图渲染。这个被选择的过滤器组用于显示／隐藏每一个单独的过滤器组的细节。<code>isFiltering</code>标记被用于决定去消除所有过滤器的按钮是否被在 <code>UI</code> 中启用和关闭。
在决定了某一个特性状态的模型之后，我常常在下一步考虑不同的状态变换。在 <code>Flux</code> 架构中，状态的变换以 <code>actions</code> 形式模拟，描述了什么样的改变是预期的。对于注释过滤器特性，这一揽子 <code>actions</code> 很段:
甚至没有一个对这个特性深入认识，它也是能被理解的，状态由 <code>action</code> 来转换。众多 <code>Flux</code> 架构中的一个好处是，这个<code>actions</code> 的列表是一个所有状态改变的全方位的概述，它能被触发用于这个特别的特性。
我们在这一步中实现这个特性的核心业务逻辑。我个人想使用 <code>TDD</code> 开发方式，我将在之后讨论。这个 <code>store</code> 能用以下内容总结:
用 <code>dispatcher</code> 注册对所有 <code>actions</code> 感兴趣的 <code>store</code>。当前的例子中，它是所有的 <code>AnnotationFilteringActions</code>。
实现一个处理函数，它将被每一个单独的 <code>actions</code> 调用。
在这个处理函数中，执行必要的业务逻辑和在完成后更新状态。
最为一个例子，我们能看一下 <code>AnnotationFilterStore</code> 怎么处理 <code>toggleFilterAction</code>。
这个例子并不是那么简单。所以让我们一点一点分解。每当 <code>ToggleFilterAction</code> 被分发的时候，<code>handleToggleFilterAction</code> 就被调用。<code>ToggleFilterAction</code> 携带了哪个具体的过滤器需要被切换的消息。
作为一个实现这个业务逻辑的开端，这个方法简单地通过切换 <code>filter.enabled</code> 这个值来切换过滤器。
之后，我们对这个特性，实现了一些定制化的业务逻辑。当配合使用那些过滤有问题的注释的过滤器的时候，我们需要去激活<code>issueTypeFilter</code>。没有必要深入讨论这个 <code>PlanGrid</code> 特有的特性，但是这个方法封装了一些和开关触发器有关的业务逻辑。
在这个方法的结尾，我们调用 <code>_applyFilter()</code> 方法。这是一个共享方法，它被很多 <code>action</code> 处理函数中使用:
调用 <code>self._annotationFilterService.applyFilter()</code> 真正触发了注释过滤器在页面上显示。过滤器的逻辑本身是有点复杂的，所以把它移动一个独立的，专门的类型中。
每一个 <code>store</code> 的角色是提供状态信息，它与相关的 <code>UI</code> 和成为关联点为了状态的更新。这并不意味着整个业务逻辑需要被实现在 <code>store</code> 本身。
每一个 <code>action</code> 处理函数最后一步是更新状态。在 <code>_applyFilter()</code> 方法中，我们正在更新 <code>isFiltering</code> 状态值通过检查是否任何过滤器正在被激活。
还有一个需要注意的事情是有关这个特别的 <code>store</code>: 你可能期望看到一个外部的状态更新，去更新过滤器的值，它存储在<code>AnnotationFilterState</code>。一般来说，这是我们如何去实现我们的 <code>stores</code>的方式，但是这个实现方式有一点特别。
由于存在 <code>AnnotationFilterState</code> 中的过滤器需要与很多现存的 <code>Objective-C</code> 代码交互，我们决定将他们模型成类。这意味着他们是引用类型并且 <code>store</code> 和注释过滤器 <code>UI</code> 共享一个对同一个实例的引用。反过来意味着在<code>store</code>内所有发生在过滤器上的变化，也对 <code>UI</code> 是可见的。一般来说，我们尝试避免这个，通过只在我们的状态结构中使用值类型 - 但是这篇文章是有关真实世界的 <code>Flux</code> 并且在这个特别的例子中，为了让 <code>Objective-C</code> 交互更容易被接受而妥协。
如果过滤器是值类型，我们需要对更新过的过滤器的值赋值到我们的状态属性，为了让 <code>UI</code> 观察到这个变化。由于我们在这里使用了引用类型，我们执行一个幽灵状态更新：
这个对 <code>_state</code> 属性赋值的任务将会开启更新 <code>UI</code> 的策略 - 一会我们将讨论这个过程的细节。
我们已经深入足够了解实现的细节了，所以我想暂告这一个部分，并提醒有关高层次 <code>store</code> 的责任:
用 <code>dispatcher</code> 注册 <code>store</code>，对所有 <code>actions</code> 感兴趣的。在当前的例子中，它就是 <code>AnnotationFilterActions</code>。
实现一个处理函数，它将会被每个单独的 <code>actions</code> 调用。
在这个处理函数中，执行必要的业务逻辑并且在完成后更新状态。
让我们移步到讨论 <code>UI</code> 怎么接收到来自 <code>store</code> 的状态更新。
每当一个状态更新（的事件）发生， 自动更新 <code>UI</code> 的机制就被触发, 这是 <code>Flux</code> 的一个核心理念。它保证了 <code>UI</code> 始终显示最新的状态，并且可以摆脱一直需要（手动地）维护这些代码的工作。这一步类似于在 <code>MVVM</code> 架构中，将一个视图绑定到<code>ViewModel</code>。
有很多中方式实现这个 - 我们决定在 <code>PlanGrid</code>中，使用 <code>ReactiveCocoa</code> 使得 <code>store</code> 提供一个可见的 <code>state</code> 属性。下面就是 <code>AnnotationFilterStore</code> 怎么去实现这个模式的方法:
<code>_state</code> 属性被用于在 <code>store</code> 内改变状态。<code>state</code> 属性被客户端使用于订阅 <code>store</code> 的消息。这允许 <code>store</code> 信息的订阅者们接收到状态的更新，但是并不允许他们直接改变状态。(状态的改变只能通过 <code>actions</code> 发生!)。
在初始化中，内部可被观察的属性仅仅简单的绑定到外部信号发生器:
现在，任何 <code>_state</code> 的更新将会自动将最新的状态值通过信号发生器发送给并且存储在 <code>state</code> 中。
仅剩下的就是通过代码确认，每当一个新的 <code>state</code> 值被发出，<code>UI</code> 都更新了。这算得上当开始在 <code>iOS</code> 上使用 <code>Flux</code> 模式最复杂的部分之一了。在网页上，<code>Flux</code> 能很好的和 <code>Facebook</code> (脸书) 的 <code>React</code> 框架配合。<code>Recat</code> 是为处理以下特性场景而设计的:
当配合 <code>UIKit</code> 时，我们没有这个至宝，相反我们需要自己手工实现 <code>UI</code> 的更新。我不能在这篇文章里深入讨论这个实现的细节，否则这篇文章将会太冗长。我们的底线是为 <code>UITableView</code> 和 <code>UICollectionView</code> 创建一些类似于 <code>React API</code> 提供的调用接口，我们将在之后的文章里提到他们。
让我们再看看实际的代码 (我们摘选了部分代码)，从注释过滤器这个特性中。这段代码存在于<code>AnnotationFilterViewController</code> 中:
我们在代码库中遵循着一个准则，每一个视图控制器都有一个 <code>_bind</code> 方法，它被 <code>viewWillAppear</code> 调用。这个 <code>_bind</code> 方法负责订阅 <code>store</code> 的状态并且提供当状态变化发生时候，提供更新 <code>UI</code> 的代码。
由于我们需要我们自己实现部分 <code>UI</code> 更新的代码并且不能依靠类似 <code>React</code> 的框架，这个方法，一般来说，需要包含描述一个特定的状态更新如何映射到 <code>UI</code> 更新的代码。<code>ReactiveCocoa</code> 是非常便利的，因为它提供了很多操作 (<code>skipUntil</code>，<code>take</code>，<code>map</code>，其他。)，很容易就能创建这些关系。如果你之前没有使用过 <code>Reactive</code> 的库，这些代码可能会让你感到困惑 - 这一小部分的 <code>ReactiveCocoa</code> 代码学起来很快。
在例子中的第一行 <code>_bind</code> 方法确保了，每当一个状态发生更新的时候，表视图能获得这个更新。我们使用 <code>ReactiveCocoa</code> 中<code>ignoreNil()</code> 操作符，来确保我们不会为一个空状态启动了更新。之后，我们使用 <code>map</code> 操作符将最新的状态从 <code>store</code> 中映射到表述图应该变成什么样的描述符。
这个映射通过 <code>annotationFilterViewProvider.tableViewModelForState</code> 方法发生。这也是我们自定义的类似 <code>React</code> 的<code>UIKit</code> 包装器参与作用的地方。
我不会深入讨论所有的实现细节，但是 <code>tableViewModelForState</code> 方法看上去是这样的:
这个方法的结果，之后绑定到视图控制器的 <code>tableViewDataSource</code> 属性。存储在这个属性中的组件，会负责基于<code>FluxTableViewModel</code> 提供的信息来更新 <code>UITableView</code>。
其他的绑定代码会比较容易，比如，负责基于 <code>isFiltering</code> 状态来开启/关闭 <code>Clear Filter</code> 的按钮。
实现 <code>UI</code> 绑定的过程是比较复杂的部分之一，由于它不能与 <code>UIKit</code> 的编程模型完美配合。但它只需要花一点精力写出一些自定义的组件，就能简单些。从我们的经验来看，我们通过实现这些自定义组件节省了很多研发时间，而不是一定要保持经典的<code>MVC</code> 实现方式，在那些在多个视图控制器需要重复实现 <code>UI</code> 更新的地方。
有了这些 <code>UI</code> 的绑定方法，我们讨论实现 <code>Flux</code> 特性的最后一个部分。由于我们已经掌握了很多内容，我想要快速回顾下之前的内容，在我们继续讨论如何测试这些 <code>Flux</code> 特性之前。
当实现一个 <code>Flux</code> 模式特性的时候，我们需要将工作分为以下几个部分:
定义状态类型的形状。
定义 <code>actions</code>。
实现业务逻辑和针对每个 <code>action</code> 状态的转变 - 这个实现在 <code>store</code> 中。
实现 <code>UI</code> 绑定方法，将状态映射到视图展示层。
这些已经包括了所有我们讨论过的有关实现的细节。
让我们继续讨论如何测试 <code>Flux</code> 特性。
有一个 <code>Flux</code> 主要的好处是，它把有关的内容严格的区分开。这让测试业务逻辑和大块的 <code>UI</code> 代码变得非常容易。
每一个 <code>Flux</code> 特性都有两个重要的区域需要被测试:
在 <code>store</code> 中的业务逻辑
视图模型的提供者 （就是那些我们实现的类似 <code>React</code> 的方法，他们基于输入的状态描述了 <code>UI</code>。）
测试 <code>stores</code> 很简单。我们能通过插入 <code>actions</code> 到 <code>stores</code> 驱动交互，并且我们能通过订阅 <code>store</code> 或者观察在我们测试用的内部 <code>_state</code> 属性来观察状态的变化。
另外，我们能模拟其他外部的类型，那些,<code>store</code> 可能需要去交互的内容，为了实现某一个特性(可能是一个 <code>API</code> 的客户端或者数据对象)并且在 <code>store</code> 的初始化器中注入这些。这允许我们去验证，那些类型是否被如期调用。
在 <code>PlanGrid</code>中，我们使用 <code>Quick</code> 和 <code>Nimble</code> 以反应样式来写测试代码。以下是一个简单的例子，来自于注释过滤器，保存某一个 <code>action</code>:
再一次强调，有关测试 <code>stores</code> 将会被放在其他文章里，所以我们也不会深入讨论过多细节。然而，测试的方式已经很清楚了。我们把 <code>actions</code> 发送给 <code>store</code>并且验证响应，以改变状态或者模拟注入代码的形式。
（你会对为什么我们在 <code>store</code> 中调用 <code>_handleActions</code>，而非使用 <code>dispatcher</code> 来分配感到好奇。起初，我们使用异步<code>dispatcher</code>，当有 <code>actions</code> 需要被分配时，这也意味着我们的测试方法也需要是异步调用的。因此，我们直接在 <code>store</code> 中直接调用处理函数。因此，这个 <code>dispatcher</code> 的实现方式也变了，所以我们在我们的测试中使用 <code>dispatcher</code>。 ）
当实现 <code>store</code> 中的业务逻辑的时候，我总会先写我的测试代码。我们的代码结构能很好的配合 <code>TDD</code> 开发过程。
<code>Flux</code> 架构结合我们申明的 <code>UI</code> 层能让测试视图变得非常容易。我们也一直在内部讨论有关我们想要覆盖(测试)多少的视图的话题。
实际上，所有我们的视图代码都是相当清晰的。它绑定了在 <code>store</code> 中的状态到我们不同 <code>UI</code> 层的属性上。对于我们的应用程序，我们决定通过 <code>UI</code> 自动测试机制来覆盖我大部分的代码。
对于我们的应用程序，我们的 <code>UI</code> 自动测试已经足够了，所以我们不需要其他的快照测试。
我们也尝试使用单元测试在我们的视图方法上（例如，早些时候我们看到的 <code>tableViewModelForState</code> 方法）。这些视图提供者，映射一个状态到 <code>UI</code> 描述符，所以他们能基于输入和返回值被很容易的测试，我发现，这些测试并不能增加很多价值，因为他们仅仅是复制了申明过的实现了的描述符。）
使用 <code>Flux</code> 架构在视图测试熵变得非常简单，因为视图的代码独立于其他的应用程序的实现。你只需要注入一些状态，他们应该被反映在你的测试中，并且他们处理的很好。
就如我们所见，的确有很多其他的方法可以测试 <code>UI</code>,我对我们（其他开发者），从长远来看，会选择哪一个很感兴趣。
在我们深入讨论了那么多的实现细节之后，我想总结下目前我们的经验和教训。
我们只使用了 <code>Flux</code> 架构 6 个月左右，但是我们已经能看到很多给我们代码库带来的好处:
新的特性能被一致性的实现。贯穿于多个特性间的，<code>stores</code> , 视图提供者和视图控制器的结构几乎保持一致（完全相同）。
通过监视状态，<code>actions</code> 和 <code>TDD</code> 的测试框架，几分钟之内，就能很容易的理解，某一个特性是怎么工作得。
我们很好的分离了 <code>stores</code> 和视图之间的关系。对于某个代码是否应该存在没有模糊的界定。
我们的代码阅读起来很简单。状态和视图之间的以来关系总是非常明确。这也让调试工作轻松愉快。
所有以上的优点，都让新来的开发者门更容易上手工做。
显而易见，我们也遇到了一些痛点:
首先，集成 <code>UIKit</code> 组件有一点麻烦。不像 <code>React</code> 组件， <code>UIKit</code> 视图不提供 <code>API</code> 基于一个新的状态容易的更新自己。这部分的工作完全依赖与我们自己，我们需要实现手动绑定视图的工作或者自定义的组件，对 <code>UIKit</code> 二次开发。
我们需要想出一个在大型应用程序中共享状态的好的模式，(如文章一开始讨论的，"什么是 <code>Store</code> 的作用域？")。我们需要在原版的 <code>Flux</code> 架构中，增加 <code>stores</code> 之间的依赖关系么？ 我们还有其他选择么？
还有很多，很多的实现细节，优点和缺点，我想我会在之后的文章里深入讨论他们。
至此，我对目前的选择很满意，并且我希望这篇文章能给你们一些参考，是否 <code>Flux</code> 架构也对你适合。
最后，如果你对 <code>Flux</code> 在 <code>Swift</code> 上的实现感兴趣，或只想为我们的产品贡献一份你的力量共同成就一个巨大的产业。
<b>原文发布时间为：2016年07月28日</b>
<b>本文来自云栖社区合作伙伴掘金，了解相关信息可以关注掘金网站。</b>