iOS專案架構模式(MVC、MVVM、MVCS、VIPER的選擇)
聯絡人:石虎 QQ:1224614774 暱稱: 嗡嘛呢叭咪哄
QQ群:807236138 群稱: iOS 技術交流學習群
一、概念
沒有最好的架構，只有適合自己的業務的架構才是最好的架構，並且它是逐步地變強變大。
架構，又名軟體架構，是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。
二、iOS的系統架構分為四個層次：
核心作業系統層（Core OS layer）、核心服務層（Core Services layer）、媒體層（Media layer）和可觸控層（Cocoa Touch layer）。下面是IOS系統結構圖。
1、Core OS是位於iOS系統架構最下面的一層是核心作業系統層，它包括記憶體管理、檔案系統、電源管理以及一些其他的作業系統任務。它可以直接和硬體裝置進行互動。作為app開發者不需要與這一層打交道。
2、Core Services是核心服務層，可以通過它來訪問iOS的一些服務。
3、Media是媒體層，通過它我們可以在應用程式中使用各種媒體檔案，進行音訊與視訊的錄製，圖形的繪製，以及製作基礎的動畫效果。
4、Cocoa Touch是可觸控層，這一層為我們的應用程式開發提供了各種有用的框架，並且大部分與使用者介面有關，本質上來說它負責使用者在iOS裝置上的觸控互動操作。
iOS是基於UNIX核心，android是基於Linux核心，iOS和android作為兩款優秀的手機作業系統，他們有共性有區別，下面分享一張android系統架構圖：
三、常見的分層架構
有三層架構：檢視層、業務層、資料層。
也有四層架構：檢視層、業務層、網路層、本地資料層。
這裡說三層、四層，跟TCP/IP所謂的五層或者七層不是同一種概念。再具體說就是：你的架構在邏輯上設計的是幾層那就是幾層，具體每一層的名稱和作用，沒有特定的規範, 這主要是針對模組分類而言的。
1.檢視層設計方案
2.網路層設計方案
3.本地持久化方案
4.動態部署方案
上面這四大點，稍微細說一下就是：
- 頁面如何組織，才能儘可能降低業務方程式碼的耦合度？儘可能降低業務方開發介面的複雜度，提高他們的效率？
- 如何讓業務開發工程師方便安全地呼叫網路API？然後儘可能保證使用者在各種網路環境下都能有良好的體驗？
- 當資料有在本地存取的需求的時候，如何能夠保證資料在本地的合理安排？如何儘可能地減小效能消耗？
- iOS應用有稽核週期，如何能夠通過不發版本的方式展示新的內容給使用者？如何修復緊急bug？
四、檢視層設計方案
一般來說，一個不夠好的View層架構，主要原因有以下五種：
1.程式碼混亂不規範
2.過多繼承導致的複雜依賴關係
3.模組化程度不夠高，元件粒度不夠細
4.橫向依賴
5.架構設計失去傳承
1.View層的程式碼結構規範
制定程式碼規範嚴格來講不屬於View層架構的事情，但它對View層架構未來的影響會比較大，也是屬於架構師在設計View層架構時需要考慮的事情。制定View層規範的重要性在於：
1.提高業務方View層的可讀性可維護性
2.防止業務程式碼對架構產生腐蝕
3.確保傳承
4.保持架構發展的方向不輕易被不合理的意見所左右
五、架構模式(MVC、MVVM、MVCS、VIPER的選擇)
MVC
- 任務均攤–View和Model確實是分開的，但是View和Controller卻是緊密耦合的
- 可測試性–由於糟糕的分散性，只能對Model進行測試
- 易用性–與其他幾種模式相比最小的程式碼量。熟悉的人很多，因而即使對於經驗不那麼豐富的開發者來講維護起來也較為容易。
MVVM
- 任務均攤 – 在例子中並不是很清晰，但是事實上，MVVM的View要比MVP中的View承擔的責任多。因為前者通過ViewModel的設定繫結來更新狀態，而後者只監聽Presenter的事件但並不會對自己有什麼更新。
- 可測試性 – ViewModel不知道關於View的任何事情，這允許我們可以輕易的測試ViewModel。同時View也可以被測試，但是由於屬於UIKit的範疇，對他們的測試通常會被忽略。
- 易用性 – 在我們例子中的程式碼量和MVP的差不多，但是在實際開發中，我們必須把View中的事件指向Presenter並且手動的來更新View，如果使用繫結的話，MVVM程式碼量將會小的多。
VIPER
- 任務均攤 – 毫無疑問，VIPER是任務劃分中的佼佼者。
- 可測試性 – 不出意外地，更好的分佈性就有更好的可測試性。
- 易用性 – 最後你可能已經猜到了維護成本方面的問題。你必須為很小功能的類寫出大量的介面。
六、總結
一個好的架構
- 遵循程式碼規範程式碼，分類明確(沒有難以區分模組的資料夾或模組)
- 註釋明瞭, 邏輯清晰, 不用文件，或很少文件，就能讓業務方上手
- 思路和方法要統一，儘量不要多元
- 沒有橫向依賴，儘可能少的跨層訪問
- 對業務方該限制的地方有限制，該靈活的地方要給業務方創造靈活實現的條件
- 易測試，易拓展
- 保持一定量的超前性
- 介面少，介面引數少
- 低記憶體，高效能