MVP 在 Android 上的使用其實已經流行了有挺長的一段時間，包括我們公司，經過我們Android端小伙伴們的思考與才華 我們的產品也是采取的MVP模式。
今天主要是想分享一下，本人對MVP的淺見，以及如何使用MVP模式搭建一個項目框架。
說明：由於本人能力和時間有限，所以本文只是拋磚引玉，疏漏之處敬請諒解。
老規矩，先上圖：

MVP概述

MVP定義

MVP，全稱 Model-View-Presenter；
從MVC這位老前輩 演變而來；

簡單知識：

View :負責繪制UI元素、與用戶進行交互(在Android中體現為Activity); View interface :需要View實現的接口，View通過View interface與Presenter進行交互，降低耦合，方便進行單元測試; Model :負責存儲、檢索、操縱數據(有時也實現一個Model interface用來降低耦合); Presenter :作為View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。

MVP考量:

MVP的優點：

分離了視圖邏輯和業務邏輯，降低了耦合； Activity只處理生命周期的任務，代碼變得更加簡潔； 我們可以將一個Presenter用於多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁； 視圖邏輯和業務邏輯分別抽象到了View和Presenter的接口中去，提高代碼的可閱讀性； Presenter被抽象成接口，可以有多種具體的實現，所以方便進行單元測試； 把業務邏輯抽到Presenter中去，避免後台線程引用著Activity導致Activity的資源無法被系統回收從而引起內存洩露和OOM

不足：

Presenter中除了應用邏輯以外，還有大量的View->Model，Model->View的手動同步邏輯，造成Presenter比較重，維護起來會比較困難。 額外的代碼復雜度及學習成本。

MVP實踐

背景—>大體思路

背景：

有三大主打產品； 產品需要不斷迭代； 功能模塊多； 以團隊為單位進行開發；

大體思路：
拆分成兩個包：commonlibrary 與 app(Presentation)

commonlibrary：負責提供各種工具和管理第三方庫，與業務邏輯完全無關，可跨項目使用；

Presentation:負責展示圖形界面，並填充數據,處理業務邏輯；

Presentation<喎?/kf/ware/vc/" target="_blank" class="keylink">vc3Ryb25nPiDE2tKqsLS5psTcu6631sSjv+mjujxiciAvPg0KPGltZyBhbHQ9"這裡寫圖片描述" src="/uploadfile/Collfiles/20160428/20160428083905309.png" title="\" />

包結構劃分

一個項目是否好擴展，靈活性是否夠高，包結構的劃分方式占了很大比重。很多項目裡面喜歡采用按照特性分包（就是Activity、Service等都分別放到一個包下），在模塊較少、頁面不多的時候這沒有任何問題；但是對於模塊較多，團隊合作開發的項目中，這樣做會很不方便。所以，我的建議是按照模塊劃分包結構。

res劃分

layout 布局文件按 模塊劃分 其它資源文件照舊

注意：需要修改 module下的 build.gradle 文件

MVP 分層說明

View 層

簡單的頁面中直接使用 Activity/Fragment 作為 View 的實現類，然後抽取相應的接口； 在一些有 Tab 的頁面中，可以使用 Activity + Fragment ( + ViewPager) 的方式來實現，至於 ViewPager，視具體情況而定，當然也可以直接 Activity + ViewPager 或者其他的組合方式 在一些包含很多控件的復雜頁面中，那麼建議將界面拆分，抽取自定義 View，也就是一個 Activity/Fragment 包含多個 View（實現多個 View 接口）

Presentation

用於程序邏輯處理, 通過接口與View交互, 解耦業務和界面

這邊會大量的View->Model，Model->View的手動同步邏輯，造成Presenter比較重，維護起來會比較困難，所以這邊我們采用的是EventBus來進行解耦