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解耦

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和數據的距離跟遠了。

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的具體實現。每一層對另一層的依賴都是接口依賴，並不關心另一層的具體實現，每一層我們都可以寫不同的實現，隨時切換，這就意味著，有一天如果有一層不好用了，我們可以輕松的重寫另一個實現來替換掉，而不是如履薄冰的修改。

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