1、架構設計目的
經過設計使程序模塊化，作到模塊內部的高聚合和模塊之間的低耦合，這樣作的好處是使得程序在開發的過程當中，開發人員只須要專一於一點，提升程序開發的效率，而且更容易進行後續的測試以及定位問題。前端
對於不一樣量級的工程，具體架構的實現方式必然是不一樣的，因此對於移動端來講，逐漸演變出MCV、MVP、MVVM三種結構模式。android
2、MVC架構模式
一、工做模塊
- View（視圖）:界面渲染
- Controller（控制器）: 業務邏輯處理
- Model（模型）:數據提供
二、工做流程
- View將請求轉交給Controller
- Controller操做Model進行數據更新
- 數據更新以後，Model通知View數據變化
- View顯示更新以後的數據
三、架構缺陷
MVC看似各施其職，互不干涉，可是互聯網發展了不少年了，隨着業務不斷的迭代，複雜度不斷的提升，MVC模式的缺陷也被愈來愈多的開發者們所詬病。git
在Android早期開發中使用的是都是MVC架構，這是一種非標準的MVC架構，Controller和View並無解耦，由於Activity或Fragment既承擔Controller的角色，又承擔了View的角色。由於UI的更新幾乎都是在Activity或Fragment中進行，一旦工程的量級上來，就會致使Controller層變得及其臃腫且難以維護。github
因爲 Controller 和 View 的揉合，回調嵌套太多，代碼邏輯不清晰，難以理解且不利於後期維護，各層次模塊之間職責不清晰等等。數據庫
3、MVP架構模式
在2016年，Google 推出了 MVP 架構，MVP是從經典的MVC模式演變而來。在嘗試使用的過程當中發現這種架構模式能解決如今所面臨過的不少問題。編程
一、工做模塊
- View（視圖）: 界面渲染
- Presenter（調度器）: 業務邏輯處理
- Model（模型）: 數據提供
二、工做流程
- View將請求轉交給Presenter
- Presenter操做Model進行數據請求
- 數據更新以後，Model通知Presenter數據發生變化
- Presenter更新View的數據
三、設計優點
明顯能夠看到，MVP和MVC最大的不一樣之處是View與Model徹底隔離，這就意味着，在Android開中，就能夠明確的把Activity看成View處理,而不須要多承擔Controller的做用，Controller和View徹底解耦。若是Model或View中的一方發生變化，只要交互接口不變，另外一方就不必對上述變化作出改變，使得Model層的業務邏輯具備很好的靈活性和可重用性，耦合性下降。對於後期維護來講，特別是項目愈來愈龐大時，能夠很快的梳理出項目結構，很方便的進行管理。設計模式
下面經過幾段實例代碼來體現一下MVP模式的事件流服務器
首先要定義幾個事件接口來做爲view和presenter之間的契約。架構
在MVP模式中，View層只負責數據的渲染和展現，因此對於事件的監聽，咱們統一經過接口的形式交給Presenter進行接管，數據更新的時候，咱們又經過接口的形式將數據回調給View層進行更新。模塊化
Presenter層則會驅動Model拿到最新的數據，咱們也能夠經過泛型封裝去簡化掉Model層，由於咱們主要的目的是將Controller和View進行解耦，經過Presenter做爲中間橋樑進行通訊。當數據更新時，Presenter又會將數據經過接口通知給View，構建了一條簡單的MVP模式的數據鏈路。
四、架構缺陷
儘管這樣，MVP模式仍是有不足之處。由於Presenter層與View層是經過接口進行交互的，若是好幾個Activity都是去實現同一個View接口，這就致使View層可能會有大量的接口，那麼無論你是否用到，全部用到的Activity都要去實現該接口的全部方法；若是對Activity去進行實現單一View接口維護的話，每個View都要去建立對應的Presenter和View接口。會致使出現大量的類，你的工程體系將會變得很龐大，以下圖：
另外，對於一些業務比較複雜的界面，你的Presenter須要去實現不少的接口，這樣會致使Presenter層太大，邏輯比較複雜，代碼臃腫的依然是個問題。
4、MVVM架構模式
MVVM架構模式目前普遍的用於移動端和前端的開發，大名鼎鼎的Vue響應式編程用的就是這種設計，其雙向綁定更是將觀察者模式完美得體現。
一、工做模塊:
- View（視圖）: 界面渲染
- ViewModel（調度器）: 業務邏輯處理
- Model（模型）: 數據提供
二、工做流程:
- 在View中來綁定事件和響應事件，進行事件的觸發
- ViewModel操做Model的去獲取數據
- Model去請求數據
- 服務器或數據庫將數據返回到Model層中
- ViewModel在回調中收到返回的實體類對象
- 實體類更新，驅動UI更新
三、設計優點
在MVVM中，數據是核心，因爲VIewModel與View之間的雙向綁定，操做了ViewModel中的數據，就會同步到DOM，咱們透過DOM事件監控用戶對DOM的改動，也會同步到ViewModel，很好作到數據的一致性。不只如此，由於雙向綁定的存在，View的功能進一步強化，Controller的功能大都移動到了View上處理，大大的簡化Controller，業務複雜、代碼臃腫的問題獲得瞭解決。
四、架構缺陷
瞭解MVVM以後，咱們會發現雙向綁定確實簡化了控制層，可以適用於複雜的業務場景，保證了數據的一致性的同時，也大大的增長了Model層。若是長期持有，不釋放內存就形成了花費更多的內存，處理不當，就會致使內存溢出或內存泄露的問題出現。
移動端開發最經常使用的重用是View，可是數據雙向綁定技術，讓你在一個View都綁定了一個Model，不一樣模塊的Model都不一樣，就會致使不利於代碼重用。
5、總結
從 MVC 架構模式到 MVVM， 這幾個軟件設計模式是一步步演化發展的，從分離展現層到展現模型層，通過這麼長時間的發展和演變，MVC 架構模式出現了各式各樣的變種，並切在不一樣的平臺上有着本身的表現，下面是對三種架構模式的統一對比：
| 模式 |
優點 |
缺陷 |
| MVC |
模塊獨立，組件重用 |
一、Controller和View耦合度高 二、邏輯回調和嵌套複雜 |
| MVP |
一、Controller和View徹底解耦 二、方便大型項目管理 |
一、接口泛化、難以維護 二、Presenter層代碼臃腫 |
| MVVM |
雙向綁定，簡化業務代碼 |
|
有些Android開發工程師認爲爲了雙向綁定而使用MVVM模式顯得很生硬，對於大型項目的協同開發，「MVP+組件化」開發則有着自然的優點，更有人說Google的AAC架構更好用。對此我不作評價，由於沒有最好的，只有適合的。每一個平臺自己每每對應用層有着本身的設計。場景不一樣，選擇不一樣，可是目的都是同樣的，都是爲了解決複雜度，提供高性能、高可用、可擴展的應用。