注：【本文內容是閱讀「戴銘」老師的iOS開發高手課內容后，自己的筆記總結】

1、開發架構基本模式演變歷程

蘋果官方推薦的 App 開發模式是 MVC，隨之衍生出其他很多類 MVC 的設計模式 MVP、MVVM、MVCS ，它們在不同程度上增強了視圖、數據的通信方式，使得邏輯、視圖、數據之間的通信更靈活、規整、易于擴展。在 App 浪潮初期，幾乎所有 App 采用的都是這種類 MVC 的結構。原因在于，MVC 是很好的面向對象編程范式，非常適合個人開發或者小團隊開發。

但是，項目大了，人員多了以后，這種架構就扛不住了。接下來我們就不得不考慮模塊粒度如何劃分、如何分層，以及多團隊如何協作這三個問題了。

首先，項目規模變大后，模塊劃分必須遵循一定的原則。如果模塊劃分規則不規范、不清晰，就會導致代碼耦合嚴重的問題，并加大架構重構的難度

其次，我們需要搞清楚模塊的粒度采用什么標準進行劃分，也就是要遵循的原則是什么。對于 iOS 這種面向對象編程的開發模式來說，我們應該遵循以下五個原則，

2、即 SOLID 原則。

1>單一功能原則：對象功能要單一，不要在一個對象里添加很多功能。

2>開閉原則：擴展是開放的，修改是封閉的。

3>里氏替換原則：子類對象是可以替代基類對象的。

4>接口隔離原則：接口的用途要單一，不要在一個接口上根據不同入參實現多個功能。

5>依賴反轉原則：方法應該依賴抽象，不要依賴實例。iOS 開發就是高層業務方法依賴于協議。

最后，我們需要選擇合適的粒度。切記，大型項目的模塊粒度過大或者過小都不合適。

iOS 開發中的組件，不是 UI 的控件，也不是 ViewController 這種大 UI 和功能的集合。因為，UI 控件的粒度太小，而頁面的粒度又太大。iOS 組件，應該是包含 UI 控件、相關多個小功能的合集，是一種粒度適中的模塊。

3、功能模塊之間的耦合解除，就需要重新梳理組件之間的邏輯關系，進行改造。

但是，組件解耦并不是說要求每個組件間都沒有耦合，組件間也需要有上下層依賴的關系。組件間的上下層關系劃分清楚了，就會容易維護和管理。而對于組件間如何分層這個問題，層級最多不要超過三個。

你可以這么設置：?

1> 底層可以是與業務無關的基礎組件，比如 網絡、存儲、通用彈框、加密、字符處理、數組擴展、字典擴展等等；

2>中間層一般是通用的業務組件，比如 賬號、埋點、支付、購物車等項目中公共業務等；

3>最上層是 「迭代業務」組件，更新頻率最高。

這樣的三層結構，尤其有利于多個團隊分別開發維護。比如，一開始有兩個業務團隊 A 和 B，他們在開發時既有通用的功能、賬號、埋點、個人頁等，也有專有的業務功能模塊，每個功能都是一個組件。也不用把所有的功能都做成組件，只有那些會「?被多個業務或者團隊」使用的功能模塊才需要做成組件。

4、組件化是解決項目大、人員多的一種很好的手段，這在任何公司或團隊都是沒有歧義的。組件間關系協調卻沒有固定的標準，協調的優劣，成為了衡量架構優劣的一個基本標準。所以在實踐中，一般分為了「協議式」和「中間者」 兩種架構設計方案。

「協議式架構」設計主要采用的是協議式編程的思路：在編譯層面使用協議定義規范，實現可在不同地方，從而達到分布管理和維護組件的目的。這種方式也遵循了依賴反轉原則，是一種很好的面向對象編程的實踐。

但是，這個方案的缺點也很明顯，主要體現在以下兩個方面：

1>由于協議式編程?缺少統一調度層，導致難于集中管理，特別是項目規模變大、團隊變多的情況下，架構管控就會顯得越來越重要。

2>協議式編程接口定義模式過于規范，從而使得架構的靈活性不夠高。當需要引入一個新的設計模式來開發時，我們就會發現很難融入到當前架構中，缺乏架構的統一性。

雖然協議式架構有這兩方面的局限性，但由于其簡單易用的特點依然被很多公司采用。

另一種常用的架構形式是「中間者架構」。它采用 ?中間者統一管理的方式，來控制 App 的整個生命周期中組件間的調用關系。同時，iOS 對于組件接口的設計也需要保持一致性，方便中間者統一調用。拆分的組件都會依賴于中間者，但是組間之間就不存在相互依賴的關系了。

中間者架構的易管控帶來的架構更穩固，易擴展帶來的靈活性，所以我認為中間者這種架構設計模式是非常值得推薦的。casatwy 以前設計了一個 CTMediator 就是按照中間者架構思路設計的。你可以在GitHub上看到它的內容。