轉：Android官方MVP架構示例項目解析

轉自： http://www.infoq.com/cn/articles/android-official-mvp-architecture-sample-project-analysis

 

做者 呂英斌 發佈於 2016年4月29日 | 注意:GTLC全球技術領導力峯會 幫助深具遠見卓識的技術人審時度勢，提高領導力！討論

• 分享到： 微博 微信 Facebook Twitter 有道雲筆記 郵件分享
• 稍後閱讀
• 個人閱讀清單

 

前段時間Google在Github推出了一個項目，專門展現Android引用各類各樣的MVP架構，算是官方教程了。趁着還新鮮，讓咱們來拋磚引玉一探究竟，看看在Google眼裏什麼樣算是好的MVP架構。

App架構在Android開發者中一直是討論比較多的一個話題，目前討論較多的有MVP、MVVM、Clean這三種。google官方對於架構的態度一直是很是開放的，讓開發者自主選擇組織和架構app的方式，指望能留給開發者更多的靈活性。

因爲沒有一套權威的架構實現，如今不少App項目中在架構方面都有或多或少的問題。第一種常見問題是沒有架構，需求中的一個頁面對應項目中的一個activity或一個fragment，全部的界面響應代碼、業務邏輯代碼、數據請求代碼等等都集中在其中。第二種常見的問題是架構實現的不斷變化，不斷在各類架構間搖擺，一直找不到一個適合本身的架構。

就在近日，google在官方示例中給出了一系列不一樣架構的app實現，這對於一直困惑於到底該用何種架構的android開發者來講確實是福音，開發者只要根據本身項目的狀況，在不一樣的實現中選擇一種便可，固然google也明確表示了這些示例只是用來作參考，而並非要爲了當作標準，下面先爲你們簡單介紹下此項目。

項目介紹

Google把這個項目命名爲：Android架構藍圖。

項目地址爲：https://github.com/googlesamples/android-architecture

下面的內容引用自項目說明：

項目目的是經過展現各類架構app的不一樣方式來幫助開發者解決架構問題。項目中經過不一樣的架構概念及方式實現了功能相同的app。你能夠用示例來當作參考，或是乾脆拿來當作建立app項目的基礎。項目中，但願你們能把關注點集中到代碼結構、總體架構、可測試性、可維護性這四個方面。固然實現app有不少種方式，千萬不要把它當作定式。

項目中有哪些示例

目前已經完成的示例有

• todo-mvp（mvp基礎架構示例）

   

  相關廠商內容

  滴滴出行iOS客戶端架構演進之路！

  微信客戶端如何應對弱網絡！

  函數式編程中的Swift與Swift中的函數式編程！

  AWS Webinar 5月24日在線課堂|利用AWS Lambda建立應用

  國際範 最前沿 不容錯過的容器技術盛會

   

  相關贊助商

  GMTC全球移動技術大會2016年6月24日-25日，北京，點擊瞭解詳情！

   

• todo-mvp-loaders（基於mvp基礎架構項目，獲取數據部分使用了Loaders架構）

• todo-mvp-databinding（基於mvp基礎架構項目，使用了數據綁定組件）

仍在進展中的示例有

• todo-mvp-contentproviders（基於mvp基礎架構項目，使用了Content Providers）

• todo-mvp-clean（基於mvp基礎架構項目，使用了clean架構的概念）

• todo-mvp-dagger（基於mvp基礎架構項目，使用了dagger2進行依賴注入）

如何進行選擇

這個仍是須要開發者本身來作決定，每一個項目的說明文件中都說明了該實現的特性。app規模、團隊情況、維護工做量的大小、平板是否支持、代碼簡潔程度偏好，這些都會影響你的選擇。

 

到了這裏，想必你們都很想一探究竟了，到底官方示例是如何實現的呢？仍是那句話，源碼面前，了無祕密。爲了可以更好的理解官方mvp架構實現，下面咱們從源碼的角度來分析todo-mvp（mvp基礎架構示例）的實現。咱們先從項目的總體組織方式開始，再看項目究竟使用了哪些組件，最後固然是最重要的具體mvp的實現方式。

源碼分析

項目代碼組織方式

項目含一個app src目錄，4個測試目錄，分別是androidTest（UI層測試）、androidTestMock（UI層測試mock數據支持）、test（業務層單元測試）、mock（業務層單元測試mock數據支持）。src目錄的代碼組織方式徹底是按照功能來組織的，功能內部分爲xactivity、xcontract、xfragment、xpresenter四個類文件(x表明業務名稱)。

平時用到較多的另外一種組織方式是按照類型，好比按照activity、adapter、fragment、contract、presenter進行劃分，不一樣的類文件分別放到不一樣的目錄中，筆者以爲兩種方式沒有什麼太大的區別，徹底看我的喜愛了。

組件使用

因爲項目是基於gradle進行編譯的，因此咱們能夠從build.gradle文件看到項目依賴的全貌。

Guava

項目中使用到了Guava庫（https://github.com/google/guava），該庫是Google在基於java的項目中都會引用到得一個庫，庫中包含大約14k的方法數，是個很大的庫，其中包含了集合、緩存、併發、基本註解、字符串處理、io處理等等。項目中使用Guava庫主要是處理null這種不安全的狀況，由於通常咱們在使用有可能爲null的對象時，通常會增長一次判斷，代碼以下：

而若是有Guava的時候，能夠經過以下方式

這樣面對空的時候，就不用再多寫不少代碼了，確實是方便了不少。可是不建議爲了null安全直接引入如此大的一個庫，由於咱們都知道android apk的65k方法數限制，若是要用的話能夠把源碼中涉及到得部分直接拿出來用。固然Guava中還有不少重要的功能，其餘功能讀者能夠自行研究，關於Guava就先到這裏了。

測試相關組件

示例項目在可測試方面作的很是好，因爲對視圖邏輯(view層)和業務邏輯(presenter層)進行了拆分，因此咱們就能夠對UI、業務代碼分別進行測試。爲了進行UI測試引入了Espresso，爲了對業務層進行單元測試引入了junit，爲了生成測試mock對象引入了mockito，爲了支撐mockito又引入了dexmaker，hamcrest的引入使得測試代碼的匹配更接近天然語言，可讀性更高，更加靈活。

項目MVP實現方式

這節咱們就具體來看官方示例究竟是如何實現mvp的。這裏咱們先看下整體的輪廓，關於項目中業務代碼咱們僅列出了任務詳情頁（taskDetail）的相關類，其餘業務代碼相似。

基類

咱們首先來看兩個Base接口類，BasePresenter與BaseView，兩類分別是全部Presenter與View的基類。

BasePresenter中含有方法start(),該方法的做用是presenter開始獲取數據並調用view中方法改變界面顯示，其調用時機是在Fragment類的onResume方法中。

BaseView中含方法setPresenter，該方法做用是在將presenter實例傳入view中，其調用時機是presenter實現類的構造函數中。

契約類

與筆者以前見到的全部mvp實現都不一樣，官方的實現中加入了契約類來統一管理view與presenter的全部的接口，這種方式使得view與presenter中有哪些功能，一目瞭然，維護起來也方便，實例以下

activity在mvp中的做用

activity在項目中是一個全局的控制者，負責建立view以及presenter實例，並將兩者聯繫起來，下面是activity中建立view及presenter的代碼

(點擊放大圖像)

咱們能夠從上面看到整個建立過程，並且要注意的是建立後的fragment實例做爲presenter的構造函數參數被傳入，這樣就能夠在presenter中調用view中的方法了。

mvp的實現與組織

實例中將fragment做爲view層的實現類，爲何是fragment呢？有兩個緣由，第一個緣由是咱們把activity做爲一個全局控制類來建立對象，把fragment做爲view，這樣二者就能各司其職。第二個緣由是由於fragment比較靈活，可以方便的處理界面適配的問題。咱們先看view的實現，咱們只挑一部分重要的方法來看

(點擊放大圖像)

上面能夠看到setPresenter方法，該方法繼承於父類，經過該方法，view得到了presenter得實例，從而能夠調用presenter代碼來處理業務邏輯。咱們看到在onResume中還調用了presenter得start方法，下面咱們再看presenter的實現

(點擊放大圖像)

presenter構造函數中調用了view得setPresenter方法將自身實例傳入，start方法中處理了數據加載與展現。若是須要界面作對應的變化，直接調用view層的方法便可，這樣view層與presenter層就可以很好的被劃分。

最後還剩下model層實現，項目中model層最大的特色是被賦予了數據獲取的職責，與咱們日常model層只定義實體對象大相徑庭，實例中，數據的獲取、存儲、數據狀態變化都是model層的任務，presenter會根據須要調用該層的數據處理邏輯並在須要時將回調傳入。這樣model、presenter、view都只處理各自的任務，此種實現確實是單一職責最好的詮釋。

總結

到這裏咱們就基本分析完了，咱們再來總體看下官方的實現方式有哪些特性。

首先是複雜度，咱們能夠從上面的分析看出總體的複雜度仍是較低的，易學的；而後是可測試性，因爲將UI代碼與業務代碼進行了拆分，總體的可測試性很是的好，UI層和業務層能夠分別進行單元測試；最後是可維護性和可擴展性，因爲架構的引入，雖然代碼量有了必定的上升，可是因爲界限很是清晰，各個類職責都很是明確且單一，後期的擴展，維護都會更加容易。有了這個架構以後，咱們再回頭看下以前的實現是否是有不少不足，沒有關係，那麼接下來就是在項目中進行實踐的時間了。