通常一個(gè)App的成長(zhǎng)過(guò)程都是這樣的：
第一階：先用最少的成本和時(shí)間快速把東西做出來(lái)侨糟。
第二階段：積累一定用戶(hù)量之后再小步快跑的迭代功能联四。
第三階段：性能和體驗(yàn)上逐步求精扰才。
我發(fā)現(xiàn)好多項(xiàng)目在第二階段和第三階段耗費(fèi)了好多本來(lái)不應(yīng)該浪費(fèi)的人力成本雄右、時(shí)間成本剃诅。究其原因就是因?yàn)榍捌诤雎粤撕侠淼募軜?gòu)巷送，我甚至經(jīng)歷過(guò)因?yàn)榍捌诘脑O(shè)計(jì)不合理導(dǎo)致后期技術(shù)債務(wù)太多項(xiàng)目瀕臨死掉、整個(gè)項(xiàng)目組全員換掉重造鍋爐的境地矛辕。所以笑跛，我們?yōu)槭裁床患饶苁褂米詈?jiǎn)潔的方式實(shí)現(xiàn)功又能要保證后期靈活的擴(kuò)展能力呢？下面是本人最近項(xiàng)目實(shí)踐的一些整理聊品，拋磚引玉飞蹂，希望一起討論。文章首發(fā)：http://www.liuguangli.win/archives/299翻屈。
視圖和數(shù)據(jù)
好的代碼一定是層次分明陈哑、職責(zé)分明，糟糕的代碼架構(gòu)就是沒(méi)有層次沒(méi)有模塊伸眶，每次修改代碼都是牽一發(fā)動(dòng)全身芥颈。從大的方面來(lái)講Android應(yīng)用都會(huì)被分為兩層：視圖層、數(shù)據(jù)層赚抡。
視圖：一般以Activity為依托的各種View，包含View纠屋、ViewGroup和WebView涂臣，還有各種fragment。
數(shù)據(jù)：支撐整個(gè)應(yīng)用邏輯的數(shù)據(jù)售担，分為兩類(lèi)赁遗。一類(lèi)存儲(chǔ)在遠(yuǎn)端服務(wù)器上的，一類(lèi)在本地族铆。遠(yuǎn)端數(shù)據(jù)需要通過(guò)網(wǎng)絡(luò)（通常是Http）獲取岩四，本地?cái)?shù)據(jù)包括sqlite存儲(chǔ)的關(guān)系型數(shù)據(jù)，文件系統(tǒng)哥攘，內(nèi)存緩存對(duì)象剖煌。
必然聯(lián)系
用數(shù)據(jù)驅(qū)動(dòng)視圖變化材鹦，這才產(chǎn)生了豐富多彩的應(yīng)用交互世界，所以耕姊，視圖和數(shù)據(jù)的聯(lián)系是必然的桶唐。
在Android平臺(tái)和整個(gè)移動(dòng)開(kāi)發(fā)生態(tài)都發(fā)展的非常快茉兰，在Android興起之初尤泽，對(duì)層的重要性不是太強(qiáng)調(diào)，所有很多開(kāi)始寫(xiě)Android程序的開(kāi)發(fā)對(duì)層劃分不是太清晰 规脸，看到很多入門(mén)書(shū)本里很多直接在Activity里面直接處理數(shù)據(jù)的代碼坯约，例如直接在Activity里面直接調(diào)SharedPrefrence操作數(shù)據(jù)，直接在Activity 里面直接調(diào)用網(wǎng)絡(luò)請(qǐng)求等莫鸭，很多初級(jí)選手的很容易寫(xiě)出這樣沒(méi)有層次的代碼出來(lái)闹丐。當(dāng)接口變更，當(dāng)存儲(chǔ)方式更好的時(shí)候整個(gè)UI層面的邏輯都受影響黔龟。
解耦
好一點(diǎn)的設(shè)計(jì)必然會(huì)做一次隔離：盡量做到UI和數(shù)據(jù)彼此透明妇智、“互不干涉內(nèi)政”。
隔離的好處是：一氏身、 提高可維護(hù)性巍棱。在UI邏輯發(fā)生變化甚至整個(gè)端掉都不會(huì)影響到處理邏輯。二蛋欣、 提高可復(fù)用性航徙。復(fù)用通常只數(shù)據(jù)的復(fù)用，數(shù)據(jù)邏輯不受UI的左右陷虎，由此可以服務(wù)于多個(gè)UI視圖到踏。三、 可讀性尚猿。層次分清之后按照統(tǒng)一的架構(gòu)思路去理解代碼窝稿，當(dāng)然還得靠開(kāi)發(fā)人員良好的編程素養(yǎng)和代碼規(guī)范。
那么怎么做到隔離呢凿掂？關(guān)于解耦伴榔，業(yè)內(nèi)比統(tǒng)一的可以歸納為兩種：MVC、MVP（MVVM）庄萎。
MVC解耦
V：在MVC架構(gòu)中Activity（托管Fragment踪少，View，WebView等）首先充當(dāng)V的角色糠涛。
M：業(yè)務(wù)邏輯層劃分出來(lái)專(zhuān)門(mén)處理數(shù)據(jù)援奢。例如：數(shù)據(jù)的http請(qǐng)求，數(shù)據(jù)解析和儲(chǔ)存等邏輯都封裝在這一層忍捡。Activity不直接和Http集漾，Dao（數(shù)據(jù)訪問(wèn)對(duì)象層）直接有聯(lián)系了切黔，視圖數(shù)據(jù)從此為路人。
C：C是什么帆竹？MVC這個(gè)模式及概念绕娘，在移動(dòng)應(yīng)用開(kāi)發(fā)出新之前就已經(jīng)產(chǎn)生了，最經(jīng)典的水用場(chǎng)景JSP +servlet+javabean栽连，我開(kāi)始接觸MVC也是在做JavaWeb開(kāi)發(fā)的時(shí)候险领。后來(lái)Android開(kāi)發(fā)火了，把這套模式搬上來(lái)秒紧。但是C套上了不太好理解绢陌。Android應(yīng)用開(kāi)發(fā)中，套上MVC熔恢，Activity 兼具V和C的角色脐湾。
MVP解耦
很多時(shí)候視圖層面還是充斥中很多復(fù)雜的邏輯，例如UI事件的響應(yīng)處理叙淌，網(wǎng)絡(luò)響應(yīng)的回調(diào)等等秤掌，充斥著各種監(jiān)聽(tīng)器的回調(diào)。我們期望視圖V便當(dāng)更簡(jiǎn)單鹰霍、更純粹闻鉴，V只負(fù)責(zé)繪制和刷新其他邏輯都不用管了，也不想和M有直接的聯(lián)系茂洒。從MVC的VC（Activity）中我們分離一層出來(lái)叫做Presenter孟岛，由它來(lái)負(fù)責(zé)調(diào)度UI何時(shí)刷新、由它來(lái)接受UI的事件響應(yīng)并傳達(dá)指令給M督勺。從此V和M是路人渠羞，V和數(shù)據(jù)的距離跟遠(yuǎn)了。
V：Activity為代表智哀，這時(shí)候的Activity更為簡(jiǎn)單了次询，只負(fù)責(zé)UI的繪制和刷新。
P：負(fù)責(zé)傳達(dá)指令瓷叫。向上接收V的事件指令并需要的時(shí)候傳達(dá)給M渗蟹，向下接收M的指令并通知V刷新UI。
M：只負(fù)責(zé)出來(lái)數(shù)據(jù)邏輯赞辩。其實(shí)還可以細(xì)分一些東西，比如Http請(qǐng)求授艰，很多時(shí)候我們的Http框架都是用的第三方開(kāi)源框架辨嗽，如果有一天更優(yōu)秀的框架出現(xiàn)了，要更換淮腾，怎么才能做到不影響其他層次糟需？如果我門(mén)做了分層隔離那么屉佳，我門(mén)可以很輕松的換掉，如果沒(méi)有做分層隔離洲押，那么我門(mén)可能要在每一個(gè)功能模塊的M中修改代碼武花，修改代價(jià)是巨大的，所以一遍第三方開(kāi)源框架我都不會(huì)直接使用而是在業(yè)務(wù)上做一層抽象隔離杈帐。同理体箕，本地?cái)?shù)據(jù)的存儲(chǔ)，也有必要做響應(yīng)的封裝或隔離挑童，因?yàn)榻裉焓怯肔itepal累铅，也許某一天想用GreenDao了，只需要修改封裝類(lèi)的代碼就好了站叼。
MVP的依賴(lài)關(guān)系：
MVP類(lèi)圖：
我們把每一層都抽象成一個(gè)接口娃兽，例如V層，我們定義一個(gè)接口為View（不要和Android API里的View弄混了）尽楔，讓后Activity成為這個(gè)View的具體實(shí)現(xiàn)投储。每一層對(duì)另一層的依賴(lài)都是接口依賴(lài)，并不關(guān)心另一層的具體實(shí)現(xiàn)阔馋，每一層我們都可以寫(xiě)不同的實(shí)現(xiàn)玛荞，隨時(shí)切換，這就意味著垦缅，有一天如果有一層不好用了冲泥，我們可以輕松的重寫(xiě)另一個(gè)實(shí)現(xiàn)來(lái)替換掉，而不是如履薄冰的修改壁涎。
MVP demo
https://github.com/liuguangli/androidmvp
下篇文章將以登錄為業(yè)務(wù)場(chǎng)景分析MVP的具體實(shí)現(xiàn)凡恍。下篇：《Android應(yīng)用架構(gòu)之MVP實(shí)現(xiàn)》
