構建iOS穩定應用架構時方案選擇的思考，主要涉及工程結構，資料流思想和代碼規範

標籤：

工程結構架構，減少耦合混亂以及防治需求大改造成結構重構

我打算採用Information flow的方式自上而下，兩大層分為基礎層和展現層的結構。基礎層分為多層，展現層也可分為多層。主要思想是將基礎層的最下一層當做零組件，將業務層最下 層當做組裝大組件，通過流程串起來形成一個完整的產品，做零件時按照做出一個就扔進對應基礎層的籃子裡思路來，目錄結構也可以按照這種來進行。這兩大層的 最下層按照零件拆得越小越容易應對需求變化越容易保護鞏固上層的思路來就好。拿這個大家都熟悉的產品的幾個功能來簡單樣本說明下這個思路構建後的結 構，模組比較多，一些模組就不深入到最底層分析了：

基礎層－ 網路－－ 收發資料－－－單例（持續使用資料）－－－本地（緩衝和持續化儲存資料對業務的封裝輸出）－－－單次使用（API介面Model封裝輸出和商務邏輯封裝的ViewModel，將這些做為業務零件）－ 儲存－－－ NSUserDefault（對輕量需要儲存的添加下一層業務零件封裝）－－－ keychain（對安全層級較高需要儲存的添加下一層業務零件封裝）－－－ 檔案儲存體（對時效需求短的需要儲存的添加下一層業務零件封裝）－－－ 資料庫儲存（對資料量大的需要儲存的添加下一層業務零件封裝，業務層上一層加一層封裝CoreData或SQLite方便日後切換資料庫用）－ 動畫（下層將動畫架構輸出成各個可以複用的動畫功能小零件）－ 視圖風格－ 清單控制項－－ 上拉載入更多－－ 下拉重新整理－－ GuideView－ WebView控制項－ AlertView－ iOS系統空間封裝－－ 拍照控制項－－ 通訊錄－ 二維碼－ 語音－ 安全－ 支付－ 統計－ 日誌展現層－ 首頁－－ 訂閱－－ 掃描二維碼－－ 發布視頻－ 列表－－ 時間軸列表－－－ Listview頭部封面－－－ 外鏈情況Cell－－－ 圖片Cell－－－ 廣告插入Cell－－－ 留言評論－－－ 贊地區－－ 我的列表－－ 訂閱列表－－ 文章列表－ 詳細頁－－ 分享－－ 內容區－－ 評論－ 登入－－ 註冊－－ 登入－－ 忘記密碼－－ 條款－－ 上傳頭像－－ 個人資訊修改

基礎層中各個模組上層可以使用類似CocoaPod或Cathage方式，下一層再對其引用進行業務封裝。

這裡注意最下層需要拆的粒度越細越好。減少橫向依賴。類似Common這樣的東西可以拆到基礎層的對應模組裡，比如說設定檔裡和統計相關的放到基 礎層的統計裡，網路相關的放到網路裡，顏色字型放到視圖風格裡，不要都堆在一個檔案裡。再或者是各種第三方的Category也放到對應的組裡，比如說 UIView+Additions和UIColor+Expanded就放到視圖風格這個模組中，不要專門搞個Category放所有的 Category。

資料流控制模式MVC和MVCS/MVVM/VIPER的選擇

其實這些都是對MVC的擴充，只是擴充的方向不同而已。VIPER把視圖和資料拆得過細變相增加了複雜度很多人也都不熟也沒有意願去瞭解它的實現， 但是模組複用卻達到了最優，MVCS是這幾個裡對MVC最佳化最簡單的只是把資料的儲存拆開了。MVVM正好介於VIPER和MVCS之間，從 ViewController裡拆出來的ViewModel能夠將資料經過邏輯處理用於View的顯示，View有操作用過ReactiveCocoa將 訊號傳給ViewModel來處理。

如果是我個人選擇我會選擇VIPER，因為它更符合細粒度模組劃分的思想。但是用在團隊多人開發上，還是偏向MVVM這種折中方案。MVVM按照先 前對應用的結構分層，會將View和ViewController放到展現層的最下面的兩層裡，將ViewModel和Model放到基礎層對應模組的最 下面一層中。最後要說的是無論選擇哪種，只要是按照減少ViewController大小，將改胖的地方放到Model或View都是可以的，招式學多後 最高境界就是無招勝有招嘛，有時也不需要刻板的在一個項目中將所有的模組都按照統一的思路給框死，比如說一個模組很簡單就用MVC，一般複雜就用 MVVM，要是項目本身業務非常龐大可以整體採用VIPER來進行ViewController的完全拆分。

可以通過下列圖表看其中的不同：

名稱	邏輯和視圖	資料
MVC	View + ViewController	+ Model
MVCS	View + ViewController + Store	+ Model
MVVM	View + ViewController + ViewModel	+ Model
VIPER	View + ViewController + Wireframe + Presenter + Interactor + Data Manager	+ Entity(Model)

代碼規範

這塊最有權威的應該是蘋果自己提出的蘋果官方規範，按照這套來肯定是沒問題的，而且首先應該遵守。代碼結構主要根據不同團隊的經驗來做。下面舉個我常用的代碼結構

@property...#pragma mark - Life cycle生命週期，類似addSubview和Notification的監聽和銷毀都放在這裡#pragma mark - Interface介面#pragma mark - Event response#pragma mark - Private method如果是ViewController，這個地方就是瘦身的關鍵，業務和邏輯功能相關的就放到ViewModel裡。#pragma mark - Delegate代理#pragma mark - Getters and Setters建議所有的Property都設定，這樣修改配置會比較方便，看起來不會很混亂

構建iOS穩定應用架構時方案選擇的思考，主要涉及工程結構，資料流思想和代碼規範