展望未来，为了简化和与Soroush保持一致，我将把这个概念称为流程协调器，或者简称为协调器。我觉得控制器一词在iOS中已经具有一定的含义，我们希望避免任何不必要的混乱。术语协调器似乎更适合这些对象的角色。

我们都已经看到（并编写了）从现有视图控制器提示或模态显示新视图控制器的代码。通常，我们创建新的视图控制器，传递它可能需要的任何数据，然后直接呈现（模式）或抓取导航控制器，并告诉其“按下”新的视图控制器。

let viewController = CustomViewController()
viewController.data = NSObject() //some data object
navigationController.show(viewController, sender: self)

通常在给定的用户流中重复此过程，其中每个先前的视图控制器配置后续的视图控制器。这带来了一些问题，例如子对象直接访问父对象，下游视图控制器所需的任何数据都需要通过所有先前的视图控制器传递，使测试变得更加复杂复杂以及是否需要在其上使用流。不同的设备类型，我们必须添加逻辑检查。协调器模式改善这些问题，替代向前控制器更容易重用，允许重用用户流，并在对象之间分离关注点。

基本概念确实非常简单，您可以将所有特定于导航的UIKit调用移至自定义对象。这些对象负责为应用程序中的每个特定流甚至子流执行导航。例如，如果您的应用程序中有一个注册流程，那么注册协调员将对此进行处理。忘记密码流程，由“忘记密码”协调员处理。还有一个初始的应用程序协调器，它将启动应用程序流并根据需要生成新的协调器，，以处理新的用户流。协调程序能够产生其他协调程序，可以更轻松地重用工作流程和协调程序。给定的协调器负责创建任何所需的视图控制器，视图模型，并通过委派来响应任何操作。

由于最初的演示文稿不包含代码示例，并且原始文章也对代码有所帮助（GitHub上有一个可以下载和查看的应用程序），所以我决定自己实施流程协调器，以更好地理解潜在的好处。复习有关该主题的大量帖子只会使问题变得更加复杂，因为不同的作者在其“协调员”中采用了不同的技术。一些人将流协调器注入到流的基本视图控制器中，而其他人则使用协议和委派，还有一些人使用块/闭包。一些作者仅使用协调器进行导航，而另一些作者则建议协调器处理网络或持久性访问（将视图控制器保留为仅显示，对象。因为我想获得基本的了解，所以我只专注于导航。最后，我决定也使用委派方法，因为这更松散地替换了控制器和协调器，并定义了清晰的界面。但是，它确实需要一些额外的样板代码，因为每个视图控制器都需要声明一个协议以委托给适当的流控制器。

为了更好地了解流程协调器在实际应用中的工作方式，我决定创建一个简单的iOS应用，该应用在用户登录后便具有注册流程和配置文件流程。配置文件流程模拟了标签栏控制器以及其他内容。当然，这是一个人为的示例，但它使我们有机会了解流程协调器如何处理导航以及自定义导航动画。

登录按钮将带您直接进入配置文件屏幕，我们在这里通过伪选项卡栏模拟多项功能。设置将以模式方式显示视图控制器，而关注者和关注者将使用自定义导航委托来过渡到为相应的视图控制器。“注册”按钮将在两个简单的屏幕之间导航，以模拟用户名，密码选择和帐户生成。为简单起见，实际上不需要任何值，并且实际上没有处理或验证任何内容。

总体上建立流程协调器并不困难。我们首先在应用程序委托中创建应用程序协调器。在这里，我们创建一个rootview控制器，并使用它初始化应用协调员，然后调用启动。

我们的第一位协调员是应用程序协调员。该协调器检查用户的登录状态，并根据结果显示登录屏幕或配置文件屏幕。屏幕和相关流程均由两个儿童协调员控制。逻辑非常简单，易于遵循。应用协调器充当其子协调器的委托，并在身份验证过程完成时接收响应，以便它可以移至下一个流程（配置文件流程）。

接下来是我们的身份验证协调器，顾名思义，改为对用户进行身份验证，或者在我们的情况下，引导我们完成伪注册过程。在此示例中，有两个屏幕依次显示，以模拟选择用户名，密码和生成帐户。身份验证协调器根据“下一步”或“创建帐户”操作处理每个后续屏幕的显示。在此流程中，我们使用标准的推导航动画。

不需要子协调器属性，因为此流不会生成任何其他流，它只需完成并通知父（应用程序协调器）即可。如果一切按计划进行，那么我们将进入配置文件协调器。此流程模拟了应用程序中具有访问其他内容（“关注者”和“关注者”以及“设置”页面）功能的基本“开始”屏幕。此流程使用自定义导航委托，以便在转换为“跟随/跟随者”前端控制器时使用自定义动画，同时将设置显示为标准模式。

同样，逻辑和实现非常简单明了，易于遵循。每个动作（“设置” /“关注者” /“关注”）均由配置文件协调器处理，以显示适当的视图控制器。定制动画师和导航代表处理所有动画方面。这样可以使所有组件保持更多且易于理解。

由于我们使用委托，因此我们将引用类型的协调器。在Swift中实现委托需要定义一个弱委托变量，而弱修饰符仅可使用类协议。我创建了一个空的基类协调器，以简化在类型数组中存储子协调器的过程。我们可以将常见的属性（例如子协调者属性和导航委托）移动到生产应用程序中的超类中。

起初，将导航流移动到单独的对象中感觉很不直观，但是一旦开始使用流协调器，您就会很快意识到其好处。流被很好地包含并与视图控制器相互隔离。您可以通过，为流替换一个不同的导航委托或将不同的动画师注入该导航委托来轻松更改给定流的动画。现在，视图控制器对应用程序的流程一无所知，并且不再负责呈现或关闭内容。减少责任是一件好事，我们使视图控制器更加整洁，更容易重用。

Soroush建议协调器也要处理模型变异，以使视图控制器保持“仅显示”对象。我喜欢在我的应用程序中使用MVVM和RxSwift。如果使用的是MVVM，则可以考虑使视图模型成为视图控制器的委托，然后将所有导航操作通过视图模型转发到协调器上。这将取决于您的实现以及在给定导航之前视图模型是否需要执行任何操作。在MVVM中，如果不直接更改模型，则首先模型负责处理模型更改的请求并大量见。

Flow协调器看起来像是另一个潜在有用的工具，可以缓解iOS应用中常见的全景视图控制器问题。

**参考作者
**如果您对此处提及的任何作者感兴趣，可以在Twitter上通过@Khanlou和@merowing（Krzysztof Zablocki）关注他们。

**来源
**Github Repo
协调器
协调器redux
使用FlowControllers改进的iOS体系结构
流量控制器