通常一個app的成長過程都是這樣的：
第一階：先用最少的成本和時間快速把東西做出來。
第二階段：積累一定使用者量之後再小步快跑的疊代功能。
第三階段：性能和體驗上逐漸求精。
好的代碼一定是層次分明、職責分明，糟糕的代碼架構就是沒有層次沒有子產品，每次修改代碼都是牽一發動全身。從大的方面來講android應用都會被分為兩層：視圖層、資料層。
資料和視圖
視圖：一般以activity為依托的各種view，包含view、viewgroup和webview，還有各種fragment。
資料：支撐整個應用邏輯的資料，分為兩類。一類存儲在遠端伺服器上的，一類在本地。遠端資料需要通過網絡（通常是http）擷取，本地資料包括sqlite存儲的關系型資料，檔案系統，記憶體緩存對象。
用資料驅動視圖變化，這才産生了豐富多彩的應用互動世界，是以，視圖和資料的聯系是必然的。
視圖資料的直接聯系
在android平台和整個移動開發生态都發展的非常快，在android興起之初，對層的重要性不是太強調，所有很多開始寫android程式的開發對層劃分不是太清晰 ，看到很多入門書本裡很多直接在activity裡面直接處理資料的代碼，例如直接在activity裡面直接調sharedprefrence操作資料，直接在activity 裡面直接調用網絡請求等，很多初級選手的很容易寫出這樣沒有層次的代碼出來。當接口變更，當存儲方式更好的時候整個ui層面的邏輯都受影響。
好一點的設計必然會做一次隔離：盡量做到ui和資料彼此透明、“互不幹涉内政”。
解耦
隔離的好處是：一、 提高可維護性。在ui邏輯發生變化甚至整個端掉都不會影響到處理邏輯。二、 提高可複用性。複用通常隻資料的複用，資料邏輯不受ui的左右，由此可以服務于多個ui視圖。三、 可讀性。層次厘清之後按照統一的架構思路去了解代碼，當然還得靠開發人員良好的程式設計素養和代碼規範。
那麼怎麼做到隔離呢？關于解耦，業内比統一的可以歸納為兩種：mvc、mvp（mvvm）。
mvc
v：在mvc架構中activity（托管fragment，view，webview等）首先充當v的角色。
m：業務邏輯層劃分出來專門處理資料。例如：資料的http請求，資料解析和儲存等邏輯都封裝在這一層。activity不直接和http，dao（資料通路對象層）直接有聯系了，視圖資料從此為路人。
很多時候視圖層面還是充斥中很多複雜的邏輯，例如ui事件的響應處理，網絡響應的回調等等，充斥着各種監聽器的回調。我們期望視圖v便當更簡單、更純粹，v隻負責繪制和重新整理其他邏輯都不用管了，也不想和m有直接的聯系。從mvc的vc（activity）中我們分離一層出來叫做presenter，由它來負責排程ui何時重新整理、由它來接受ui的事件響應并傳達指令給m。從此v和m是路人，v和資料的距離跟遠了。
mvp
v：activity為代表，這時候的activity更為簡單了，隻負責ui的繪制和重新整理。
p：負責傳達指令。向上接收v的事件指令并需要的時候傳達給m，向下接收m的指令并通知v重新整理ui。
m：隻負責出來資料邏輯。其實還可以細分一些東西，比如http請求，很多時候我們的http架構都是用的第三方開源架構，如果有一天更優秀的架構出現了，要更換，怎麼才能做到不影響其他層次？如果我門做了分層隔離那麼，我門可以很輕松的換掉，如果沒有做分層隔離，那麼我門可能要在每一個功能子產品的m中修改代碼，修改代價是巨大的，是以一遍第三方開源架構我都不會直接使用而是在業務上做一層抽象隔離。同理，本地資料的存儲，也有必要做響應的封裝或隔離，因為今天是用litepal，也許某一天想用greendao了，隻需要修改封裝類的代碼就好了。
mvp的依賴關系：
mvp依賴關系
mvp類圖：
mvp類圖
我們把每一層都抽象成一個接口，例如v層，我們定義一個接口為view（不要和android api裡的view弄混了），讓後activity成為這個view的具體實作。每一層對另一層的依賴都是接口依賴，并不關心另一層的具體實作，每一層我們都可以寫不同的實作，随時切換，這就意味着，有一天如果有一層不好用了，我們可以輕松的重寫另一個實作來替換掉，而不是如履薄冰的修改。
<a href="https://github.com/liuguangli/androidmvp" target="_blank">https://github.com/liuguangli/androidmvp</a>
未完待續...
關于架構與解耦，并非一篇部落格文章就能說清楚的，文章如有不足之處懇請指正，後續有時間還會做相關補充總結。