使用ReSwift管理应用状态

前面提到引入App Coordinator之后，ViewController的剩下的职责之一就是“接收数据并把数据绑定到对应的子UIView展示”，这儿的数据来源就是应用的状态。它山之石，可以攻玉，不只是iOS应用有复杂状态管理的问题，在越来越多的逻辑往前端迁移的时代，所有的前端都面临着类似的问题，而目前Web前端最火的Redux就是为了解决这个问题诞生的状态管理机制，而ReSwift则把这套机制带入了iOS的世界。这套机制中主要有一下几个概念：
App State: 在一个时间点上，应用的所有状态. 只要App State一样，应用的展现就是一样的。

Store: 保存App State的对象，其还负责发送Action更新App State.

Action: 表示一次改变应用状态的行为，其本身可以携带用以改变App State的数据。

Reducer: 一个接收当前App State和Action，返回新的App State的小函数。

在这个机制下, 一个App的状态转换如下：
启动初始化App State -> 初始化UI，并把它绑定到对应的App State的属性上

业务操作 -> 产生Action -> Reducer接收Action和当前App State产生新的AppState -> 更新当前State -> 通知UI AppState有更新 -> UI显示新的状态 -> 下一个业务操作......

在这个状态转换的过程中，需要注意，业务操作会有两类：
无异步调用的操作，如点击界面把界面数据存储到App State上；这类操作处理起来非常简单，按照上面提到的状态转换流程走一圈即可。

有异步调用的操作。如点击查询，调用API，数据返回之后再存储到App State上。这类操作就需要引入一个新的逻辑概念（Action Creators)来处理，通过Action Creators来处理异步调用并分发新的Action。

整个App的状态变换过程如下：

无异步调用操作的状态流转

统一管理应用状态，包括统一的机制和唯一的状态容器，这让应用状态的改变更容易预测，也更容易调试。

清晰的逻辑拆分，清晰的代码组织方式，让团队的协作更加容易。

函数式的编程方式，每个组件都只做一件小事并且是独立的小函数，这增加了应用的可测试性。

单向数据流，数据驱动UI的编程方式。

整理后的iOS架构

经过上面的大篇幅介绍，下面我们就来归纳下结合了App Coordinator和ReSwift的一个iOS App的整体架构图：

架构实战

上面已经讲解了整体的架构原理，"Talk is cheap"， 接下来就以Raywendlich上面的这个App为例来看看如何实践这个架构。

该ViewController需要的数据及该数据的格式？

该ViewController需要支持哪些业务操作？

以第一个页面为例：

class SearchSceneViewController: BaseViewController {      //定义业务操作的接口    
    var searchSceneCoordinator:SearchSceneCoordinatorProtocol?      //子组件      var searchView:SearchView?  //该UI接收的数据结构      private func update(state: AppState) {            if let searchCriteria = state.property.searchCriter   {                searchView?.update(searchCriteria: searchCriteria)        }    }      //支持的业务操作      func searchByCity(searchCriteria:SearchCriteria) {            searchSceneCoordinator?.searchByCity(searchCriteria: searchCriteria)        }      func searchByCurrentLocation() {              searchSceneCoordinator?.searchByCurrentLocation()      }       //子组件的组织      override func viewDidLoad() {            super.viewDidLoad()            searchView = SearchView(frame: self.view.bounds)            searchView?.goButtonOnClick = self.searchByCity            searchView?.locationButtonOnClick = self.searchByCurrentLocation            self.view.addSubview(searchView!)      }}

注：子组件支持的操作都以property的形式从外部注入，组件内命名更组件化，不应包含业务含义。
其它的几个ViewController也依法炮制，完成所有UI组件，这步完成之后，我们就有了App的所有UI组件，以及UI支持的所有操作接口。下一步就是把他们串联起来，根据业务逻辑完成User Journey。
第二步：构建App Coordinators串联所有的ViewController
首先，在AppDelegate中加入AppCoordinator，把路由跳转的逻辑转移到AppCoordinator中。
var appCoordinator: AppCoordinator! func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { window = UIWindow() let rootVC = UINavigationController() window?.rootViewController = rootVC appCoordinator = AppCoordinator(rootVC) appCoordinator.start() window?.makeKeyAndVisible() return true }

然后，在AppCoordinator中实现首页SeachSceneViewController的加载
class AppCoordinator { var rootVC: UINavigationController init(_ rootVC: UINavigationController){ self.rootVC = rootVC } func start() { let searchVC = SearchSceneViewController(); let searchSceneCoordinator = SearchSceneCoordinator(self.rootVC) searchVC.searchSceneCoordinator = searchSceneCoordinator self.rootVC.pushViewController(searchVC, animated: true) }}

在上一步中我们已经为每个ViewController定义好对应的CoordinatorProtocol，也会在这一步中实现
protocol SearchSceneCoordinatorProtocol { func searchByCity(searchCriteria:SearchCriteria) func searchByCurrentLocation()}class SearchSceneCoordinator: AppCoordinator, SearchSceneCoordinatorProtocol { func searchByCity(searchCriteria:SearchCriteria) { self.pushSearchResultViewController() } func searchByCurrentLocation() { self.pushSearchResultViewController() } private func pushSearchResultViewController() { let searchResultVC = SearchResultSceneViewController(); let searchResultCoordinator = SearchResultsSceneCoordinator(self.rootVC) searchResultVC.searchResultCoordinator = searchResultCoordinator self.rootVC.pushViewController(searchResultVC, animated: true) }}

以同样的方式完成SearchResultSceneCoordinator. 从上面的的代码中可以看出，我们跳转逻辑中只做了两件事：初始化ViewController和装配该ViewController对应的Coordinator。这步完成之后，所有UI之间就已经按照业务逻辑串联起来了。下一步就是根据业务逻辑，让用App State在UI之间流转起来。
第三步：引入ReSwift架构构建Redux风格的应用状态管理机制
首先，跟着ReSwift官方指导选取你喜欢的方式引入ReSwift框架，笔者使用的是Carthage。
定义App State

然后，需要根据业务定义出整个App的State，定义State的方式可以从业务上建模，也可以根据UI需求来建模，笔者偏向于从UI需求建模，这样的State更容易和UI进行绑定。在本例中主要的State有：
struct AppState: StateType { var property:PropertyState ...}struct PropertyState { var searchCriteria:SearchCriteria? var properties:[PropertyDetail]? var selectedProperty:Int = -1}struct SearchCriteria { let placeName:String? let centerPoint:String?}struct PropertyDetail { var title:String ...}

定义好State的模型之后，接着就需要把AppState绑定到Store上，然后直接把Store以全局变量的形式添加到AppDelegate中。
let mainStore = Store<AppState>( reducer: AppReducer(), state: nil )

把App State绑定到对应的UI上

注入之后，就可以把AppState中的属性绑定到对应的UI上了，注意，接收数据绑定应该是每个页面的顶层ViewController，其它的子View都应该只是以property的形式接收ViewController传递的值。绑定AppState需要做两件事：订阅AppState
override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) mainStore.subscribe(self) { state in state } } override func viewWillDisappear(_ animated: Bool) { super.viewWillDisappear(animated) mainStore.unsubscribe(self) }和实现StoreSubscriber的newState方法class SearchSceneViewController: StoreSubscriber { ...... override func newState(state: AppState) { self.update(state: state) super.newState(state: state) } ......}

经过绑定之后，每一次的AppState修改都会通知到ViewController，ViewController就可以根据AppState中的内容更新自己的UI了。
定义Actions和Reducers实现App State更新机制

绑定好UI和AppState之后，接下来就应该实现改变AppState的机制了，首先需要定义会改变AppState的Action们
struct UpdateSearchCriteria: Action { let searchCriteria:SearchCriteria}......

然后，在AppCoordinator中根据业务逻辑把对应的Action分发出去, 如果有异步请求，还需要使用ActionCreator来请求数据，然后再生成Action发送出去
func searchProperties(searchCriteria: SearchCriteria, _ callback:(() -> Void)?) -> ActionCreator { return { state, store in store.dispatch(UpdateSearchCriteria(searchCriteria: searchCriteria)) self.propertyApi.findProperties( searchCriteria: searchCriteria, success: { (response) in store.dispatch(UpdateProperties(response: response)) store.dispatch(EndLoading()) callback?() }, failure: { (error) in store.dispatch(EndLoading()) store.dispatch(SaveErrorMessage(errorMessage: (error?.localizedDescription)!)) } ) return StartLoading() } }

Action分发出去之后，初始化Store时注入的Reducer就会接收到相应的Action，并根据自己的业务逻辑和当前App State的状态生成一个新的App State
func propertyReducer(_ state: PropertyState?, action: Action) -> PropertyState { var state = state ?? PropertyState() switch action { case let action as UpdateSearchCriteria: state.searchCriteria = action.searchCriteria ... default: break } return state }

最终Store以Reducer生成的新App State替换掉老的App State完成了应用状态的更新。
以上三步就是一个完整的架构实践步骤，该示例的所有源代码可以在笔者的Github上找到

总结

以解决掉Massive ViewController的iOS应用架构之争持续多年，笔者也参与了公司内外的多场讨论，架构本无好坏，只是各自适应不同的上下文而已。本文中提到的架构方式使用了多种模式，它们各自解决了架构上的一些问题，但并不是一定要捆绑在一起使用，大家完全可以根据需要裁剪出自己需要的模式，希望本文中提到的架构模式能够给你带来一些启迪。