猿题库 iOS 客户端架构设计-唐巧
序
猿題庫是一個擁有數千萬用戶的創業公司，從20013年題庫項目起步到2015年，團隊保持了極高的生產效率，使我們的產品完成了五個大版本和數十個小版本的高速迭代。
在如此快速的開發過程中，如何保證代碼的質量，降低后期維護的成本，以及為項目越來越快的版本迭代速度提供支持，成為了我們關注的重要問題。這篇文章將闡明我們在猿題庫 iOS 客戶端的架構設計。
MVC
MVC，Model-View-Controller，我們從這個古老而經典的設計模式入手。采用 MVC 這個架構的最大的優點在于其概念簡單，易于理解，幾乎任何一個程序員都會有所了解，幾乎每一所計算機院校都教過相關的知識。而在 iOS 客戶端開發中，MVC 作為官方推薦的主流架構，不但 SDK 已經為我們實現好了 UIView、UIViewController 等相關的組件，更是有大量的文檔和范例供我們參考學習，可以說是一種非常通用而成熟的架構設計。
但 MVC 也有他的壞處。由于 MVC 的概念過于簡單樸素，已經越來越難以適應如今客戶端的需求，大量的代碼邏輯在 MVC 中并沒有定義得很清楚究竟應該放在什么地方，導致他們很容易就會堆積在 Controller 里，成為了人們所說的 Massive View Controller。
MVVM
MVVM，Model-View-ViewModel，一個從 MVC 模式中進化而來的設計模式，最早于2005年被微軟的 WPF 和 Silverlight 的架構師 John Gossman 提出。在 iOS 開發中實踐 MVVM 的話，通常會把大量原來放在 ViewController 里的視圖邏輯和數據邏輯移到 ViewModel 里，從而有效的減輕了 ViewController 的負擔。
另外通過分離出來的 ViewModel 獲得了更好的測試性，我們可以針對 ViewModel 來測試，解決了界面元素難于測試的問題。MVVM 通常還會和一個強大的綁定機制一同工作，一旦 ViewModel 所對應的 Model 發生變化時，ViewModel 的屬性也會發生變化，而相對應的 View 也隨即產生變化。
同樣的，MVVM 也有他的缺點：
一個首要的缺點是，MVVM 的學習成本和開發成本都很高。MVVM 是一個年輕的設計模式，大多數人對他的了解都不如 MVC 熟悉，基于綁定機制來進行編程需要一定的學習才能較好的上手。同時在 iOS 客戶端開發中，并沒有現成的綁定機制可以使用，要么使用 KVO，要么引入類似 ReactiveCocoa 這樣的第三方庫，使得學習成本和開發成本進一步提高。
另一個缺點是，數據綁定使 Debug 變得更難了。數據綁定使程序異常能快速的傳遞到其他位置，在界面上發現的 Bug 有可能是由 ViewModel 造成的，也有可能是由 Model 層造成的，傳遞鏈越長，對 Bug 的定位就越困難。
同時還必須指出的是，在傳統的 MVVM 架構中，ViewModel 依然承載的大量的邏輯，包括業務邏輯，界面邏輯，數據存儲和網絡相關，使得 ViewModel 仍然有可能變得和 MVC 中 ViewController 一樣臃腫。
在兩種架構中權衡而產生的架構
兩種架構的優點都想要，缺點又都想避開，我們在兩種架構中權衡了他們的優缺點，設計出了一個新的架構，起了一個名字叫：MVVM without Binding with DataController，架構圖如下：
ViewModel
先來看右邊視圖相關的部分，傳統的 MVC 當中 ViewController 中有大量的數據展示和樣式定制的邏輯，我們引入 MVVM 中 ViewModel 的概念，將這部分視圖邏輯移到了 ViewModel 當中。
在這個設計中，每一個 View 都會有一個對應的 ViewModel，其包含了這個 View 數據展示和樣式定制所需要的所有數據。同時，我們不引入雙向綁定機制或者觀察機制，而是通過傳統的代理回調或是通知來將 UI 事件傳遞給外界。而 ViewController 只需要生成一個 ViewModel 并把這個裝配給對應的 View，并接受相應的 UI 事件即可。
這樣做有幾個好處：首先是 View 的完全解耦合，對于 View 來說，只需要確定好相應的 ViewModel 和 UI 事件的回調接口即可與 Model 層完全隔離；而 ViewController 可以避免與 View 的具體表現打交道，這部分職責被轉交給了 ViewModel，有效的減輕了 ViewController 的負擔；同時我們棄用了傳統綁定機制，使用了傳統的易于理解的回調機制來傳遞 UI 事件，降低了學習成本，同時使得數據的流入和流出變得易于觀察和控制，降低了維護了調適的成本。
DataController
接下來我們關注 Model 和 VC 之間的關系。如之前提到，在傳統的 MVVM 中，ViewModel 接管了 ViewController 的大部分職責，包括數據獲取，處理，加工等等，導致其很有可能變得臃腫。我們將這部分邏輯抽離出來，引入一個新的部件，DataController。
ViewController 可以向 DataController 請求獲取或是操作數據，也可以將一些事件傳遞給 DataController，這些事件可以是 UI 事件觸發的。DataController 在收到這些請求后，再向 Model 層獲取或是更新數據，最后再將得到的數據加工成 ViewController 最終需要的數據返回。
這樣做之后，使得數據相關的邏輯解耦合，數據的獲取、修改、加工都放在 Data Controller 中處理，View Controller 不關心數據如何獲得，如何處理，Data Controller 也不關心界面如何展示，如何交互。同時 Data Controller 因為完全和界面無關，所以可以有更好的測試性和復用性。
DataController 層和 Model 層之間的界限并不是僵硬的，但需要保證每一個 ViewController 都有一個對應的 DataController。Data Controller 更強調的是其作為業務邏輯對外的接口。而在 DataController 中調用更底層的 Model 層邏輯是我們推薦的編程范式，例如數據加工層，網絡層，持久層等。
在后面的例子中，我們會更詳細的講解 DataController 的實現細節。
Show me the code
我們以猿題庫主頁為例，展示我們是如何使用應用這個架構的。
主頁有幾個部分組成，最上面的小猴子 Banner 頁，用于滾動展示一些活動信息；中間有一個用戶名字的頁面，用于展示用戶信息和答題情況以及一些心靈雞湯；最底下的這部分是一個課目選擇頁面，展示了用戶開啟的科目入口，在更多選項里面可以進一步配置這些科目入口。接下來我們會以科目頁面（SubjectView）為例展示一些細節。
ViewController
我們會給每一個 ViewController 都創建一個對應的 DataController。
例如我們給主頁建一個類起名叫APEHomePraticeViewController，同時他會有一個對應的 DataController 起名叫 APEHomePraticeDataController。同時我們把頁面拆分為幾個部分，每個部分有一個相對應的 SubView。代碼如下：
在 viewDidLoad 的時候，初始化好各個 SubView，并設置好布局：
- (void)setupContentView {self.contentView = [[UIScrollView alloc] init];[self.view addSubview:self.contentView];self.bannerView = [[APEHomePracticeBannerView alloc] init];self.activityView = [[APEHomePracticeActivityView alloc] init];self.subjectsView = [[APEHomePracticeSubjectsView alloc] init];self.subjectsView.delegate = self;[self.contentView addSubview:self.bannerView];[self.contentView addSubview:self.activityView];[self.contentView addSubview:self.subjectsView];// Layout Views ... }接下來，ViewController 會向 DataController 請求 Subject 相關的數據，并在請求完成后，用獲得的數據生成 ViewModel，將其裝配給 SubjectView，完成界面渲染，代碼如下：
- (void)fetchSubjectData {[self.dataController requestSubjectDataWithCallback:^(NSError *error) {if (error == nil) {[self renderSubjectView];}}]; } - (void)renderSubjectView {APEHomePracticeSubjectsViewModel *viewModel =[APEHomePracticeSubjectsViewModel viewModelWithSubjects:self.dataController.openSubjects];[self.subjectsView bindDataWithViewModel:viewModel]; }數據結構
為了更好的演示，我們接下來要介紹一下 Subject 相關的數據結構：
APESubject 是科目的資源結構，包含了 Subject 的 id 和 name 等資源屬性，這部分屬性是用戶無關的；APEUserSubject 是用戶的科目信息，包含了用戶是否打開某個學科的屬性。
DataController
如我們之前所說，每一個 ViewController 都會有一個對應的 DataController，這一類 DataController 的主要職責是處理這個頁面上的所有數據相關的邏輯，我們稱其為 View Related Data Controller。
// APEHomePracticeDataController.h @interface APEHomePracticeDataController : APEBaseDataController // 1 @property (nonatomic, strong, nonnull, readonly) NSArray<APESubject *> *openSubjects; // 2 - (void)requestSubjectDataWithCallback:(nonnull APECompletionCallback)callback; @end上面的這個代碼
DataController 這一層是一個靈活性很高的部件，一個 DataController 可以復用更小的 DataController，這一類更小的 DataController 通常只會包含純粹的或是更抽象的 Model 相關的邏輯，例如網絡請求，數據庫請求，或是數據加工等。我們稱這一類 DataController 為 Model Related Data Controller。
Model Related Data Controller 通常會為上層提供正交的數據：
在我們的 APEHomePraticeDataController 的實現中，就包含了一個 APESubjectDataController，這個 subjectDataController 會負責請求 All Subjects 和 User Subjects，并將其加工成上層所最終需要的 Open Subjects。（備注：這個例子里面的 callback 會回調多次是猿題庫產品的需求，如有需要，可在這一層控制請求都完成后再調用上層回調）
事實上，Model Related Data Controller 可以一般性的認為就是大家經常在寫的 Model 層代碼，例如 UserAgent，UserService，PostService 之類的服務。之后讀者若想重構就項目成這個架構，大可以不必糾結于形式，直接在 DataController 里調用舊有代碼的邏輯即可，如圖下面這樣的行為都是允許的：
ViewModel
每一個 View 都會有一個對應的 ViewModel，這個 ViewModel 會包含展示這個 View 所需要的所有數據。
我們會使用工廠方法來創建 View Model，例如這個例子里，Subject View Model 不需要關心傳遞給他是什么樣的 Subject，所有的課目或者只是用戶開啟的科目。
ViewModel 可以包含更小的 ViewModel，就像 View 可以有 SubView 一樣。SubjectView 的內部是由一個UICollectionView實現的，所以我們也給了對應的 Cell 設計了一個 ViewModel。
需要額外注意的是，ViewModel 一般來說會包含的顯示界面所需要的所有元素，但粒度是可以控制。一般來說，我們只把會因為業務變化而變化的部分設為 ViewModel 的一部分，例如這里的 titleColor 和 backgroundColor 會因為主題不同而變化，但字體的大小（titleFont）卻是不會變的，所以不需要事無巨細的都加到 ViewModel 里。
View
View 只需要定義好裝配 ViewModel 的接口和定義好 UI 回調事件即可：
@protocol APEHomePracticeSubjectsViewDelegate <NSObject> - (void)homePracticeSubjectsView:(nonnull APEHomePracticeSubjectsView *)subjectViewdidPressItemAtIndex:(NSInteger)index; @end @interface APEHomePracticeSubjectsView : UIView @property (nonatomic, strong, nullable, readonly) APEHomePracticeSubjectsViewModel *viewModel; @property (nonatomic, weak, nullable) id<APEHomePracticeSubjectsViewDelegate> delegate; - (void)bindDataWithViewModel:(nonnull APEHomePracticeSubjectsViewModel *)viewModel; @end渲染界面的時候，完全依靠 ViewModel 進行，包括 View 的 SubView 也會使用 ViewModel 里面的子 ViewModel 渲染。
- (void)bindDataWithViewModel:(nonnull APEHomePracticeSubjectsViewModel *)viewModel {self.viewModel = viewModel;self.backgroundColor = viewModel.backgroundColor;[self.collectionView reloadData];[self setNeedsUpdateConstraints]; } - (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath: (NSIndexPath *)indexPath {APEHomePracticeSubjectsCollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"Cell" forIndexPath:indexPath];if (0 <= indexPath.row && indexPath.row < self.viewModel.cellViewModels.count) {APEHomePracticeSubjectsCollectionCellViewModel *vm = self.viewModel.cellViewModels[indexPath.row];[cell bindDataWithViewModel:vm]; }return cell; }至此，我們就完成了所有的步驟。我們回過頭再看一下 ViewController 的職責就回變的非常簡單，裝配好 View，向 DataController 請求數據，裝配 ViewModel，配置給 View，接收 View 的UI事，一切復雜的操作都能夠的代理出去。
總結
優點
通過上面的例子我們可以看到，這個架構有幾個優點：
層次清晰，職責明確：和界面有關的邏輯完全劃到 ViewModel 和 View 一遍，其中 ViewModel 負責界面相關邏輯，View 負責繪制；Data Controller 負責頁面相關的數據邏輯，而 Model 還是負責純粹的數據層邏輯。 ViewController 僅僅只是充當簡單的膠水作用。
耦合度低，測試性高：除開 ViewController 外，各個部件可以說是完全解耦合的，各個部分也是可以完全獨立測試的。同一個功能，可以分別由不同的開發人員分別進行開發界面和邏輯，只需要確立好接口即可。
復用性高：解耦合帶來的額外好處就是復用性高，例如同一個View，只需要多一個工廠方法生成 ViewModel，就可以直接服用。數據邏輯代碼不放在 ViewController 層也可以更方便的服用。
學習成本低: 本質上來說，這個架構屬于對 MVC 的優化，主要在于解決 Massive View Controller 問題，把原本屬于 View Controller 的職責根據界面和邏輯部分相應的拆到 ViewModel 和 DataController 當中，所以是一個非常易于理解的架構設計，即使是新手也可以很快上手。
開發成本低: 完全不需要引入任何第三方庫就可以進行開發，也避免了因為 MVVM 維護成本高的問題。
實施性高，重構成本低：可以在 MVC 架構上逐步重構的架構，不需要整體重寫，是一種和 MVC 兼容的設計。
缺點
不可否認的是，這個設計也有其相應的缺點，由于其把傳統 MVVM 里面的 VM 拆成兩部分，會照成下面的一些情況：
后記
MVVM 是一個很棒的架構，私底下我也會用其來做一些個人項目，但在公司項目里，我會更慎重的考慮個中利弊。我做這個設計的時候，心儀 MVVM 的種種好處，又忌憚于它的種種壞處，再考慮到團隊的開發和維護成本，所以最終設計成了如今這樣。
個人認為，好的架構設計的都是和團隊以及業務場景息息相關的。我們這套架構幫助我們解決了 ViewController 代碼堆積的問題，也帶來了更清晰明了的代碼層級和模塊職責，同時沒有引入過多的復雜性。希望大家也能充分理解這套架構的適用場景，在自己的 APP 架構設計中有所借鑒。
轉載于:https://www.cnblogs.com/weiboyuan/p/5090592.html
總結
以上是生活随笔為你收集整理的猿题库 iOS 客户端架构设计-唐巧的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： FileStream功能被禁用
- 下一篇： poj 1830 开关问题 高斯消元