iOS之深入解析App的架构设计

Posted 2021-08-23 Forever_wj

一、概述

① 应用架构

• App 架构是软件设计的一个分支，它关心的是如何设计一个 App 的结构。具体来说，它关注于两个方面：如何将 App 分解为不同的接口和概念层次部件，以及这些部件之间和自身的不同操作中 所使用的控制流和数据流路径。
• 通常使用简单的框图来解释 App 的架构，比如，Apple 的 MVC 模式可以通过 model、 view 和 controller 三层结构来描述，如下所示：

• 在一个 MVC 项目中，绝大部分的代码都会集中其中的某个层级上。但这种简单的框图几乎无法解释在实践中模式的操作方式，这是因为在实际的 App 架构中， 部件的构建有非常多的可能性。比如说：事件流在层中穿梭的方式是什么？部件之间是否应该在编译期间或者运行时持有对方？要怎么读取和修改不同部件中的数据？以及状态的变更应该以哪条路径在 App 中进行？

② Model 和 View

• 在最高的层级上，App 架构其实就是一套分类，不同的部件会被归纳到某个类型中去，科技将这些不同的种类叫做层次。一个层次指的是遵循一些基本规则并负责特定 功能的接口和其他代码的集合。
• Model 层是 App 的内容，它不依赖于 (像 UIKit 那样的) 任何 App 框架，也就是说，程序员对 model 层有完全的控制。Model 层通常包括 model 对象 (在录音 App 中的例子是文件夹和录音对象) 和协调对象 (比如 App 中的负责在磁盘上存储数据的 Store 类型)。被存储在磁盘上的那部分 model 称之为文档 model (documentation model)。
• View 层是依赖于 App 框架的部分，它使 model 层可⻅，并允许用戶进行交互，从而将 model 层转变为一个 App。当创建 ios 应用时，view 层几乎总是直接使用 UIKit。不过，也会看到在有些架构中，会使用 UIKit 的封装来实现不同的 view 层。另外，对一些其他的像是游戏类的自定义应用，view 层可以不是 UIKit 或者 AppKit，它可能是 SceneKit 或者 OpenGL 的某种封装。
• 有时候，选择使用结构体或者枚举来表示 model 或者 view 的实例，而不使用类的对象。 在实践中，类型之间的区别非常重要，但是当在 model 层中谈到对象、结构体和枚举时， 会将三者统一地称为 model 对象。类似地，也会把 view 层的实例叫做 view 对象，实际上它们也可能是对象、结构体或者枚举。
• View 对象通常会构成一个单一的 view 层级，在这个层级中，所有的 view 对象通过树结构的方 式连接起来。在树的根部是整个屏幕，屏幕中存在若干窗口，接下来在树的分支和叶子上是更多的小 view。类似地，view controller 也通常会形成 view controller 层级。不过，model 对象却不需要有明确的层级关系，在程序中它们可以是互不关联的独立 model。
• 当提到 view 时，通常指的是像一个按钮或者一个文本 label 这样的单一 view 对象。当提到 model 时，通常指的也是像一个 Recording 实例或者 Folder 实例这样的单个 model 对象。在该话题的大多数文献中，model 在不同上下文中指的可能是不同的事情。它可以指代一个 model 层，model 层中的具体的若干对象，文档 model，或者是 model 层中不关联的文档。
• 定义一个 model 层的最重要的理由是，它为程序提供一个表述事实的单一来源，这会让逻辑清晰，行为正确，我们的程序便不会被应用框架中的实现细节所支配。如果 model 层能做到和应用框架分离，就可以完全在 App 的范围之外使用它。我们可以很容易地在另外的测试套件中运行它，或者用一个完全不同的应用框架重写新的 view 层，那么这个 model 层将能够用于 android，macOS 或者 Windows 版本的 App 中。

③ App 的本质是反馈回路

• View 层和 model 层需要交流，因此两者之间需要存在连接。假设 view 层和 model 层是被清晰地分开，而且不存在无法解耦的联结的话，两者之间的通讯需要如下所示：

• 从根本上说，用戶界面是一个同时负责展示和输入功能的反馈设备，所以毫无疑问，这导致的结果就是一个反馈回路，每个 App 设计模式所面临的挑战是如何处理上图中的箭头所包含的 交流，依赖和变换。
• 在 model 层和 view 层之间不同的路径拥有不同的名称：
• • 用戶发起的事件会导致 view 的响应， 把由此引起的代码路径称为 view action，像是点击按钮或者选中 table view 中的某一行就属于 view action。
• • 当一个 view action 被送到 model 层时，它会被转变为 model action (或者说，让 model 对象执行一个 action 或者进行更新的命令)，这种命令也被叫做一个消息 (特别 在当 model 是被 reducer 改变时)。
• • 将 view action 转变为 model action 的操作，以及路径上的其它逻辑被叫做交互逻辑。
• 一个或者多个 model 对象上状态的改变叫做 model 变更。Model 的变更通常会触发一个 model 通知，比如说从 model 层发出一个可观测的通知，它描述 model 层中什么内容发生了改变。当 view 依赖于 model 数据时，通知会触发一个 view 变更，来更改 view 层中的内容，这些通知可以以多种形式存在：Foundation 中的 Notification、代理、回调、或者是其他机制， 都是可以的。将 model 通知和数据转变为 view 更改的操作，以及路径上的其他逻辑被叫做表现逻辑。
• 根据 App 模式的不同，有些状态可能是在文档 model 之外进行维护的，这样一来，更新这些状 态的行为就不会追随文档 model 的路径。在很多模式中的导航状态就这种行为的一个常⻅例 子，在 view 层级中的某个部分 (或者按照 Cocoa Storyboard 中使用的术语，将它称为 scene) 可能会被换出或者换入层级中。
• 在 App 中非文档 model 的状态被叫做 view state。在 Cocoa 里，大部分 view 对象都管理着它 们自己的 view state，controller 对象则管理剩余的 view state。在 Cocoa view state 的框图 中，通常会有加在反馈回路上的捷径，或者单个层自身进行循环。在有一些架构中，view state 不属于 controller 层，而是属于 model 层的部分 (不过，根据定义，view controller 并不是文 档 model 的一部分)。
• 当所有的状态都在 model 层中被维护，而且所有的变更都通过完整的反馈回路路径进行传递时，就将它称为单向数据流。当任意的 view 对象或者中间层对象只能够通过 model 发出的通知来进行创建和更新 (换句话说，view 或者中间层不能通过捷径来更新自身或者其他的 view) 时，这个模式通常就是单向的。

④ 架构技术

• Apple 平台的标准 Cocoa 框架提供了一些架构工具：
• • Notification 将值从单一源广播给若干个收听者；
• • 键值观察 (KVO) 可以将某个对象上属性的改变报告给另一个对象。
• 使用到的第三方技术中可能包含了响应式编程，响应式编程也是一种用来交流变更的工具， 不过和通知或者 KVO 不同的是，它专注于在源和目标之间进行变形，让逻辑可以在部件之间传输信息的同时得以表达。
• 可以使用像是响应式编程或者 KVO 这样的技术创建属性绑定。绑定接受一个源和一个目 标，无论何时，只要源发生了变化，目标也将被更新。这和手动进行观察在语法上有着不同， 不再需要写观察的逻辑，而只需要指定源和目标，接下来框架将会处理其余部分的 工作。
• macOS 上的 Cocoa 包含有 Cocoa 绑定技术，它是一种双向绑定，所有的可观察对象同时也是 观察者，在一个方向上建立绑定连接，会在反方向也创建一个连接。不论是 RxCocoa，还是 CwlViews，都不是双向绑定的。

⑤ App 任务

• 要让程序正常工作，view 必须依赖于 model 数据来生成和存在，配置 view，让它可以对model 进行更改，并且能在 model 更新时也得到更新。 所以，需要决定在 app 中如何执行下列任务：
• • 构建—谁负责构建 model 和 view，以及将两者连接起来？
• • 更新 model，如何处理 viewaction？
• • 改变 view，如何将 model 的数据应用到 view 上去？
• • viewstate 如何处理导航和其他一些 modelstate 以外的状态？
• • 测试为达到一定程度的测试覆盖，要采取怎样的测试策略?

二、常用的设计模式

① Model-View-Controller

• 标准的 CocoaModel-View-Controller(MVC) 是 Apple 在示例项目中所采用的设计模式。它是 Cocoa App 中最为常⻅的架构，同时也是在 Cocoa 中讨论架构时所采用的基准线。
• 在 Cocoa MVC 中，一部分 controller 对象负责处理 model 或者 view 层范畴之外的所有任务。这意味着，controller 层接收所有的 view action，处理所有的交互逻辑，发送所有的 model action，接收所有的 model 通知，对所有用来展示的数据进行准备，最后再将它们应用到 view 的变更上去。
• 在上文中的 App 反馈回路的图，会发现在 model 和 view 之间的箭头上，几乎每个标签都是 controller，而且要知道，上图中的构建和导航任务并没有标注出来，它们也会由 controller 来处理。
• 下面是 MVC 模式的框图，它展示了一个 MVC App 的主要通讯路径：

• 图中的虚线部分代表运行时的引用，view 层和 model 层都不会直接在代码中引用 controller。 实线部分代表编译期间的引用，controller 实例知道自己所连接的 view 和 model 对象的接口。
• 如果在这个图标外部描上边界的话，就得到了一个 MVC 版本的 App 反馈回路。注意：在图表中其他的路径并不参与整个反馈回路的路径 (也就是 view 层和 controller 层上那些指向自身的箭头)。
• 构建
• • App 对象负责创建最顶层的 view controller，这个 view controller 将加载 view，并且知道应 该从 model 中获取哪些数据，然后把它们显示出来。
• • Controller 要么显式地创建和持有 model 层，要么通过一个延迟创建的 model 单例来获取 model。
• • 在多文档配置中，model 层由更低层 的像是 UIDocument 或 NSDocument 所拥有。那些和 view 相关的单个 model 对象，通常会 被 controller 所引用并缓存下来。
• 更改 Model
• • 在 MVC 中，controller 主要通过 target/action 机制和 (由 storyboard 或者代码进行设置的) delegate 来接收 view 事件。
• • Controller 知道自己所连接的 view，但是 view 在编译期间却没有 关于 controller 接口的信息。
• • 当一个 view 事件到达时，controller 有能力改变自身的内部状态， 更改 model，或者直接改变 view 层级。
• 更改 View
• • 在所理解的 MVC 中，当一个更改 model 的 view action 发生时，controller 不应该直接去 操作 view 层级。正确的做法是，controller 去订阅 model 通知，并且在当通知到达时再更改 view 层级。
• • 这样一来，数据流就可以单向进行:view action 被转变为 model 变更，然后 model 发送通知，这个通知最后被转为 view 变更。
• View State
• • View state 可以按需要被 store 在 view 或者 controller 的属性中。相对于影响 model 的 view action，那些只影响 view 或 controller 状态的 action 则不需要通过 model 进行传递。
• • 对于 view state 的存储，可以结合使用 storyboard 和 UIStateRestoring 来进行实现，storyboard 负责记录活跃的 controller 层级，而 UIStateRestoring 负责从 controller 和 view 中读取数据。
• 测试
• • 在 MVC 中，view controller 与 app 的其他部件紧密相连，边界的缺失使得为 controller 编写单元测试和接口测试十分困难，集成测试是余下的为数不多的可行测试手段之一。
• • 在集成测试中，构建相连接的 view、model 和 controller 层，然后操作 model 或者 view，来测试是 否能得到我们想要的结果。集成测试的书写非常复杂，而且它涵盖的范围太广了。它不仅仅测试逻辑，也测试部件是如何 连接的 (虽然在一些情况下和 UI 测试的⻆度并不相同)。
• • 不过，在 MVC 中通过集成测试，通常达到 80% 左右的测试覆盖率是有可能的。
• MVC 的重要性：因为 Apple 在所有的实例项目中都使用了这种模式，加上 Cocoa 本身就是针对这种模式设计的，所以 Cocoa MVC 成为了 iOS、macOS、tvOS 和 watchOS 上官方认证的 App 架构模式。

② Model-View-ViewModel + 协调器

• MVVM 和 MVC 类似，也是通过基于场景 (scene，view 层级中可能会在导航发生改变时切入或者换出的子树) 进行的架构。相较于 MVC，MVVM 在每个场景中使用 view-model 来描述场景中的表现逻辑和交互逻辑。
• View-model 在编译期间不包含对 view 或者 controller 的引用，它暴露出一系列属性，用来描述每个 view 在显示时应有的值，把一系列变换运用到底层的 model 对象后，就能得到这些最终可以直接设置到 view 上的值。
• 实际将这些值设置到 view 上的工作，则由预先建立的绑定来完成，绑定会保证当这些显示值发生变化时，把它设定到对应的 view 上去。响应式编程是用来表达这类声明和变换关系的很好的工具，所以它天生就适合 (虽说不是严格必要) 被用来处理 view-model。在很多时候，整个 view-model 都可以用响应式编程绑定的方式，以声明式的形式进行表达。
• 在理论上，因为 view-model 不包含对 view 层的引用，所以它是独立于 App 框架的，这让对于 view-model 的测试也可以独立于 App 框架。由于 view-model 是和场景耦合的，还需要一个能够在场景间切换时提供逻辑的对象，在 MVVM-C 中，这个对象叫做协调器 (coordinator)。协调器持有对 model 层的引用，并且了解 view controller 树的结构，这样，它能够为每个场景的 view-model 提供所需要的 model 对象。
• 和 MVC 不同，MVVM-C 中的 view controller 从来都不会直接引用其他的 view controller (因此也不会引用其他的 view-model)。View controller 通过 delegate 的机制，将 view action 的信息告诉协调器。协调器据此显示新的 view controller 并设置它们的 model 数据。换句话 说，view controller 的层级是由协调器进行管理的，而不是由 view controller 来决定的。
• 这些特性所形成的架构的总体结构如下图所示：

• 如果忽略掉协调器，那么这张图表就很像 MVC 了，只不过在 view controller 和 model 之间加入了一个阶段。MVVM 将之前在 view controller 中的大部分工作转移到了 view-model 中，但是要注意，view-model 并不会在编译时拥有对 view controller 的引用。
• View-model 可以从 view controller 和 view 中独立出来，也可以被单独测试。同样，view controller 也不再拥有内部的 view state，这些状态也被移动到了 view-model 中。在 MVC 中 view controller 的双重⻆色 (既作为 view 层级的一部分，又负责协调 view 和 model 之间的交互)，减少到了单一⻆色 (view controller 仅仅只是 view 层级的一部分)。
• 协调器模式的加入进一步减少了 view controller 所负责的部分：现在它不需要关心如何展示其它的 view controller 了。因此，这实际上是以添加了一层 controller 接口为代价，降低了 view controller 之间的耦合。
• 构建
• • 对于 model 的创建和 MVC 中的保持不变，通常它是一个顶层 controller 的职责。不过，单独的 model 对象现在属于 view-model，而不属于 view controller。初始的 view 层级的创建和 MVC 中的一样，通过 storyboard 或者代码来完成。
• • 和 MVC 不同的是，view controller 不再直接为每个 view 获取和准备数据，它会把这项工作交给 view-model。 View controller 在创建的时候会一并创建 view-model，并且将每个 view 绑定到 view-model 所暴露出的相应属性上去。
• 更改 Model
• • 在 MVVM 中，view controller 接收 view 事件的方式和 MVC 中一样 (在 view 和 view controller 之间建立连接的方式也相同)。
• • 不过，当一个 view 事件到达时，view controller 不会去改变自身的内部状态、view state、或者是 model。相对地，它立即调用 view-model 上的方 法，再由 view-model 改变内部状态或者 model。
• 更改 View
• • 和 MVC 不同，view controller 不监听 model，View-model 将负责观察 model，并将 model 的通知转变为 view controller 可以理解的形式。
• • View controller 订阅 view-model 的变更，这通常通过一个响应式编程框架来完成，但也可以使用任意其他的观察机制。当一个 view-model 事件来到时，由 view controller 去更改 view 层级。
• • 为了实现单向数据流，view-model 总是应该将变更 model 的 view action 发送给 model，并 且仅仅在 model 变化实际发生之后再通知相关的观察者。View State
    View state 要么存在于 view 自身之中，要么存在于 view-model 里。
• • 和 MVC 不同，view controller 中不存在任何 view state。View-model 中的 view state 的变更，会被 controller 观 察到，不过 controller 无法区分 model 的通知和 view state 变更的通知。当使用协调器时， view controller 层级将由协调器进行管理。
• 测试
• • 因为 view-model 和 view 层与 controller 层是解耦合的，所以可以使用接口测试来测试 view-model，而不需要像 MVC 里那样使用集成测试。接口测试要比集成测试简单得多，因为 不需要为它们建立完整的组件层次结构。
• • 为了让接口测试尽可能覆盖更多的范围，view controller 应当尽可能简单，但是那些没有被移出 view controller 的部分仍然需要单独进行测试。在实现中，这部分内容包括与协调器的交互，以及初始时负责创建工作的代码。
• MVVM 是 iOS 上最流行的 MVC 的非直接变形的 App 设计模式。换言之，它和 MVC 相比，并没有非常大的不同，两者都是围绕 view controller 场景构建的，而且所使用的机制也大都相同。
• 最大的区别可能在于 view-model 中对响应式编程的使用，它被用来描述一系列的转换和依赖关系。通过使用响应式编程来清晰地描述 model 对象与显示值之间的关系，为我们从总体上 理解应用中的依赖关系提供了重要的指导。
• iOS 中的协调器是一种很有用的模式，因为管理 view controller 层级是一件非常重要的事情。协调器在本质上并没有和 MVVM 绑定，它也能被使用在 MVC 或者其他模式上。

③ Model-View-Controller + ViewState

• MVC+VS 是为标准的 MVC 带来单向数据流方式的一种尝试。在标准的 Cocoa MVC 中，view state 可以由两到三种不同的路径进行操作，MVC+VS 则试图避免这点，让 view state 的处理更加易于管理。在 MVC+VS 中，明确地在一个新的 model 对象中，对所有的 view state 进行定义和表达，把这个对象叫做 view state model。
• 在 MVC+VS 中，不会忽略任何一次导航变更，列表选择，文本框编辑，开关变更，model 展示或者滚动位置变更 (或者其他任意的 view state 变化)，我们将这些变更发送给 view state model。每个 view controller 负责监听 view state model，这样变更的通讯会非常直接，在表现或者交互逻辑部分，不从 view 中去读取 view state ，而是从 view state model 中去获取它们：

• 结果所得到的图表和 MVC 类似，但 controller 的内部反馈回路的部分 (被用来更新 view state) 有所不同，现在它和 model 的回路类似，形成了一个独立的 view state 回路。
• 构建：和传统的 MVC 一样，将文档 model 数据应用到 view 上的工作依然是 view controller 的责任， view controller 还会使用和订阅 view state 。因为 view state model 和文档 model 都需要观察，所以相比于典型的 MVC 来说，需要多得多的通过通知进行观察的函数。
• 更改 Model：当 view action 发生时，view controller 去变更文档 model (这和 MVC 保持不变) 或者变更 model state，不会去直接改变 view 层级，所有的 view 变更都要通过文档 model 和 view state model 的通知来进行。
• 更改 View：Controller 同时对文档 model 和 view state model 进行观察，并且只在变更发生的时候更新 view 层级。
• View State：View State 被明确地从 view controller 中提取出来，处理的方法和 model 是一样的：controller 观察 view state model，并且对应地更改 view 层级。
• 测试：
• • 在 MVC+VS 中，使用和 MVC 里类似的集成测试，但是测试本身会非常不同。所有的测试都从一个空的根 view controller 开始，然后通过设定文档 model 和 view state model，这个根 view controller 可以构建出整个 view 层级和 view controller 层级。MVC 的集成测试中最困 难的部分 (设定所有的部件) 在 MVC+VS 中可以被自动完成。
• • 要测试另一个 view state 时，我 们可以重新设置全局 view state，所有的 view controller 都会调整自身。
• • 一旦 view 层级被构建，可以编写两种测试：第一种测试负责检查 view 层级是不是按照期望被建立起来，第二种测试检查 view action 有没有正确地改变 view state。
• MVC+VS 主要是用来对 view state 进行教学的工具，在一个非标准 MVC 的 App 中，添加一个 view state model，并且在每个 view controller 中 (在已经对 model 进行观察的基础上) 观察这些 view state model，提供了不少优点：任意的状态恢复 (这种恢复不依赖于 storyboard 或者 UIStateRestoration)，完整的用戶界面日志，以及为了调试目的，在不同的 view state 间进行跳转的能力。

④ Model 适配器-View 绑定器 (MAVB)

• MAVB 是一种以绑定为中心的实验模式，在这个模式中，有三个重要的概念：view 绑定器， model 适配器，以及绑定。
• View 绑定器是 view (或者 view controller) 的封装类：它构建 view，并且为它暴露出一个绑定列表，一些绑定为 view 提供数据 (比如，一个标签的文本)，另一些从 view 中发出事件 (比如， 按钮点击或者导航变更)。
• 虽然 view 绑定器可以含有动态绑定，但是 view 绑定器本身是不可变的，这让 MAVB 也成为了一种声明式的模式：声明 view 绑定器和它们的 action，而不是随着时间去改变 view 绑定器。
• Model 适配器是可变状态的封装，它是由所谓的 reducer 进行实现的。Model 适配器提供了一个 (用于发送事件的) 输入绑定，以及一个 (用于接收更新的) 输出绑定。
• 在 MAVB 中，不会去直接创建 view，相对地，只会去创建 view 绑定器。同样地，也从 来不会去处理 model 适配器以外的可变状态。在 view 绑定器和 model 适配器之间的 (两个方 向上的) 变换，是通过 (使用标准的响应式编程技术) 来对绑定进行变形而完成的。
• MAVB 移除了对 controller 层的需求，创建逻辑通过 view 绑定器来表达，变换逻辑通过绑定来表达，而状态变更则通过 model 适配器来表达。结果得到的框图如下：

• 构建：
• • Model 适配器 (用来封装主 model ) 和 view state 适配器 (封装顶层的 view state) 通常是在 main.swift 文件中进行创建的，这早于任何的 view。
• • View 绑定器使用普通的函数进行构建，这些函数接受必要的 model 适配器作为参数。实际的Cocoa view 则由框架负责进行创建。
• 更改 Model：
• • 当一个 view (或者 view controller) 可以发出 action 时，对应的 view 绑定允许指定一个 action 绑定，在这里，数据从 view 流向 action 绑定的输出端。
• • 典型情况下，输出端会与一个 model 适配器相连接，view 事件会通过绑定进行变形，成为 model 适配器可以理解的一条消息，这条消息随后被 model 适配器的 reducer 使用，并改变状态。
• 更改 View：当 model 适配器的状态发生改变时，它会通过输出信号产生通知。在 view 绑定器中，可以将 model 适配器的输出信号进行变形，并将它绑定到一个 view 属性上去。这样一来，view 属性就会在一个通知被发送时自动进行变更。
• View State：View state 被认为是 model 层的一部分。View state action 以及 view state 通知和 model action 以及 model 通知享有同样的路径。
• 测试：
• • 在 MAVB 中，通过测试 view 绑定器来测试代码。由于 view 绑定器是一组绑定的列表，可以验证绑定包含所期望的条目，而且它们的配置正确无误，可以和使用绑定来测试初始构建以及发生变化时的情况。
• • 在 MAVB 中进行的测试，与在 MVVM 中的测试很相似。不过，在 MVVM 中，view controller 有可能会包含逻辑，这导致在 view-model 和 view 之间有可能会存在没有测试到的代码。而 MAVB 中不存在 view controller，绑定代码是 model 适配器和 view 绑定器之间的唯一的代码， 这样一来，保证完整的测试覆盖要简单得多。

⑤ Elm 架构 (TEA)

• TEA 和 MVC 有着根本上的不同，在 TEA 中，model 和所有的 view state 被集成为一个单个状 态对象，所有 App 中的变化都通过向状态对象发送消息来发生，一个叫做 reducer 的状态更新 函数负责处理这些消息。
• 在 TEA 中，每个状态的改变会生成一个新的虚拟 view 层级，它由轻量级的结构体组成，描述 了 view 层级应该看上去的形式。虚拟 view 层级能够使用纯函数的方式来写 view 部分的代码，虚拟 view 层级总是直接从状态进行计算，中间不会有任何副作用。当状态发生改变时，使用同样的函数重新计算 view 层级，而不是直接去改变 view 层级。
• Driver 类型 (这是 TEA 框架中的一部分，它负责持有对 TEA 中其他层的引用) 将对虚拟 view 层级和 UIView 层级进行比较，并且对它进行必要的更改，让 view 和它们的虚拟版本相符合。这个 TEA 框架中的 driver (驱动) 部件是随着 App 的启动而被初始化的，它自身并不知道要对应哪个特定的 App。要在它的初始化方法中传入这些信息：包括 App 的初始状态，一个通过消息更新状态的函数，一个根据给定状态渲染虚拟 view 层级的函数，以及一个根据给定状态计算通知订阅的函数 (比如，可以订阅某个 model store 更改时所发出的通知)。
• 从框架的使用者的视⻆来看，TEA 的关于更改部分的框图是这样的：

• 如果追踪这张图表的上面两层，会发现在 view 和 model 之间存在在本文开头是就说过的反馈回路，这是一个从 view 到状态，然后再返回 view 的回路 (通过 TEA 框架进行协调)。
• 上面的回路代表的是 TEA 中处理副作用的方式 (比如将数据写入磁盘中)：当在状态更新方法中处理消息时，可以返回一个命令，这些命令会被 driver 所执行。在上面的例子中，最重要的命令是更改 store 中的内容，store 反过来又被 driver 所持有的订阅者监听，这些订阅者可以触发消息来改变状态，状态最终触发 view 的重新渲染作为响应。
• 构建：状态在启动时被构建，并传递给运行时系统 (也就是 driver)。运行时系统拥有状态，store 是一个单例。初始的 view 层级和之后更新时的 view 层级是通过同样的路径构建的:通过当前的状态，计算 出虚拟 view 层级，运行时系统负责更新真实的 view 层级，让它与虚拟 view 层级相匹配。
• 更改 Model：虚拟 view 拥有与它们所关联的消息，这些消息在一个 view 事件发生时会被发送。Driver 可以接收这些消息，并使用更新方法来改变状态。更新方法可以返回一个命令 (副作用)，比如想在 store 中进行的改动，Driver 会截获该命令并执行它，TEA 让 view 不可能直接对状态或者 store 进行更改。
• 更改 View：运行时系统负责这件事，改变 view 的唯一方式是改变状态。所以，初始化创建 view 层级和更新 view 层级之间没有区别。
• View State：View state 是包含在整体的状态之中的，由于 view 是直接从状态中计算出来的，导航和交互状态也同样会被自动更新。
• 测试：
• • 在大多数架构中，让测试部件彼此相连往往要花费大量努力。在 TEA 中，不需要对此进行 测试，因为 driver 会自动处理这部分内容。类似地，不需要测试当状态变化时 view 会正确 随之变化，所需要测试的仅仅是对于给定的状态，虚拟 view 层级可以被正确计算。
• • 要测试状态的变更，可以创建一个给定的状态，然后使用 update 方法和对应的消息来改 变状态，然后通过对比之前和之后的状态，就可以验证 update 是否对给定的状态和消息返回了所期望的结果。
• • 在 TEA 中，还可以测试对应给定状态的订阅是不是正确。和 view 层级一样，update 函数和订阅也都是纯函数。
• • 因为所有的部件 (计算虚拟 view 层级，更新函数和订阅) 都是纯函数，可以对它们进行完全隔离的测试。任何框架部件的初始化都是不需要的，只用将参数传递进去，然后验证结果就行。

三、其他架构模式

① Model-View-Presenter

• Model-View-Presenter (MVP) 是一种在 Android 上很流行的模式，在 iOS 中，也有相应的实现。在总体结构和使用的技术上，它粗略来说是一种位于标准 MVC 和 MVVM 之间的模式。
• MVP 使用单独的 presenter 对象，它和 MVVM 中 view-model 所扮演的⻆色一样。相对 view-model 而言，presenter 去除了响应式编程的部分，而是把要展示的值暴露为接口上的属 性。不过，每当这些值需要变更的时候，presenter 会立即将它们推送到下面的 view 中去 (view 将自己作为协议暴露给 presenter)。
• 从抽象的观点来看，MVP 和 MVC 很像。Cocoa 的 MVC，除了名字以外，就是一个 MVP， 它是从上世纪九十年代 Taligent 的原始的 MVP 实现中派生出来的 View，状态和关联的逻辑在两个模式中都是一样的。不同之处在于，现代的 MVP 中有一个分离的 presenter 实体，它使用协议来在 presenter 和 view controller 之间进行界定，Cocoa 的 MVC 让 controller 能够直接引用 view，而 MVP 中的 presenter 只能知道 view 的协议。
• 有些开发者认为协议的分离对于测试是必要的。当在讨论测试时，会看到标准的 MVC 在没有任何分离的情况下，也可以被完整测试，所以感觉 MVP 并没有太大不同。如果对测试一个完全解耦的展示层有强烈需求的话，认为 MVVM 的方式更简单一些，让 view controller 通过观察去从 view-model 中拉取值，而不是让 presenter 将值推送到一个协议中去。

② VIPER，Riblets，和其他 “Clean” 架构

• VIPER，Riblets 和其他类似的模式尝试将 Robert Martin 的 “Clean Architecture” 从 web app 带到 iOS 开发中，它们主要把 controller 的职责分散到三到四个不同的类中，并用严格的顺序将它们排列起来，在序列中的每个类都不允许直接引用序列中前面的类。
• 为了强制单方向的引用这一规则，这些模式需要非常多的协议和类，以及在不同层中传递数据的方式。由于这个原因，很多使用这些模式的开发者会去使用代码生成器。我们的感觉是，这些代码生成器，以及任何的繁杂到需要生成器的模式，都产生了一些误导，将 “Clean” 架构带 到 Cocoa 的尝试通常都宣称它们可以管理 view controller 的 “肥大化” 问题，但这么做往往让代码库变得更大。
• 虽然将接口分解是控制代码尺寸的一种有效手段，但是我们认为这应该按需进行，而不是教条式地对每个 view controller 都这么操作。分解接口需要我们对数据以及所涉及到的任务有清楚 的认识，只有这样，我们才能达到最优的抽象，并在最大程度上降低代码的复杂度。

③ 基于组件的架构 (React Native)

• 如果选择使用 javascript 而不是 Swift 编程，或者 App 重度依赖于 web API 的交互， JavaScript 会是更好的选择，这时可能会考虑 React Native。
• 如果想要找一些类似 React Native，但是是基于 Swift 的东西的话，可以看看对 TEA 的探索。MAVB 的实现也从 ComponentKit 中获得了一些启发，而 ComponentKit 本身又从 React 中获取灵感：它使用类 DSL 的语法来进行声明式和可变形的 view 构建，这和 React 中 Component 的 render 方法及其相似。