iOS APP架构

作者：小萝卜
链接：https://zhuanlan.zhihu.com/p/37360635
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

前言

<noscript> image

</noscript>

image

<figcaption>网络系统架构</figcaption>

<noscript> image

</noscript>

image

<figcaption>IOS系统架构</figcaption>

任何系统任何程序都有自己的架构，为解决复杂的网络系统，根据不同的功能不同的复杂度设计OSI7层结构，IOS系统同样也是。

设计模式

• MVC

<noscript> image

</noscript>

image

<figcaption>MVC元素</figcaption>

视图（View）：用户界面
控制器（Controller）：业务逻辑
模型（Model）：数据保存

<noscript> image

</noscript>

image

<figcaption>MVC架构图</figcaption>

View 传送指令到 Controller
Controller 完成业务逻辑后，要求 Model 改变状态
Model 将新的数据发送到 View，用户得到反馈

注：所有通信都是单向的。

当然MVC在实际的应用中也有很多变种，如下：

<noscript> image

</noscript>

image

<figcaption>互动模式一</figcaption>

通过 View 接受指令，传递给 Controller。

<noscript> image

</noscript>

image

<figcaption>交互模式二</figcaption>

直接通过controller接受指令。

实际的开发过程中经常会采用更灵活的方式，如下：

<noscript> image

</noscript>

image

<figcaption>实战MVC</figcaption>

用户可以向 View 发送指令，再由 View 直接要求 Model 改变状态。
用户也可以直接向 Controller 发送指令，再由 Controller 发送给 View。
Controller 非常薄，只起到路由的作用，而 View 非常厚，业务逻辑都部署在 View。

• MVP

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。

<noscript> image

</noscript>

image

<figcaption>MVP架构图</figcaption>

各部分之间的通信，都是双向的。
View 与 Model 不发生联系，都通过 Presenter 传递（项目中我们经常将其设计成Manager）。
View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter比较厚，所有的逻辑（业务逻辑和主要的UI逻辑）都部署在那里。

注：当然可以将Presenter（Manager）在做细分为业务逻辑模块和UI逻辑模块，从而进化成为MVP模式（MVVM）。

• MVVM

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。

当然有很多人会拿MVVM和MVC比较，相对于 MVC 的历史来说，MVVM 是一个相当新的架构，MVVM 最早于 2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出，并且应用在微软的软件开发中。当时 MVC 已经被提出了 20 多年了，可见两者出现的年代差别有多大。详细内容请参阅：

小萝卜：MVVM 之 Unity​zhuanlan.zhihu.com

图标 <noscript> image

</noscript>

image

<figcaption>MVVM架构图</figcaption>

唯一的区别是，它采用双向绑定（Data-Binding）和 UI逻辑与业务逻辑拆分：View的变动，自动反映在 ViewModel，反之亦然。<u>Angular</u>和<u>Ember</u>都采用这种模式。

注：MVVM 在使用当中，通常还会利用双向绑定技术（DataBinding），使得 Model 变化时，ViewModel 会自动更新，而 ViewModel 变化时，View 也会自动变化。所以，MVVM 模式有些时候又被称作：Model-View-Binder 模式。如果要在IOS中实现，可以使用 KVO 或 Notification 达到这种效果。

在架构选型的过程中甚至是在开发过程中，我发现很多程序猿童鞋对于 MVVM 以及 MVVM 衍生出来的框架（例如 ReactiveCocoa）有一种「敬畏」感。这种「敬畏」感某种程度上就像对”神“一样，可能因为主要表现在我没有听到大家对于 MVVM 的任何批评，无论是游戏项目还是应用项目。
我感觉原因首先是 MVVM 并没有很大程度上普及，大家对于新技术一般都不熟，进而不敢妄加评论。另外，ReactiveCocoa 本身上手的复杂性，也让很多人感觉到这种技术很高深难懂，进而加重了大家对它的「敬畏」。

所以我觉得MVVM还是过于被大家神化了。

我们来看看MVVM的作者 John Gossman 是怎样批评MVVM的：

数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
对于过大的项目，数据绑定需要花费更多的内存。

某种意义上来说，我认为就是数据绑定使得 MVVM 变得复杂和难用了。但是，这个缺点同时也被很多人认为是优点。（因为在游戏开发中没有这种DataBinding技术，需要自己用观察者模式设计，用起来不是很顺手，新手理解有难度）