MVP現在已經是目前最火的架構，很多的框架都是以MVP為基礎，甚至於Google自己都出一個MVP的開源架構。https://github.com/googlesamples/android-architecture，里面有好幾個項目，我們先談下todo-mvp這個最基礎的MVP架構。
說到MVP，我們不得不談到最最經典的MVC架構。什么是MVC，概括來說就是數據層，控制層以及顯示層的分離。雖然我們可以把所有的代碼都寫在一個類里，但是作為了一個優秀的程序員你我想一定不會這樣做，所以我們想到了解耦，解耦也是擴展性，可測性以及可維護性的基礎。那么最簡單也最通用的解耦就是分層，根據調用關系從上而下或是根據業務的特性，從業務功能分層實現。如jsp+severlet+db的mvc結構就是按照從上到下划分的。Jsp是用於顯示，serverlet是業務控制，db是數據層。MVC的層級結構如下：
Controller響應用戶的操作事件，以及對請求事件的轉發和處理。在事件的處理和轉發過程中會操作Model，對Model進行必要的增，刪，改，查等一系列單一或是組合處理。而Model是在經過Controller的操作后，讓View根據Model刷新自己的狀態，從而呈現給用戶，但是Model是不能直接通知View的，一定要通過Controller 。這個是一個完整的MVC流程。簡易交互如下：
而在android里對應的mvc結構是：V可以理解為控件，C是activity，M是數據。 如果M的變化要通知到V，只能走： M->C->V,這條路徑也就是上圖的體現，這比較常用的，但這種交互有個缺點，就是會導致C很復雜：C作為Activity要進行業務邏輯處理，要控制V的現實邏輯，同時還要做好告知V數據變化的任務。這樣會導致一個角色具有多種功能，這在架構中是很不好的一種表現方式，會使得這個模塊代碼行數多，邏輯復雜，不可測，擴展性差等問題。
為了使得C的功能盡量單一化，所以我們就引入了MVP模式（個人看法），這個P是什么，可以把P看成是一個三角菱鏡，放在了上面的交互中間，所以MVP的交互可以看成：
圖中紅色部分就為P.藍色為原來MVC的調用路線，黑色為MVP的調用路線。通過P的引入，會最大化的釋放C的功能，使得C功能單一化，把業務邏輯處理和告知V數據變化等功能分離給P來處理。這樣C的功能更多的是初始化P,V,M三則之間的關系。
我們來分析下todo-mvp(我們只是從架構層次去分析，不是從業務或是代碼邏輯分析)：下面是todo-mvp一個功能addedittask的UML圖（用的是Gliffy畫的，不是很標准），其他功能類似
每個功能都包含一個Activity,一個或是多個fragment，以及對應的Presenter在這個MVP模式中，Activity已經不是MVP的一部分了，它更多的作用是全局控制，初始化這個三者之間的關系。如何初始化的呢？是通過
new AddEditTaskPresenter(
taskId,
Injection.provideTasksRepository(getApplicationContext()),
addEditTaskFragment);
這行代碼，新建一個TaskPresenter，同時傳入一個TaskRepository和Fragment，進行關聯的。
所有界面顯示的都放在了Fragment里，Frament實現了TaskContract里的View接口，View接口定義了一些顯示操作，具體是什么時候顯示確實由Presenter來決定，因為Presenter實現所有的業務邏輯。Model層為了可擴展性，也通過接口的形式來實現。
每個功能都包含一個Activity,一個或是多個fragment，以及對應的Presenter在這個MVP模式中，Activity已經不是MVP的一部分了，它更多的作用是全局控制，初始化這個三者之間的關系。如何初始化的呢？是通過
new AddEditTaskPresenter(
taskId,
Injection.provideTasksRepository(getApplicationContext()),
addEditTaskFragment);
這行代碼，新建一個TaskPresenter，同時傳入一個TaskRepository和Fragment，進行關聯的。
所有界面顯示的都放在了Fragment里，Frament實現了TaskContract里的View接口，View接口定義了一些顯示操作，具體是什么時候顯示確實由Presenter來決定，因為Presenter實現所有的業務邏輯。Model層為了可擴展性，也通過接口的形式來實現。
這就是整個MVP的框架，這樣的一個好處是：極大的簡化了Activity的功能，同時引入了Presenter，把業務邏輯和Model的入口都放在Presenter。有人擔心這樣會導致Presenter過於龐大，對於這點我說下我的觀點：Presenter不是一個類，完全可以根據業務需要引入多個Presenter。