談談Android中的MVP

模式

談MVP以前咱們先來聊一聊軟件開發中的模式，在軟件開發中因爲需求的不斷變動，產品的不斷迭代，程序員們爲了應付產品經理不斷變化的需求，提出了一系列的定式。定式一詞最先應該是來源於圍棋中的術語，圍棋的定式本質上也就是經過必定開局方式來提升圍棋的勝率，軟件開發中也是同樣的，經過精心設計的一系列定式，來解決軟件開發中反覆遇到的一些問題，來快速響應產品需求。

關於「模式」在開發中會會說起兩個詞，設計模式和架構模式，二者是有區別的，個人理解是：設計模式更加關注於微觀，架構模式更加關注於宏觀設計。每每都是架構模式針對的是整個產品層面的設計，設計模式針對的是產品中的某一個功能點的設計，比較常見的MVC和MVP就屬於宏觀架構模式，觀察者和模板模式就屬於微觀設計模式。固然也不是絕對的，設計模式中也可能具備宏觀架構，架構模式中也可能有微觀架構，不過從並集結構來看，大致如此。

架構模式的設計更加註重於產品業務層面的考慮，常見的框架模式有以下幾種:

• 分層模式
• 微模式
• 事件驅動
• 基於空間架構

固然，在實際設計中可能會有多種框架設計方式結合一塊兒。關於設計模式和架構模式，推薦兩本書，GOF的《設計模式》和Frank Buschmann的《面向模式的軟件設計》。

分層思惟和MVC模式

MVC模式本質上就是屬於框架模式中的分層架構，分層架構其實就是模仿天然界各司其職的思惟方式，這種思惟在互聯網公司的組織架構中尤爲明顯，產品經理負責功能規劃，軟件開發工程師負責開發出對應功能，測試人員保證軟件質量。網絡協議也是一個著名的分層思想 ：

Java EE是一個自然的MVC分層架構

• 視圖View: JSP文件負責顯示，直接和用戶打交道
• 控制器Controller：通常是一個servlet,完成業務邏輯處理,並伴隨着請求Model層數據
• 模型層Model：表如今Java EE中就是一些bean以及持久化數據邏輯。Model層能夠直接將數據發送給View,通知View從新渲染數據

MVC優缺點網上有不少人談，好比MVC具備低耦合性，高內聚性、可維護性強等等，缺點是須要新建的類很是多，C層快速膨脹等等。可是這些都不是致命的缺點，真正致命的缺點後面再談。

爲何是MVP而不是MVC？

下圖直觀的顯示了MVP和MVC的區別：

幾句話來區分一下MVP和MVC：

• 用P層替代了C層
• P層和V層之間經過一層接口來進行解耦
• V層和M層不會直接通訊，通訊僅僅侷限於V和P之間

MVP和MVC比有什麼好處？一句話來講：

增長了中心節點，減小了數據流向的混亂

明顯，P層就是MVP種的中心節點，中心節點有什麼好處？

令行禁止，說一是一

全部的數據都從P層流入，流出，數據流向透明、可控，MVC具備的一優勢MVP都有，而MVC因爲缺乏中心化的數據控制層，因此V層能夠直接和M層通訊，致使數據的流入和流出一團糟，這個就是MVC的致命缺點之一，它自己違背了分層思想中的分層隔離的思想。

Android開發中爲何MVC很差使，一個緣由是Android自己就不是一個自然的MVC架構，它只是一個類MVC架構，M層是數據層，C層是Activity/fragment，V是XML文件，XML的生命週期又須要依賴於Activity/fragment，因此在Activity/fragment中會有對View的操做。 另一個緣由是MVC在Android開發中的侷限，V層會常常對M層作通訊，好比V層中接收M層數據的變化,刷新頁面,這種直接M直接做用於V；有時候可能C層也會直接通知V層來響應數據的變化,若是出現BUG,你很難找到是哪個部分致使的.而MVP模式經過把邏輯縮到P層，經過在View和presenter之間增長一層接口,而減小model和view層的交互,從而把部分邏輯徹底轉接給presenter層,進一步減小了View層的邏輯,這樣依賴View可以真正的作到徹底處理UI方面的工做.

• 下降耦合度:MVP減小了MVC模式下V和C的直接交互,進一步減小了V層的邏輯處理.讓V層變的很是薄,P層變的很厚.
• 增長V層和P層直接之間的接口,讓P層能夠直接操做V層UI,把邏輯徹底轉嫁給P層處理
• Activity 只處理生命週期的任務和View層的邏輯
• Presenter層被抽象稱接口,便於進行單元測試
• 減小內存泄漏的風險,由於異步任務徹底抽象稱了接口,減小了相互之間的引用

優勢說完了，缺點也一樣明顯。MVP的中中心化的問題在於中心節點承載過多的邏輯，致使P層不斷臃腫，特別是在Android開發中，網絡請求、數據庫操做、控制邏輯等等，P層邏輯不斷增長，最後出現了一個巨型的上帝類。

這個時候你須要一個工具，去簡化P層代碼。

RxJava

RxJava正是這個工具。RxJava是什麼，簡單來講：

RxJava讓你經過事件流的方式來對數據進行操做，這種操做包括數據的組合、包裝、監聽，而且讓你在同步和異步線程中自如切換。

關於RxJava更多介紹，點擊這裏

RxJava在MVP中起到的做用：

經過對事件流的操做，減化P層的邏輯，減小代碼的耦合

怎麼減小？

• 異步操做的簡便性，完全拋棄各類地獄回調
• 完全訣別坑爹的AnsyTask

一句話來講：

越是複雜的邏輯，越能體現RxJava的優越性

更多關於RxJava的學習參考其它教程。

MVP的工程實踐

MVP的實踐基本是基於谷歌官方的架構

具體工程實踐下一篇在講。

總結

軟件架構永遠是服務於業務的，業務的複雜度決定了架構的簡潔性，在不少時候，架構不是萬能的，在沒法用架構解決狀況下，考慮對業務作精簡和分層可以達到很好的效果。MVC架構在分層架構中是佔有很是重要的地位，不過因爲MVC自己的缺點和Android自身架構的侷限性，原生的MVC在Android應用會有很是多的問題，而MVP架構的分層+中心化的架構模式可以在Android的項目中取得良好的效果。

參考文檔

• 架構模式的聖經
• MVC模式