本文源自本人的学习记录整理与理解，其中参考阅读了部分优秀的博客和书籍，尽量以通俗简单的语句转述。引用到的地方如有遗漏或未能一一列举原文出处还望见谅与指出，另文章内容如有不妥之处还望指教，万分感谢 ！
何为架构 ？
架构即Architecture, 是软件开发中的设计方案；
它可大可小，小到类与类之间的关系、模块与模块之间的关系；
大到客户端与服务端之间的关系; 这些都可以认为是一种架构设计方案
经常听到的架构名词
-
MVC、MVP、MVVM、VIPER、CDD -
三层架构、四层架构等等
Apple官方的MVC设计
M：数据模型 V: 视图View C: 控制器
- 控制器可以创建View，并显示出来
- View内部的事件响应可以交给控制器来处理，比如按钮的点击事件
- 控制器可以通过发出网络请求或从数据库缓存中获取数据，数据发生了改变控制器是可以知道的；会拿到View的属性控件把数据赋值给它显示
- 控制器相当于是数据和视图之间的桥梁；数据模型和View是互相不知道的
这种设计方案最经典案例：UITableView、UICollectionView
优点:
View和Model解耦，可重用
View不依赖数据模型，可以拿到任何地方使用；简称万能View
Model不依赖View，可以重复利用，可以独立拿出来使用
缺点：
Controller 的代码过于臃肿，维护成本高
MVC变种
- 控制器可以创建View，并显示出来
- View内部拥有模型，View内部的事件响应可以交给控制器来处理，比如按钮的点击事件
- 控制器可以通过发出网络请求或从数据库缓存中获取数据，接下来会把模型数据传给View，有View自己负责显示模型的数据
优点：
对Controller进行瘦身，将View内部的细节封装起来了，外界不知道View内部的具体实现
缺点：
View依赖于Model，换Model可能会有点麻烦；别人要用就需要把数据变成这个Model传递
MVP
M：数据模型 V: View P: presenter 分担控制器部分业务逻辑处理
- 控制器内部拥有presenter，负责初始化presenter
- presenter专门来处理业务逻辑，可以声明一个弱指针指向控制器；presenter内部操作分三步：
- 创建View 给控制器显示
- 加载模型 ：网络请求或本地缓存
- 将模型数据给View显示
优点：
View和Model解耦 - 相互不知道，可重用
对Controller进行瘦身，部分业务逻辑处理由presenter实现; 同时Controller可以拥有多个presenter切换
缺点：
代码量会比普通的MVC要大
MVVM
和MVP相似，最大不同在于MVVM是通过属性监听绑定的方式相互协作
M ：数据模型 V: View VM: 处理绑定和显示
- 控制器内部拥有VM，负责初始化VM
- VM专门来业务逻辑，可以声明一个弱指针指向控制器；VM内部操作分三步：
- 创建View给控制器显示，View也声明一个指针指向VM,即View拥有VM，并监听VM属性
model的改变(facebook推出的FBKVOController)
QQ20200421-123214.png
当然还有一个RAC框架可以做到，不过该框架内容比较多；需要花一些时间 - 加载模型 ：网络请求或本地缓存
- 设置数据 ：把获取到的数据赋值给自己的属性模型
优点：
View和Model解耦 - 相互不知道，可重用
对Controller进行瘦身，部分业务逻辑处理由VM实现，同时Controller可以拥有多个VM切换
缺点：
代码量会比普通的MVC要大
分层架构
比较成熟的有三层架构和四层架构
分层的基本思路：
一般来说是把项目中的所有类，不管是控制器、View、model、工具类等对它们采用分层的设计，每层只需要专注自己的事情不需要关系其他层怎么做
三层架构设计：应用层、业务层、数据层
应用层：界面相关的如：控制器、View控件， MVC、MVP、MVVM都是属于该范畴
业务层：处理业务逻辑，比如商城应用的购物车业务、结算业务
数据层：网络请求获取数据、本地数据库
四层架构设计：应用层、业务层、网络层、本地数据层
应用层：界面相关的如：控制器、View控件，MVC、MVP、MVVM都是属于这个范畴
业务层：处理业务逻辑，比如商城应用的购物车业务、结算业务
网络层：网络请求获取数据
本地数据层：本地数据库
不管三层架构还是四层架构也好主要的还是依托项目的业务，做出合适的选择，没有最好只有只有最合适 ！
组件化架构
组件化要求：不能出现横向依赖，不能出现反向依赖；
当出现横向依赖时考虑把组件下沉，以保证能够实现解耦合；即编程原则中的依赖倒置原则
反向依赖: 下层不能依赖上层，上层可以依赖下层；这是单向的依赖；即编程原则中的迪米特原则
随着移动互联网的不断发展，很多程序代码量和业务越来越多，现有架构已经不适合公司业务的发展速度了，很多都面临着重构的问题。
在公司项目开发中，如果项目比较小，普通的单工程+MVC架构就可以满足大多数需求了。但是像淘宝、蘑菇街、微信这样的大型项目，原有的单工程架构就不足以满足架构需求了。
就拿淘宝来说，淘宝在13年开启的“All in 无线”战略中，就将阿里系大多数业务都加入到手机淘宝中，使客户端出现了业务的爆发。在这种情况下，单工程架构则已经远远不能满足现有业务需求了。所以在这种情况下，淘宝在13年开启了插件化架构的重构，后来在14年迎来了手机淘宝有史以来最大规模的重构，将其彻底重构为组件化架构。
将每个模块作为一个组件并且建立一个主项目，这个主项目负责集成所有组件；这样的方式被称为组件化 ！
进行组件化开发后，可以把每个组件当做一个独立的app，每个组件甚至可以采取不同的架构，例如分别使用MVVM、MVC、MVCS等架构。
当下组件化大多是基于CocoaPods实现组件化架构，利用中间件来完成组件之间通信，在CocoaPods中可以通过podfile很好的配置各个组件，包括组件的增加和删除，以及控制某个组件的版本。使用CocoaPods的原因，很大程度是为了解决大型项目中，代码管理工具merge代码导致的冲突。并且可以通过配置podfile文件，轻松配置项目。
注意：在组件化架构是需要进行分层的，这其中有分层架构的思想在里面；层这个概念是用来区分组件的职能的，在项目越做越大的过程中分层的思想就变得非常重要；不然大家会把一个项目理解成一团麻，没有清晰的划分对未来的扩展和优化非常不利；
架构和设计模式的关系
设计模式即 Design Pattern,是一套被反复使用、代码设计经验的总结；使用设计模式的好处是：可重用代码、让代码更容易被他人理解、保证代码可靠性；一般与编程语言无关，是一套比较成熟的编程思想
- 和架构相比概念上会小一些，设计模式是策略，架构模式是战略
设计模式可以被分为三大类: 创建型模式、结构型模式、行为型模式
创建型模式：对象实例化的模式，用于解耦随想的实例化过程； 常见的有：单利模式、工厂模式等
结构型模式：把类或对象结合在一起形成一个更大的结构；常见的有：代理模式、适配器模式、组合模式、装饰模式等
行为型模式：类或对象之间如何交互，及划分责任和算法；常见的有：观察者模式、命令模式、责任链模式、订阅者模式等
以上设计模式OC用到的不是很多，像java语言的设计模式就有23种；
推荐
数据结构与算法 严蔚敏，《数据结构》
大话数据结构与算法 提取码: f2ux
网络
HTTP权威指南电子书 提取码: bsji
《TCP/IP详解卷1：协议》：买第一本就好
TCP/IP详解卷1、2、3 电子书 提取码: 35ei
架构与设计模式
