Android App的架構設計：從VM、MVC、MVP到MVVM

隨著Android應用開發規模的擴大，客戶端業務邏輯也越來越複雜，已然不是簡單的數據展示了。如同後端開發遇到瓶頸時採用的組件拆分思想，客戶端也需要進行架構設計，拆分視圖和數據，解除模塊之間的耦合，提高模塊內部的聚合度。開始之前先上一張內部分享時用的PPT圖：以上是筆者在客戶端開發過程中面臨的問題 ...

隨著Android應用開發規模的擴大，客戶端業務邏輯也越來越複雜，已然不是簡單的數據展示了。如同後端開發遇到瓶頸時採用的組件拆分思想，客戶端也需要進行架構設計，拆分視圖和數據，解除模塊之間的耦合，提高模塊內部的聚合度。

開始之前先上一張內部分享時用的PPT圖：

以上是筆者在客戶端開發過程中面臨的問題，涉及到以下四個主題：

Android App的架構設計：從VM、MVC、MVP到MVVM
Android App的網路訪問：支持REST、HTTPS及SPDY的Retrofit+Okhttp
Android App的響應式編程：RxJava/RxAndroid解決方案
Android App的依賴註入：Dagger2和ButterKnife使用

本文將從架構設計入手，分享筆者在Android開發中採用MVC、MVP及MVVM的一些想法。

一、Android原生開發中的MVC

Android原生開發採用XML文件實現頁面佈局，通過Java在Activity中開發業務邏輯，這種開發模式實際上已經採用了MVC的思想，分離視圖和控制器。MVC模式（Model–view–controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。

MVC模式最早由Trygve Reenskaug在1978年提出，是施樂帕羅奧多研究中心（Xerox
PARC）在20世紀80年代為程式語言Smalltalk發明的一種軟體架構。MVC模式的目的是實現一種動態的程式設計，使後續對程式的修改和擴展簡化，並且使程式某一部分的重覆利用成為可能。除此之外，此模式通過對複雜度的簡化，使程式結構更加直觀。軟體系統通過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員可以通過自身的專長分組：

控制器（Controller）- 負責轉發請求，對請求進行處理。

視圖（View） - 界面設計人員進行圖形界面設計。

模型（Model） - 程式員編寫程式應有的功能（實現演算法等等）、資料庫專家進行數據管理和資料庫設計(可以實現具體的功能)。

——以上內容來自《維基百科》

在Android編程中，View對應xml佈局文件，Model對應實體模型（網路、資料庫、I/O），Controller對應Activity業務邏輯，數據處理和UI處理。如下圖所示。

圖片來自互聯網

但在實際開發過程中，純粹作為View的各個XML文件功能較弱，Activity基本上都是View和Controller的合體，既要負責視圖的顯示又要加入控制邏輯，承擔的功能很多，導致代碼量很大。所有更貼切的目前常規的開發說應該是View-Model模式，大部分都是通過Activity的協調，連接處理邏輯的。

二、從MVC過渡到MVP

在業務邏輯稍微複雜一點的頁面，Activity的代碼超過一千是很容易的，如果作者又剛好讀過《如何寫出無法維護的代碼》，那麼恭喜後來接手該代碼的童鞋，接下來的幾個月會很酸爽的。。。

既然Activity存在代碼量過大的問題，那自然會想到進行拆分。上節說到Android原生開發採用了MVC的思想，但Activity並不是一個標準的MVC模式中的Controller，它的首要職責是載入應用的佈局和初始化用戶界面，並接受並處理來自用戶的操作請求，進而作出響應。隨著界面及其邏輯的複雜度不斷提升，Activity類的職責不斷增加，以致變得龐大臃腫。

MVP是從MVC過渡而來，MVP框架由三部分組成：View負責顯示，Presenter負責邏輯處理，Model提供數據。Android開發從MVC過渡到MVP，最主要的變化就是將Activity中負責業務邏輯的代碼移到Presenter中，Activity只充當MVP中的View，負責界面初始化以及建立界面控制項與Presenter的關聯。

這樣拆分之後，Presenter承擔了大量的邏輯操作，避免了Activity的臃腫。整個架構如下圖所示。

圖片來自互聯網

View(Activity)負責響應用戶操作，通過Presenter暴露的方法請求數據；
Presenter在獲取數據後，通過View(Activity)暴露的方法實現界面控制（showLoading/showUsers）；
Presenter的數據是通過Model來獲取的，Model包含網路、資料庫以及I/O等；
Model通過回調的方式將數據傳到Presenter中。

採用MVP明顯的優點是避免了傳統開發模式中View和Model耦合的情況，提高了代碼可擴展性、組件復用能力、團隊協作的效率以及單元測試的便利性。但也有一些缺點，比如：

Model到Presenter的數據傳遞過程需要通過回調；
View(Activity)需要持有Presenter的引用，同時，Presenter也需要持有View(Activity)的引用，增加了控制的複雜度；
MVC中Activity的代碼很臃腫，轉移到MVP的Presenter中，同樣造成了Presenter在業務邏輯複雜時的代碼臃腫。

三、從Presenter到ViewModel

MVVM是Model-View-ViewModel的簡稱，從實際效果來看，ViewModel是View的數據模型和Presenter的結合，具體結構如下圖所示：

圖片來自互聯網

View（視圖層）採用XML文件進行界面的描述；
Model（模型層）通過網路和本地資料庫獲取視圖層所需數據；
ViewModel（視圖-模型層）負責View和Model之間的通信，以此分離視圖和數據。

View和Model之間通過Android Data Binding技術，實現視圖和數據的雙向綁定；ViewModel持有Model的引用，通過Model的方法請求數據；獲取數據後，通過Callback（回調）的方式回到ViewModel中，由於ViewModel與View的雙向綁定，使得界面得以實時更新。同時，界面輸入的數據變化時，由於雙向綁定技術，ViewModel中的數據得以實時更新，提高了數據採集的效率。

採用ViewModel解決MVP中View(Activity)和Presenter相互持有對方應用的問題，界面由數據進行驅動，響應界面操作無需由View(Activity)傳遞，數據的變化也無需Presenter調用View(Activity)實現，使得數據傳遞的過程更加簡潔，高效。

在Android中實現MVVM架構的核心支撐技術是Google去年I/O大會開源的Data binding技術，這項技術的思想並不新穎，最初由微軟提出，在前端開發中已經有成熟的應用。下麵對其進行簡要的介紹。

四、Android中的Data Binding

學習Data Binding主要推薦兩個內容：

這兩篇文章中已經將Data Binding的基本內容描述的很詳細了。這裡僅列兩個在實踐中遇到的坑，拋磚引玉。

ObservableField的get方法可能無法返回界面實時更新的內容

public ObservableField<String> username = new ObservableField<>();

上述username表示用戶名，在界面上可能會與EditText綁定。通過username的set方法可以設置EditText顯示，但如果輸入變更後，通過get方法卻不一定能及時返回界面的數據。

Data Binding依然有很多支持的不好的組件（listview，recyclerView等），不可能通過給所有組件綁定ViewModel從而實現Activity沒有業務邏輯操作。另外，ViewModel獲取數據之後，也不可能把所有數據直接綁定到界面，有些也需要通過回調傳到Activity中。

從MVC、MVP到MVVM，實際上是模型和視圖的分離過程。MVC中模型和視圖沒有完全分離，造成Activity代碼臃腫，MVP中通過Presenter來進行中轉，模型和視圖徹底分離，但由於V和P互相引用，代碼不夠優雅。ViewModel通過Data Binding實現了視圖和數據的綁定，解決了這種MVP的缺陷，但目前也存在Data Binding還不成熟的問題。

其實，MVC、MVP及MVVM沒有絕對好壞，在軟體編程過程中，也沒必要非此即彼，最重要的是讓軟體高內聚、低耦合、可維護、可擴展，至於架構，根據實際情況選擇吧。