iOS应用架构介绍
什么是建筑？ 这个词实际上是什么意思？ 如果您查看字典，则有两个主要定义。
设计或建造建筑物的艺术或实践
事物的复杂或精心设计的结构。
第一个定义是我们大多数人最熟悉的定义，它是设计建筑物（或任何其他类型的结构）。 例如，在实际建造房屋之前，您必须设计房屋的建造方式。 您必须设计外观，工作方式，哪些门将通向哪些房间，支撑梁将在何处等等。
这引出了第二个定义： 事物的复杂或精心设计的结构。 这采用了与以前相同的想法，并在更广泛的意义上应用了它。 这是经过精心设计的事物结构。 我们在这里要谈论的是软件 。
令人难以置信的是，没有蓝图，没有任何计划或设计的人就会开始盖房子。 显然，在开始建造房屋之前，您需要考虑周全，设计合理的蓝图，该蓝图应遵循标准的行业模式。 造成这种情况的众多原因之一是，在房屋建造（或中途建造）之后，即使不是不可能，也很难回去改变房屋的基本结构。 另外，如果您没有蓝图或设计，我只能想象房子的一塌糊涂，到处都是矛盾和惊奇。
同样适用于软件。 我们应该设计系统，以便对将要拥有的高级结构，它们之间的关系以及每个结构的输入/输出有一个想法。 这将使我们的系统易于推理和理解。 不可避免地会发生软件系统的变化，因此，如果我们拥有可靠的体系结构，则更改软件系统的特定模块应该很简单，而不必更改整体的高级结构。
软件体系结构是关于做出基本的结构选择，一旦实施，更改成本很高。
那么，这一切如何适用于iOS应用程序？ 因此，让我们从基础开始。 如果不谈论模型视图控制器（MVC），就无法谈论iOS体系结构。
MVC于70年代在Xeroc Parc发明，最初出现在编程语言Smalltalk-80中。 这是一个非常简单的体系结构，它将软件系统中的所有对象分为三个存储区。 这些可能会有所不同，具体取决于您正在使用的域，但是对于iOS，可以这样描述：
- 模型 ：涉及存储数据，传输数据以及数据本身的任何事物。
- 视图：任何在屏幕上显示内容并处理用户输入的用户可见对象。
- 控制器：模型与视图之间的中介者。 控制器更新模型，然后模型通知控制器有新数据。 然后控制器更新视图，并且视图发送所有用户操作
在iOS中无法绕过MVC。 可以显示在屏幕上的UIView的所有子类都是您的视图，控制控件并拥有这些UIView的UIViewController的所有子类都是控制器。 基本上，其他所有东西都是模型。 因此，从某种意义上说，MVC是苹果公司处理iOS / macOS / tvOS / watchOS应用程序体系结构的“官方”方式。
如果最后一段中的内容听起来有些不对劲，则可能是您遇到了一些麻烦。 在许多情况下，“ 基本上所有其他一切都是模型 ”这句话是正确的。 至少在一个简单的应用程序中，其他对象将是数据模型，数据库或服务器/ API访问对象，而这些是模型。 但是，这里存在MVC的问题。 假设一切都将是Model或View或Controller太简单了，就是这样。 没有其他责任的对象。
这就是其他体系结构的用武之地。我不认为其他任何体系结构都可以竞争取代MVC，因为正如我之前所说，MVC是构建Apple软件的“唯一”方法，因为那是Cocoa框架的方法。被设计。 我认为这些体系结构是扩展/重新设计/重命名/改进MVC的一种方法，可以正确解决复杂的现代应用程序可能具有的所有对象。
我无法提及存在于iOS开发中的所有体系结构，因为随着人们探索和设计构建iOS应用程序的新方法，这在社区中发生了变化。 但是，我将简要介绍的那些是我认为最重要的，并且可以用作构建和设计我们自己的体系结构的基础。
Model-View-ViewModel是iOS社区中最常见的MVC后架构之一。 它最初是由Microsoft在2005年创造的，用于其Silveright软件。
从技术上讲，其含义可能会因您的领域或技术而异。 但是在iOS世界中，它基本上是MVC的扩展。 模型仍然是模型。 View仍然是View， 但是现在它也包含在View伞内的控制器（UIViewController子类），因为无论如何它都紧密地结合在一起。 最后，它引入了一个新概念ViewModel。
可以将ViewModel视为对控制器概念的改进。 它是Model和View之间的中介。 您可以认为这基本上是将MVC中的控制器部分分为两部分。 一个是UIViewController子类，它们现在属于View内部，另一个是ViewModel。
这似乎是一个非常简单的更改，但功能却非常强大。 它使ViewController极其简单，因为现在他们只需要担心控制UIView并对事件做出反应，并且所有复杂的业务逻辑现在都包含在ViewModel中。 这使我们的ViewModel与Apple框架脱钩，并使它们更易于测试。
FlowCoordinators或通常被称为Coordinator的也是一个简单的概念。 通常在我们的iOS应用中，ViewController会处理导航。 我的意思是，当用户单击我们应用程序中的按钮时，ViewController（或者更糟的情节提要！）负责决定下一步应该发生什么，我需要实例化哪个ViewController并呈现或推送到导航堆栈。
在一个简单的应用程序中这可能没问题。 但这使复杂的应用程序中的代码真正耦合在一起，并使ViewController的确很难重用。 这个想法是将所有高级导航逻辑上移到协调器中。 这使得ViewController的可重用性更高，因为它们只需要通知协调器发生了什么事情，并且他们就没有任何其他责任。
然后，协调器负责知道要实例化哪个ViewController，呈现或推送它们，以及注入控制器可能需要的任何依赖项。 最后一点是使用协调器的最大好处之一。 在不使用协调器的情况下，传递依赖项（这是推荐做法！）很麻烦。 这导致不得不将依赖项传递给多个控制器，只是为了将其传递给需要它的控制器。 或者，在某些情况下甚至更糟，不得不使用（或滥用）Singleton。
VIPER是目前最完整的iOS体系结构之一。 与其仅关注体系结构的特定部分或问题，不如从头开始创建一个全新的体系结构。 我之前没有使用过VIPER，不是因为我不喜欢它，而是因为我认为架构您的iOS应用程序应该更像是一门艺术，并且应该为您的应用程序的特定需求而构建，而VIPER如此完善以至于它确实没有空间让您创建自己的空间。
VIPER是整个程序包，我个人更喜欢创建适合您的应用程序的自定义体系结构的方法，显然，它基于其他体系结构并从其他体系结构中借鉴而来。 这就是为什么我认为提及VIPER并对其进行阅读很重要，因为它是一个完整的体系结构外观的很好的例子。 如您所见，VIPER的大多数部分已经以不同的名称存在于其他体系结构中。 因此，这是一个非常有用的示例，可以了解有关iOS体系结构的更多信息。
VIPER分为以下几个部分：
- 视图 ：我们认识并喜欢的视图。
- 交互器 ：您的应用程序可以具有的所有不同业务逻辑模块。 （类似于ViewModel）
- 演示者 ：准备显示内容。 与View和Interactor进行交互。 （也类似于ViewModel）
- 实体 ：普通数据模型对象。 （模型）
- 路由 ：显示屏幕和导航的逻辑。 （类似于协调员）
本文的目的是对iOS应用程序体系结构，它为什么重要的高层次介绍，并在那里介绍不同体系结构的一些基本概念。 这绝不是本主题的全部内容，我建议您以此作为本主题的入门，并继续学习。 我将在下面提供一些链接。
本文还旨在作为我撰写的一系列体系结构博客文章的介绍，详细介绍了自己对MVVM-C （模型-视图-视图模型-协调器）体系结构的实现。 这显然不是我发明的体系结构，而是存在的，但是我认为分享自己正在使用的大型生产应用程序中使用的特定实现很有趣。
没有关于iOS体系结构的通用指南，因此我们在iOS社区中可以依靠的是来自其他开发人员的博客文章和示例代码，以了解有关此主题的更多信息，因此，这是我的贡献。
资料来源，进一步阅读