深入淺出Android MVP模式
什麼是MVP模式
MVP是針對有GUI存在的應用程序，比如像安卓，像水果以及PC的客戶端軟件中用以劃分組織代碼的一種設計模式，是由MVC模式升級演進出來的，目的在於，對於GUI層來說，把UI展示與邏輯分開。
Model – 爲UI層提供的數據，或者保存UI層傳下來的數據
View – 單純的展示數據，響應用戶操作並都轉發給Presenter來做具體的處理
Presenter – 邏輯控制層，從Model處取數據，運算和轉化，最後用View來展示；並處理View傳過來的用戶事件，並做處理。需要注意的是MVP僅用於應用中的GUI部分，它並不是整個應用的架構方式。一個應用的主要的架構應該包括基礎組件，業務邏輯層和GUI展示層，而MVP僅是用於展示層的設計模式。另外，它是一個方法論的東西，沒有固定的實現方式，只要能體現出它的方法就可以算是MVP。
雖然是方法論，但是也有一些指導性的原則來約束實現：
Model與View不能直接通信，只能通過Presenter
Presenter類似於中間人的角色進行協調和調度
Model和View是接口，Presenter持有的是一個Model接口和一個View接口
Model和View都應該是被動的，一切都由Presenter來主導
Model應該把與業務邏輯層的交互封裝掉，換句話說Presenter和View不應該知道業務邏輯層
View的邏輯應該儘可能的簡單，不應該有狀態。當事件發生時，調用Presenter來處理，並且不傳參數，Presenter處理時再調用View的方法來獲取。
從這裏可以看的出來，其實，MVP的目的就是把GUI的邏輯都集中在Presenter層，又把View層和Model與其用接口分離，讓View儘可能的簡單，這樣可以加強移植性。因爲View層是肯定不能移植的，不同的平臺GUI的窗口部件肯定不一樣，Model也是不太好移植的，因爲每個平臺的IO也都是不一樣的。但是，MVP中的P肯定是可以移植的，因爲它裏面只有邏輯，且View和Model都是接口，所以很容易移植。同時，因爲View和Model都是接口，這個Presenter也非常好測試，只要實現一個View的接口和Model的接口，就可以單獨的測試Presenter了。
嚴格來講，View只是被動的顯示，提供方法由Presenter來調用，數據等都是由Presenter來提供，內部不能任何的邏輯與狀態，邏輯和狀態都應該是在Presenter中。UI事件發生時，調用Presenter的方法來處理，不能傳參數，也不能有返回值，在Presenter中處理後再調用View來更新數據和狀態。
MVP與MVC的區別
MVC之中邏輯是放在了Model裏，Controller負責橋接View和Model，View發生變化時通知Controller，Controller再通知Model，Model進行邏輯處理，更新數據，然後通知View來刷新。可以看到MVC中三者之間都有聯繫，如果處理不好，或者當View比較複雜時，三者之間都會雙向關聯。MVC在命令行應用，以及WEB中有大量的應用，但對於客戶端（PC和移動端）的GUI應用，MVC往往解決不了複雜性，移植性上以及可測試性上也沒有優勢。
MVP的改進在於：
邏輯放在Presenter中
View和Model抽象成爲接口這樣就帶了二個好處：
代碼更加容易移植
代碼更加容易加入Unit Testing如何在安卓中實踐MVP
MVP是一個方法論的東西，也就是沒有任何固定的具體的實現形式，只要能夠把View跟Model解除聯繫，把邏輯都放在Presenter中，那麼就能算得上是MVP，一些具體的實踐的指導性原則：
View是一個接口，負責被動的把處理好的數據顯示出來
Model也是一個接口，負責獲取數據和存儲數據
View調用Presenter處理用戶事件也是一個接口，稱爲事件Delegate
Presenter持有的是View的接口和Model接口安卓的Activity是一個比較奇葩的角色，在MVP中，既可以用作V，因爲一個應用的根佈局總是由Activity來創建的。當然也可以當作P，因爲Activity是一個應用的入口，也是出口，再加上一些關鍵的系統事件也都是通過Activity的方法來通知的（比如configChange, saveInstance）。其實，都可以。因爲MVP是方法論，並沒有固定的形式，只要是把數據處理的邏輯都封裝在Presenter裏，讓其去控制View和Model，讓Activity來承擔View還是Presenter，其實都可以。