工程結構架構，減少耦合混亂以及防治需求大改造成結構重構，如何構建穩定可擴展可變換的工程結構的思考

我打算采用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)

代碼規范

這塊最有權威的應該是蘋果自己提出的https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html，按照這套來肯定是沒問題的，而且首先應該遵守。代碼結構主要根據不同團隊的經驗來做。下面舉個我常用的代碼結構

@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都設置，這樣修改配置會比較方便，看起來不會很混亂

?

轉載：http://www.starming.com/index.php?v=index&view=83

轉載于:https://www.cnblogs.com/kenshinobiy/p/4889412.html

總結

以上是生活随笔為你收集整理的构建iOS稳定应用架构时方案选择的思考，主要涉及工程结构，数据流思想和代码规范...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。