mvp 在 android 上的使用其實已經流行了有挺長的一段時間，包括我們公司，經過我們android端小夥伴們的思考與才華 我們的產品也是採取的mvp模式。
今天主要是想分享一下，本人對mvp的淺見，以及如何使用mvp模式搭建乙個專案框架。
說明：由於本人能力和時間有限，所以本文只是拋磚引玉，疏漏之處敬請諒解。
老規矩，先上圖：
mvp，全稱 model-view-presenter，是一種架構模式；
從mvc這位老前輩 演變而來；
至於mvc，mvp，mvvm的區別請檢視：mvc，mvp 和 mvvm 的圖示。
大體分為 model、view、presenter三層，下面介紹一下這幾層的作用：
view :負責繪製ui元素、與使用者進行互動(在android中體現為activity);
view inte***ce :需要view實現的介面，view通過view inte***ce與presenter進行互動，降低耦合，方便進行單元測試;
model :負責儲存、檢索、操縱資料(有時也實現乙個model inte***ce用來降低耦合);
presenter :作為view與model互動的中間紐帶，處理與使用者互動的負責邏輯。
mvp的優點：
分離了檢視邏輯和業務邏輯，降低了耦合；
activity只處理生命週期的任務，**變得更加簡潔；
我們可以將乙個presenter用於多個檢視，而不需要改變presenter的邏輯。這個特性非常的有用，因為檢視的變化總是比模型的變化頻繁；
檢視邏輯和業務邏輯分別抽象到了view和presenter的介面中去，提高**的可閱讀性；
presenter被抽象成介面，可以有多種具體的實現，所以方便進行單元測試；
把業務邏輯抽到presenter中去，避免後台執行緒引用著activity導致activity的資源無法被系統**從而引起記憶體洩露和oom
不足：
presenter中除了應用邏輯以外，還有大量的view->model，model->view的手動同步邏輯，造成presenter比較重，維護起來會比較困難。
額外的**複雜度及學習成本。
背景：
有三大主打產品；
產品需要不斷迭代；
功能模組多；
以團隊為單位進行開發；
大體思路：
乙個專案是否好擴充套件，靈活性是否夠高，包結構的劃分方式佔了很大比重。很多專案裡面喜歡採用按照特性分包（就是activity、service等都分別放到乙個包下），在模組較少、頁面不多的時候這沒有任何問題；但是對於模組較多，團隊合作開發的專案中，這樣做會很不方便。所以，我的建議是按照模組劃分包結構。
注意：需要修改 module下的build.gradle檔案
這層不準備細分，如果細分的話可以參考這篇文章-「領域驅動設計系列文章——**vo、dto、do、po的概念、區別和用處」
簡單的頁面中直接使用 activity/fragment 作為 view 的實現類，然後抽取相應的介面；
在一些有 tab 的頁面中，可以使用 activity + fragment ( + viewpager) 的方式來實現，至於 viewpager，視具體情況而定，當然也可以直接 activity + viewpager 或者其他的組合方式
在一些包含很多控制項的複雜頁面中，那麼建議將介面拆分，抽取自定義 view，也就是乙個 activity/fragment 包含多個 view（實現多個 view 介面）
用於程式邏輯處理, 通過介面與view互動, 解耦業務和介面
這邊會大量的view->model，model->view的手動同步邏輯，造成presenter比較重，維護起來會比較困難，所以這邊我們採用的是eventbus來進行解耦
請參考： 如何評估開源庫是否值得引入!!!
mvp 模式的的開源庫：
參考：
Fabric架構淺讀
解耦交易處理節點的邏輯角色為背書節點 endorser 確認節點 committer 可以根據負載進行靈活部署 加強了身份證書管理服務，作為單獨的fabric ca專案，提供更多功能 支援多通道特性，不同通道之間的資料彼此隔離，提高隔離安全性 支援可拔插的架構，包括共識 許可權管理 加解密 賬本機制...
深入淺出Docker Swarm架構與命令
swarm是docker公司在2014年12月初新發布的容器管理工具。和swarm一起發布的docker管理工具還有machine以及compose。1.swarm簡介 docker自誕生以來，其容器特性以及映象特性給devops愛好者帶來了諸多方便。然而在很長的一段時間內，docker只能在單ho...
對三層架構和MVC的淺認識
三層架構是為了程式 之間解耦所使用的一種架構模式，區分層次的目的即為了 高內聚，低耦合 的思想。三層分為表示層 業務邏輯層和資料訪問層，三層之間相互影響卻又不相互牽制，比如你要修改表示層的內容，這時候，你不需要去考慮其他兩層的 實現，只需要把表示層的做好就行，需要用到資料了，就去業務邏輯層進行呼叫，...