Android應用開發架構概述

通常一個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：V在MVC架構中Activity（託管Fragment，View，WebView等）首先充當V的角色。

M：業務邏輯層劃分出來專門處理資料。例如：資料的http請求，資料解析和儲存等邏輯都封裝在這一層。Activity 不直接和Http，Dao（資料訪問物件層）直接有聯絡了，檢視資料從此為路人。

C：C是什麼？

MVC這個概念，在移動應用開發出現之前就已經產生了，最經典的使用場景：JSP +servlet+javabean，我開始接觸MVC頁是在做JavaWeb開發的時候。後來Android開發火了，把這套模式搬上來。但是控制器（C）的概念在Android應用開發中不太好理解，也只能很狹義的理解為接受或控制事件或邏輯層的回撥響應，所以在Android應用開發中，套上MVC，Activity 兼具V和C的角色。

MVP解耦

很多時候檢視層面還是充斥中很多複雜的邏輯，例如UI事件的響應處理，網路響應的回撥等等，充斥著各種監聽器的回撥。我們期望檢視V便當更簡單、更純粹，V只負責繪製和重新整理其他邏輯都不用管了，也不想和M有直接的聯絡。從MVC的VC（Activity）中我們分離一層出來叫做Presenter，由它來負責排程UI何時重新整理、由它來接受UI的事件響應並傳達指令給M。從此V和M是路人，V和資料的距離跟遠了。

V：Activity為代表，這時候的Activity更為簡單了，只負責UI的繪製和重新整理。

P：負責傳達指令。向上接收V的事件指令並需要的時候傳達給M，向下接收M的指令並通知V重新整理UI。

M：只負責出來資料邏輯。其實還可以細分一些東西，比如Http請求，很多時候我們的Http框架都是用的第三方開源框架，如果有一天更優秀的框架出現了，要更換，怎麼才能做到不影響其他層次？如果我門做了分層隔離那麼，我門可以很輕鬆的換掉，如果沒有做分層隔離，那麼我門可能要在每一個功能模組的M中修改程式碼，修改代價是巨大的，所以一遍第三方開源框架我都不會直接使用而是在業務上做一層抽象隔離。同理，本地資料的儲存，也有必要做響應的封裝或隔離，因為今天是用Litepal，也許某一天想用GreenDao了，只需要修改封裝類的程式碼就好了。

MVP的依賴關係：

MVP類圖：

我們把每一層都抽象成一個介面，例如V層，我們定義一個介面為View（不要和Android API裡的View弄混了），讓後Activity為這個View的具體實現。每一層對另一層的依賴都是介面依賴，並不關心另一層的具體實現，每一層我們都可以寫不同的實現，隨時切換，這就意味著，有一天如果有一層不好用了，我們可以輕鬆的重寫另一個實現來替換掉，而不是如履薄冰的修改。

MVP demo：https://github.com/liuguangli/androidmvp