原文鏈接：http://www.jianshu.com/p/9a6845b26856

在簡書上看到的一篇好文，爲作者點贊~

P 在 Android 上的使用其實已經有挺長一段時間了，長到似乎有點“過時”了（目前風頭正勁的是MVVM），那爲什麼現在還要講 MVP。今天我想要討論它的主要原因有如下幾點：

1. MVP 並未過時，值得我們研究

2. 目前關於 MVP 的資料都不算太詳盡

3. 由於能力和時間有限，本人拖到最近才下定決心寫

說明：本文只是拋磚引玉，疏漏之處敬請諒解。

MVP 詳解思維導圖

前言

2014年年底偶然得知在Android開發中出現了MVP這種模式，當時覺得這東西挺好，正好趕上公司要做一個新的小項目，於是嘗試了一下。仿照網上的Demo分出View、Model、Presenter層，抽取View接口，看起來像那麼回事的用MVP完成了整個項目。因爲項目簡單，期間也沒有遇到什麼坑，但是總覺得還有那些地方不對。當時網上一些關於Android MVP的介紹都有點淺嘗輒止，一個登錄或者根據地區查詢天氣等的小Demo，沒有實際在項目中應用的示例，所以在用MVP做完一個小項目之後還是不敢在主項目中輕易嘗試。首先，主項目比較混亂，改動起來工作量很大，而工期經常較緊，時間不允許；其次，知道自身對MVP理解還不夠，怕掉坑裏去；最後，也是最重要的一點，當時的項目不是按功能模塊劃分的包結構，如果改爲MVP那是真的就回不到過去了。好了，廢話不多說，今天主要是想分享一下，本人對MVP的淺見，以及如何使用MVP模式搭建一個項目框架。純屬一家之言，不足之處，請見諒。

一、什麼是 MVP

1.1. MVP 的定義

MVP，全稱 Model-View-Presenter

要說MVP那就不得不說一說它的前輩——MVC。

MVC（Model-View-Controller，模型-視圖-控制器）模式是80年代Smalltalk-80出現的一種軟件設計模式，後來得到了廣泛的應用，其主要目的在於促進應用中模型，視圖，控制器間的關注的清晰分離。MVP（Model-View-Presenter，模型-視圖-表示器）模式則是由IBM開發出來的一個針對C++和Java的編程模型，大概出現於2000年，是MVC模式的一個變種，主要用來隔離UI、UI邏輯和業務邏輯、數據。也就是說，MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。

說明：按照View和Presenter之間的交互方式以及View本身的職責範圍，Martin Folwer將MVP可分爲PV（Passive View）和SoC（Supervising Controller）兩種模式。

Passive View

顧名思義，PV（Passive View）是一個被動的View，針對包含其中的UI元素（比如控件）的操作不是由View自身來操作，而交給Presenter來操控。

Supervising Controller

在SoC（Supervising Controller）模式下，爲了降低Presenter的複雜度，將諸如數據綁定和格式化這樣簡單的UI處理邏輯邏輯轉移到View中，這些處理邏輯會體現在View實現的接口中。

1.2. 發展歷程

任何一種思想的產生都有其特定的背景，在軟件開發中也是如此。在軟件複雜度增長，需求不斷變更的客觀條件下，爲了更好的解決這些問題，出現了各種軟件架構思想、編程思想以及設計模式。（因爲人的能力並沒有“跟上”機器，所以纔會出現各種模式、方法、工具等等來補足人的不足，以最大地透支機器性能。--Indream Luo）

相信做過客戶端（PC、Android、iOS等）或者前端開發的童鞋都聽過MVC、MVP、MVVM這些名詞（就算不了解也大致知道有這個東西吧），這些都是爲了解決擁有圖像界面的程序開發複雜性而產生的模式。這裏說的是模式，當然有各種各樣的框架方便開發者在項目中應用這種模式，這不是本文重點。

有前輩（Indream Luo）說過，架構是對客觀不足的妥協，規範是對主觀不足的妥協。對此我深表贊同，先不管這些，我們來看看GUI是怎麼和MVX扯上關係的。

先搞清楚一個順序，是GUI應用程序的出現導致了MVC的產生。GUI應用程序提供給用戶可視化的操作界面，這個界面提供給用戶數據和信息。在PC上用戶與界面的交互主要依賴（鍵盤，鼠標等。這些操作會執行一些應用邏輯，應用邏輯（application logic）可能會觸發一定的業務邏輯（business logic）使應用程序數據的發生變更，數據的變更自然需要用戶界面的同步變更以提供最準確的信息。在開發這類應用程序時，爲更好的管理應用程序的複雜性，基於職責分離（Speration of Duties）的思想都會對應用程序進行分層。在開發GUI應用程序的時候，會把管理用戶界面的層次稱爲View，應用程序的數據爲Model（注意這裏的Model指的是Domain Model，這個應用程序對需要解決的問題的數據抽象，不包含應用的狀態，可以簡單理解爲對象）。Model提供數據操作的接口，執行相應的業務邏輯。有了View和Model的分層，那麼問題就來了：View如何同步Model的變更，View和Model之間如何粘合在一起。（所謂的MVX中的X都可以歸納爲對這個問題不同的處理方式）（引自：戴嘉華）。

MVC 的產生

早在上個世紀70年代，美國的施樂公司（Xerox）的工程師研發了Smalltalk編程語言，並且開始用它編寫圖形界面的應用程序。而在Smalltalk-80這個版本的時候，一位叫Trygve Reenskaug的工程師設計了MVC圖形應用程序的架構模式，極大地降低了圖形應用程序的管理難度。而在四人幫（GoF）的設計模式當中並沒有把MVC當做是設計模式，而僅僅是把它看成解決問題的一些類的集合。Smalltalk-80 MVC和GoF描述的MVC是最經典的MVC模式。

看到這服務端的童鞋有話要說：我們也用MVC，你看Structs、SpringMVC這些都是經典的MVC框架。那服務端的MVC和GUI開發中的MVC有何不同之處了，請看下面的分析。

MVC Model 2的出現

在Web服務端開發的時候也會接觸到MVC模式，而這種MVC模式不能嚴格稱爲MVC模式。經典的MVC模式只是解決客戶端圖形界面應用程序的問題，而對服務端無效。服務端的MVC模式又自己特定的名字：MVC Model 2，或者叫JSP Model 2，或者直接就是Model 2 。

好吧，說了等於沒說，總之一句話，我們今天所說的MVX都有一個前提，那就是得有GUI，得是來解決GUI應用程序開發中遇到的問題的。所以，我們只要關心最經典的MVC就可以了，想了解更多的請自行Google。

MVP 的產生

MVP模式是MVC模式的改良。在上個世紀90年代，IBM旗下的子公司Taligent在用C/C++開發一個叫CommonPoint的圖形界面應用系統的時候提出來的。

MVVM 的產生

MVVM模式最早是微軟公司提出，並且了大量使用在.NET的WPF和Sliverlight中。2005年微軟工程師John Gossman在自己的博客上首次公佈了MVVM模式。

1.3. 爲什麼需要 MVP

（以下內容參考自：MVP在Android平臺上的應用，原文作者konmik，譯者MiJack）

理由1：儘量簡單

如果你還有讀過這篇文章，請閱讀它：Kiss原則（Keep It Stupid Simple）

大部分的安卓應用只使用View-Model結構

程序員現在更多的是和複雜的View打交道而不是解決業務邏輯。

當你在應用中只使用Model-View時，到最後，你會發現“所有的事物都被連接到一起”。

只使用 Model-View

如果這張圖看上去還不是很複雜，那麼請你想象一下以下情況：每一個View在任意一個時刻都有可能出現或者消失。不要忘記View的保存和恢復，在臨時的view上掛載一個後臺任務。

“所有的事物都被連接到一起”的替代品是一個萬能對象(god object)。

god object

god object是十分複雜的，他的每一個部分都不能重複利用，無法輕易的測試、或者調試和重構。

With MVP

使用MVP

使用 MVP

複雜的任務被分成細小的任務，並且很容易解決。越小的東西，bug越少，越容易debug，更好測試。在MVP模式下的View層將會變得簡單，所以即便是他請求數據的時候也不需要回調函數。View邏輯變成十分直接。

理由2：後臺任務

當你編寫一個Actviity、Fragment、自定義View的時候，你會把所有的和後臺任務相關的方法寫在一個靜態類或者外部類中。這樣，你的Task不再和Activity聯繫在一起，這既不會導致內存泄露，也不依賴於Activity的重建。

這裏有若干種方法處理後臺任務，但是它們的可靠性都不及MVP。

1.4. 爲什麼 MVP 是可行的？

（以下內容參考自：MVP在Android平臺上的應用，原文作者konmik，譯者MiJack）

這裏有一張表格，用於展示在configuration改變、Activity 重啓、Out-Of-Memory時，不同的應用部分會發生什麼？

不同應用部分對不同場景的響應

情景 1: 當用戶切換屏幕、更改語言設置或者鏈接外部的模擬器時，往往意味着設置改變。相關更多請閱讀這裏。

情景 2:Activity的重啓發生在當用戶在開發者選項中選中了“Don’t keep activities”（“中文下爲不保留活動”）的複選框，然後另一個Activity在最頂上的時候。

情景 3: 進程的重啓發生在應用運行在後臺，但是這個時候內存不夠的情況下。

總結

現在你可以發現，一個調用了setRetainInstance(true)的Fragment也不奏效，我們還是需要保存/恢復fragment的狀態，所以爲簡化問題，我們暫不考慮上述情況的Fragment。Occam’s razor

場景簡化

現在，看上去更舒服了，我們只需要寫兩段代碼爲了恢復應用：

· 保存/恢復 for Activity, View, Fragment, DialogFragment;

· 重啓後臺請求由於進程重啓

第一個部分,用Android的API可以實現。第二個部分，就是Presenter的作用了。Presenter將會記住有哪些請求需要執行，當進程在執行過程中重啓時，Presenter將會出現執行它們。

1.5. MVP 的優缺點

任何事務都存在兩面性，MVP當然也不列外，我們來看看MVP的優缺點。

優點：

1. 降低耦合度，實現了Model和View真正的完全分離，可以修改View而不影響Modle

2. 模塊職責劃分明顯，層次清晰（下面會介紹Bob大叔的Clean Architecture）

3. 隱藏數據

4. Presenter可以複用，一個Presenter可以用於多個View，而不需要更改Presenter的邏輯（當然是在View的改動不影響業務邏輯的前提下）

5. 利於測試驅動開發。以前的Android開發是難以進行單元測試的（雖然很多Android開發者都沒有寫過測試用例，但是隨着項目變得越來越複雜，沒有測試是很難保證軟件質量的；而且近幾年來Android上的測試框架已經有了長足的發展——開始寫測試用例吧），在使用MVP的項目中Presenter對View是通過接口進行，在對Presenter進行不依賴UI環境的單元測試的時候。可以通過Mock一個View對象，這個對象只需要實現了View的接口即可。然後依賴注入到Presenter中，單元測試的時候就可以完整的測試Presenter應用邏輯的正確性。

6. View可以進行組件化。在MVP當中，View不依賴Model。這樣就可以讓View從特定的業務場景中脫離出來，可以說View可以做到對業務完全無知。它只需要提供一系列接口提供給上層操作。這樣就可以做到高度可複用的View組件。

7. 代碼靈活性

缺點：

1. Presenter中除了應用邏輯以外，還有大量的View->Model，Model->View的手動同步邏輯，造成Presenter比較笨重，維護起來會比較困難。

2. 由於對視圖的渲染放在了Presenter中，所以視圖和Presenter的交互會過於頻繁。

3. 如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯繫過於緊密。一旦視圖需要變更，那麼Presenter也需要變更了。

4. 額外的代碼複雜度及學習成本。

1.6. 小結

在MVP模式裏通常包含4個要素：

(1) View :負責繪製UI元素、與用戶進行交互(在Android中體現爲Activity);

(2) View interface :需要View實現的接口，View通過View interface與Presenter進行交互，降低耦合，方便進行單元測試;

(3) Model :負責存儲、檢索、操縱數據(有時也實現一個Model interface用來降低耦合);

(4) Presenter :作爲View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。

Microsoft對MVC和MVP的理解

二、MVX 剖析

2.1. M（Model）

模型：表示數據模型和業務邏輯(business logic)。模型並不總是DataSet，DataTable之類的東西，它代表着一類組件(components)或類(class)，這些組件或類可以向外部提供數據，同時也能從外部獲取數據並將這些數據存儲在某個地方。簡單的理解，可以把模型想象成“外觀類(facade class)”。譯註：這裏的外觀是指“外觀模式”中所說的外觀。外觀的一般作用是爲一個複雜的子系統提供高層次的簡單易用的訪問接口，可以參看下面的圖來理解它的原理：

model層主要負責：

· 從網絡，數據庫，文件，傳感器，第三方等數據源讀寫數據。

· 對外部的數據類型進行解析轉換爲APP內部數據交由上層處理。

· 對數據的臨時存儲,管理，協調上層數據請求。

2.2 V（View）

視圖：將數據呈現給用戶。一般的視圖都只是包含用戶界面(UI)，而不包含界面邏輯。比如，Asp.net中包含控件的頁面(page)就是一個視圖。視圖可以從模型中讀取數據，但是不能修改或更新模型。

view 層主要負責：

· 提供UI交互

· 在presenter的控制下修改UI。

· 將業務事件交由presenter處理。

注意: View層不存儲數據，不與Model層交互。

在Android中View層一般是Activity、Fragment、View（控件）、ViewGroup（佈局等）等。

2.3. X（C-Controller、P-Presenter、VM-ViewModel）

控制器：View捕獲到用戶交互操作後會直接轉發給Controller，後者完成相應的UI邏輯。如果需要涉及業務功能的調用，Controller會直接調用Model。在完成UI處理之後，Controller會根據需要控制原View或者創建新的View對用戶交互操作予以響應。

層現器：作爲View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。Presenter包含了根據用戶在視圖中的行爲去更新模型的邏輯。視圖僅僅只是將用戶的行爲告知Presenter，而Presenter負責從視圖中取得數據然後發送給模型。

視圖模型：binder 所在之處，是 View 的抽象，對外暴露出公共屬性和命令，它是View的抽象，負責View與Model之間信息轉換，將View的Command傳送到Model。ViewModel的含義就是 "Model of View"，視圖的模型。它的含義包含了領域模型（Domain Model）和視圖的狀態（State）。可以簡單把ViewModel理解爲頁面上所顯示內容的數據抽象，和Domain Model不一樣，ViewModel更適合用來描述View。

2.4. 小結

MVC模式、MVP模式和MVVM模式都作爲用來分離UI層與業務層的一種開發模式。這些模式之間的差異可以歸納爲對這個問題處理的方式的不同。

三、MVX 與三層架構

相信不少童鞋和我有過同樣的疑惑：MVX分爲了M-V-X三層，那這到底和軟件的三層架構有何關係呢？我們帶着問題繼續往下閱讀。

3.1. 什麼是三層架構

三層架構是一個分層式的軟件體系架構設計，它可適用於任何一個項目。通常意義上的三層架構就是將整個業務應用劃分爲：界面層（User Interface layer）、業務邏輯層（Business Logic Layer）、數據訪問層（Data access layer）。區分層次的目的即爲了“高內聚低耦合”的思想。在軟件體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分爲三層，從下至上分別爲：數據訪問層、業務邏輯層（又或稱爲領域層）、表示層。（參考自：百度百科）

常見的架構有：

· 分層架構（如：三層架構）

· 事件驅動架構

· 微內核架構

· 微服務架構

· 基於空間的架構

3.2. 三層架構和 MVX 的關係

首先，我想說三層架構（分層架構）和 MVX 沒有什麼關係，它們不在同一個層次上（三層是一種架構思想，更多的是和事件驅動架構、微內核架構等放在一起討論，而我更喜歡把 MVX 做爲模式來對待）。

三層是從整個應用程序架構的角度來分爲DAL(數據訪問層)、BLL(業務邏輯層)、WEB層（界面層）各司其職，意在職責分離；三層是爲了解決整個應用程序中各個業務操作過程中不同階段的代碼封裝的問題，爲了使程序員更加專注的處理某階段的業務邏輯；並且三層只是多層架構中的一種情況，完全可以根據需要分爲多層。

MVC 主要是爲了解決應用程序用戶界面的樣式替換問題，把展示數據的 HTML 頁面儘可能的和業務代碼分離。MVC把純淨的界面展示邏輯（用戶界面）獨立到一些文件中（Views），把一些和用戶交互的程序邏輯（Controller）單獨放在一些文件中，在 Views 和 Controller 中傳遞數據使用一些專門封裝數據的實體對象，這些對象，統稱爲Models。而在其後出現的 MVP 以及 MVVM 與 MVC 的作用類似，MVX 主要的區別在於如何解決 M 與 V 之間的連接與更新。

總之一句話，MVX 是一種模式，Spring MVC 以及 ASP.NET MVC 等是一個基於MVC模式的開發框架，三層架構是一種架構。

其次，它們都有一個表現層，但是這兩者的展現層並不是一樣的。可以這樣看待 MVX 與三層架構中的表現層的關係，MVX 中的 V 和 X 都屬於三層架構中的表現層，可以看下圖的示意。

最後，雖然都有提到 Model，但是在 MVX 中沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或 MVX 搭建程序最主要的區別。在三層架構中Model 的概念與 MVX 中 Model 的概念是不一樣的，“三層”中典型的Model 層是以實體類構成的，而MVC裏，則是由業務邏輯與訪問數據組成的。

也就是說，MVX 與三層架構說的根本不是一回事。在所謂的“三層”中，它要求你將BLL層獨立出來，它只是告訴你表示層和業務邏輯層之間的靜態關係。而 MVX 則告訴你在這個具體的地方如何處理其動態驅動流程，儘管 MVC 仍然粗糙（甚至 MVP、MVVM也是粗糙的），但是已經比所謂三層更細緻一些了（三層是架構好嗎...）。

MVP和三層架構示意圖

四、Android 上 MVP 的幾種實現

絮絮叨叨說了一大堆，終於乾貨要來了。正所謂：Talk is cheap,show me the code.下面會給出示例代碼，請繼續閱讀。

在 Android 開發中討論 MVP、MVVM 最終都離不了 Uncle Bob 的 The Clean Architecture。（請自行閱讀，相信閱讀原文會有更大的收穫）

下面，我會嘗試一一細數 Android 上常見的 MVP 實現方式（說明：並沒有什麼排序規則，只談大家的實現思路，展示的順序只是爲了方便大家的理解和閱讀）。

4.1. 存取用戶信息的 MVP 小 Demo

這其實是我最先接觸 MVP 時看到的示例，代碼很少，但是把 MVP 的分層展示的挺清晰。

原文：MVP模式在Android開發中的應用

源碼：GitHub 地址

登錄Demo 界面

項目結構示例

4.2. 天氣查詢的 MVP 小 Demo

現在的 Andorid 開發怎麼能夠離開網絡，來一個有網絡的示例。該天氣查詢 Demo，是通過訪問 Web 服務獲取地區的天氣信息（返回爲JSON），然後在 Activity 中用 TextView 展示出來。

原文：Android中的MVP

源碼：GitHub 地址

包結構

項目效果預覽

4.3. 使用 Activity/Fragment 作爲 Presenter 的探索

上面的示例 View 都是 Activity 來承擔的，Presenter 是一個普通的類，前面討論過 Android 在不同場景下會進入不同的生命週期，這將可能導致 Presenter 也隨着其生命週期需要做出響應。從這個角度考慮，有不少開發者提出了 MVP 實現的其他思路，接下來我們要探討的就是使用 Activity/Fragment 作爲 Presenter 的一些實現方案。

4.3.1 一種實現MVP模式的新思路

其中有使用 Activity 和 Fragment 作爲 Presenters 和使用 Adapter作爲 Presenter的探討，思路挺有意思，可以去看看。

原文：android-mvp-an-alternate-approach

譯文：一種在android中實現MVP模式的新思路

源碼：GitHub 地址

4.3.2. TheMVP 介紹

TheMVP使用Activity作爲Presenter層來處理代碼邏輯，通過讓Activity包含一個ViewDelegate對象來間接操作View層對外提供的方法，從而做到完全解耦視圖層。

原文：用MVP架構開發Android應用

源碼：GitHub 地址

TheMVP原理示意

TheMVP項目結構

4.3.3 MVPro 介紹

MVPro的實現很簡單，思想和上面兩篇文章（一種在android中實現MVP模式的新思路和用MVP架構開發Android應用）介紹的一樣，都是將Activity和Fragment作爲Presenter。Presenter即我們的Activity或者Fragment, View呢？說白了就是我們從Activity和Fragment中提取出來的和View操作相關的代碼。

原文：Android MVP框架MVPro的使用和源碼分析

源碼：GitHub 地址

MVPro原理示意

4.4. Nucleus 框架

該框架還是值得一看的，作者 Konstantin Mikheev 對於 MVP 的理解挺有見地。

Nucleus is a simple Android library, which utilizes the Model-View-Presenter pattern to properly connect background tasks with visual parts of an application.

原文：Introduction to Model View Presenter on Android

譯文：介紹ModelViewPresenter在Android中的應用

源碼：GitHub 地址

4.5. Beam 框架

該框架的作者對 MVP 的理解的特點如下：

Activity會在很多情況下被系統重啓：

當用戶旋轉屏幕

在後臺時內存不足

改變語言設置

attache 一個外部顯示器等。

正確的方式應該是：

Presenter與Activity的綁定關係應由靜態類管理。而不是由Activity管理。當Activity意外重啓時Presenter不應重啓。Activity重啓時，Presenter與Activity重新綁定，根據數據恢復Activity狀態。

而當Activity真正銷燬時。對應Presenter才應該跟隨銷燬。

這也是對 Presenter 管理的一個思路，可以參考。

原文：Android應用中MVP最佳實踐

源碼：GitHub 地址

Beam MVP

4.6. Mosby 框架

我給這篇關於Android庫的博客起的名字靈感來源於《老爸老媽浪漫史》中的建築設計師Ted Mosby。這個Mosby庫可以幫助大家在Android上通過Model-View-Presenter模式做出一個完善穩健、可重複使用的軟件，還可以藉助ViewState輕鬆實現屏幕翻轉。

這又是一種解決Activity/Fragment生命週期在屏幕翻轉等場景下對Presenter的處理的思路。

原文：Ted Mosby – Software Architect

譯文：MVP框架 – Ted Mosby的軟件架構

源碼：GitHub 地址

獲得ViewState支持的Activity的生命週期圖解

獲得ViewState支持的Fragment的生命週期圖解

4.7. Loader 的使用

就像剛纔說的一樣，關鍵問題就是在哪裏存儲Presenter以及什麼時候銷燬它們。而我們剛剛就看到了Loader的強大之處：由安卓系統框架提供，有單獨生命週期，會被自動回收且不必在後臺運行。

所以思考一下需求以及Loader的功能，我們可以讓Loader作爲Presenter的提供者，而不需要擔心手機狀態改變。

將同步的Loader作爲存放Presenter的緩存。

這裏的重點就在於同步使用Loader時，我們可以知道在生命週期的哪個階段Presenter被創建了並且可以工作了。甚至是在Activity/Fragment可見之前。

使用Loader，思路很有新意，關鍵確實解決了問題，更關鍵的是使用的是 Android Framework 提供的功能。

原文：Presenter surviving orientation changes with Loaders

譯文：通過Loader延長Presenter生命週期

源碼：GitHub 地址

MVP diagram

4.8. Google 官方推薦

大 Boss 總是最後出場，對於 Android 上 MVP 的實現，Google 給也出了一些建議和實例，趕緊看看去吧。

原文：Android Architecture Blueprints [beta]

源碼：GitHub 地址

Google MVP 示例

4.9. MVP 實現的完整開源項目

4.9.1. Philm

ChrisBannes的開源項目Philm，其整體架構是一套MVP的實現。這裏有一篇分析該項目的文章，可以直接去讀源碼，也可以先看看 lightSky 是怎麼分析的。

Philm 分析：開源項目Philm的MVP架構分析

源碼：GitHub 地址

Philm 的總體設計

Philm 的類關係圖

Philm 的基本調用流程圖

4.9.2. 使用 Beam 開發的 APP

SearchPictureTool 搜圖神器

Fishing 空鉤釣魚

Beam 前面已有介紹，感興趣的童鞋可以看看上面兩個項目。

4.9.3. 乾貨集中營客戶端

乾貨集中營有不少的開源實現都是 MVP 模式的（下面的 App 是官網上列出來的，具體是否都採用了 MVP 本人沒有一一查閱）。

4.10. 小結

上述衆多解決方案都集中在 Presenter 實現的問題上，這主要是由於 Activity、Fragment 的複雜性導致的，它們有衆多生命週期，它們無所不能，是否把它們僅僅視作 View 成了爭論的焦點。個人認爲從編碼的難易程度和編碼的習慣來說，我贊成把 Activity、Fragment 作爲 View 即可，我們可以考慮其他方式來保證Presenter的生命週期和防止 Presenter 引起內存泄漏。其中使用 Loader 的方案就非常優雅，下面在本人的示例項目中也會採用這種方式。