回顧上一篇文章《android應用架構概述》，我們知道，android
app 本質上抽象成兩個層次：視圖和資料。為了app在發展過程中快速的适應變化，友善維護和快速疊代，我們要将資料和視圖解耦，而在解藕方面我們的前輩們在漫長的軟體開發經驗中為我們提供了兩套流行的指導架構：mvc和mvp，其中mvp近年來在android應用開發上逐漸流行。接着上一篇的内容，本章我将結合具體例子說清mvp解藕的實作。是以本章的思路是：以登入為業務場景，分析對比“非mvp”和mvp的實作方式。demo位址：https://github.com/liuguangli/mvpteach
簡單的登入場景。送出登入資訊（使用者名和密碼），處理登入邏輯，傳回使用者資訊并儲存。
在沒有任何分層的指導思想下，我們往往或把視圖邏輯資料邏輯都耦合到activity中來實作。
登入按鈕的響應方法：
登入檢查：
登入到伺服器：
在這裡，activity和http架構（android－ansyc－http）以及整改資料請求邏輯耦合了。如果以後登入邏輯變化了，那麼app所有和登入邏輯相關的頁面都會受到牽連；或者http架構更換了，所有activity都要受到牽連。（本demo隻有一條業務場景一個activiy展現不出影響的嚴重性，一個完整的app就能展現出來了）
儲存資料：
資料儲存的方式有很多中，也可能會随着需求的變化而選擇不同的方式，同理，如果所有的activiy都這樣耦合，那麼日後想要切換更合适的存儲方式将變得寸步難行。
沿着《android應用架構概述》的思路，我們先把登入這個業務場景實作的層次圖畫出來。
類圖：
資料請求和處理邏輯交出去了。至此，activity變的簡單，隻負責ui的變化行為，資料請求和處理邏輯的具體實作對它沒有影響。
loginpresenterimp作為loginpresenter的實作類。它的任務和職責是：一、接受loginactivity送出的登入指令并向loginmanager傳遞任務（真正的請求在loginmanagerimp中執行）。二、接受loginmanagerimp回調的結果。
loginmanager才是正真處理業務邏輯的家夥，它和兩個子產品有直接聯系。它的職責：一、把來自ui的資料解析成網絡架構層所需格式并調用網絡架構層請求伺服器資料。二、調用本地資料通路層（dao）存取資料。三、向presenter傳遞資料。
任何東西都有兩面性，mvp雖然為資料視圖解耦提供了很好的指導思想，但是我門發現層次變多了，調用棧變多了。着就要求開發人員能夠清晰的認識業務劃分，清楚的知道mvp中，那個層次該做什麼、哪個層次不該做什麼。例如：就就面的實作，我門做一點變化：
正如圖注釋所訴，雖然在形式結構上作了mvp的設計，但因為層次職責沒化清，view層作了mode該作的事情，并沒有達到解耦的目的。
demo:https://github.com/liuguangli/mvpteach