iOS App開發的那些事兒2：如何搭建合適的框架

《iOS App開發的那些事兒》系列文章從更宏觀的角度出發，不只僅侷限於具體某個功能、界面的實現，而是結合 網易雲信iOS端研發負責人多年的經驗，從如何優化現有代碼的角度出發，深度分析如何創造出iOS App開發中比較合適的規範和框架。 

推薦閱讀

iOS App開發的那些事兒1：如何創建合適的規範

一個合適的框架不是銀彈，在我看來框架要解決的問題歷來不是：有了框架以後，工程就能無比正確地進行下去。好的框架可以作到的事僅僅只是：下降通用問題的複雜度和減小發生錯誤的可能性。我的認爲一個良好iOS App框架應該是有以下特色：

定義清晰的層次結構

• 橫向上，各模塊互相獨立，僅經過有限的幾個接口進行通信。最理想的狀態是除核心模塊外，其餘模塊都是可拔插。縱向上，各層次間依賴關係清晰，基本不出現逆向依賴的狀況。
  
• 橫向模塊通常依賴於業務需求，常被定義成各類Service或Manager。一種好的作法是有個統一的Service管理器負責相應Serivce的加載，卸載，監聽和分發App級別的通知給相應Service，如先後臺切換，收到內存警告等。這樣作一方面容易實現上面說的模塊的可插拔化，另外一方面也保證了公用特性處理的一致性。在這方面微信就作得不錯，基本全部的模塊都是從MMService繼承而來，由MMServiceCenter進行管理。固然從dump出來的頭文件也能夠發現一些管理上的紊亂，好比一些ViewController都是繼承自MMService。
  
• 縱向的層次劃分基本各個App不會有太大區別，通常能夠分爲三個層次：
  

展示層(Presentation layer)，負責管理UI和UIViewController。

邏輯層(Business/Service Layer)，負責邏輯數據的定義和轉發，起到承上啓下的做用。

數據訪問層(Data Access Layer)，負責具體API構造，網絡請求，數據持久化等。

各層根據業務邏輯的複雜性內部又會使用單層或者多層結構。以數據訪問層爲例，通常又能夠細分爲網絡層，持久化層。而通常而言，展示層(UIView和UIViewController)都是直接使用邏輯層提供的Model進行展示，可是某些場景下每每須要不一樣的Model有相同的界面展現(如咱們的App易信中，會話界面，收藏界面，問一問功能都須要進行圖片的展示，但這三個模塊下的Model定義並不一致)，這就須要增長額外的ViewModel層用於粘合展示層和邏輯Model。

遵照SOLID原則和慎用各類設計模式

這是個老生常談的話題了，並非iOS開發獨有，展開講能夠講上幾天幾夜，不贅述。

定義本身的UI基類：UIView，UIViewController，UITableviewCell

這一點的好處不言而喻，全部的子View，Controller，Cell都可以很方便的繼承基類的共有的行爲，樣式。但也會引進很大的管理風險：組內成員總會經不起誘惑往基類塞各類並不普適的特性，引發基類權責的無限膨脹。大基類不只增長組內成員對代碼的理解難度，同時也增長出現問題時的排查難度。從這方面講，微信的UIViewController基類設計就極端失敗：MMUIViewController這個類光頭文件就有上百行。

提供方便好用的工具類

一些好用的工具類每每會成爲框架重要的有機組成部分，方便快捷地解決局部問題，同時又不引入過多的複雜度。NSTimer的retain cycle是個很容易掉去的坑，那麼提供一個基於Block或者weak delegate的NSTimer的封裝就是不錯的選擇。使用KVO容易發生add和remove的不配對調用，那麼就引入THObserversAndBinders或者FB的KVOContorller。某些核心模塊須要被多個模塊依賴時，引入相似XMPP的GCDMulticastDelegate就可以方便地進行解耦。

好的範例

在前幾年使用C++的那段暗無天日的日子裏，我常想的一個問題是：如何在API層面去限制和規避一些錯誤。好比往線程池裏面扔的task必須是堆上分配的對象，那麼如何去強制傳入的指針指向的是堆地址而不是棧地址呢？這種傻問題大部分狀況下是無解的，有時候有解倒是個異常彆扭的解。而如今我更相信破窗理論所提供的可能性：作好示範，接下來的一切都會水到渠成。

你們能夠戳 iOS App開發的那些事兒1：如何創建合適的規範 回顧該系列第一篇文章，也歡迎你們積極發表本身的見解，與咱們共同討論。