作者：黃俊彬（http://huangjunbin.com/）
責編：錢曙光（[email protected]）
作者授權CSDN釋出，如需轉載請聯絡作者本人。

前言

Android的開發生態系統發展迅速，在開發Android的幾年的時間裡，用來構建Android應用的架構與技術一直在不斷進化。隨著專案的不斷更新迭代，應用的架構也有不一樣的變化。由於開發人員的數量、專案的業務複雜度、需求的開發時間、應用的使用量級，使用的技術架構也不相同。沒有最好的架構，只有最合適的。通過設計使程式模組化，做到模組內部的高聚合和模組之間的低耦合。這樣做的好處是使得程式在開發的過程中，開發人員只需要專注於一點，提高程式開發的效率，便於專案的後期維護。下面總結及彙總一下目前Android使用的主要應用架構及其優缺點和使用的學習心得，如有不對之處，歡迎交流糾正。

mvc

還記得以前學生時代學習.NET的時候，第一次接觸到專案架構叫三層架構。應用層、業務邏輯層及資料訪問層。mvc的思想其實也一樣，都是一種軟體設計典範，用一種業務邏輯、資料、介面顯示分離的方法組織程式碼，在改進和個性化定製介面及使用者互動的同時，不需要重新編寫業務邏輯。Android的專案設計本身也是採用了mvc的設計思想。

• 檢視層(View)
  一般採用XML檔案進行介面的描述，使用的時候可以非常方便的引入。同時便於後期介面的修改。邏輯中與介面對應的id不變化則程式碼不用修改，大大增強了程式碼的可維護性。
• 控制層(Controller)
  Android的控制層主要就是Activity層。相關View層互動觸發及資料展示邏輯都在Activity中進行編碼。
• 模型層(Model)

我們通常針對業務資料，都會定義好對應的Model層。資料庫的操作、對網路等的操作都應該在Model裡面處理，當然對業務計算等操作也是必須放在的該層的

所以一直以來我們使用Android預設的專案結構開發，主要都是在採用mvc的架構思想。

優點： 適用了簡單的頁面展示，業務邏輯不復雜。開發效果高，程式碼層級也簡單易懂

缺點： 當業務複雜時，Activity非常臃腫，不便於維護及測試

mvp

mvp這是目前我們專案中主要採用的應用架構方式，MVP從更早的MVC框架演變過來，與MVC有一定的相似性：Controller/Presenter負責邏輯的處理，Model提供資料，View負責顯示。mvp架構的演變，解決了Activity程式碼臃腫的問題，當我們將Activity複雜的邏輯處理移至另外的一個類（Presenter）中時，Activity其實就是MVP模式中的View，它負責UI元素的初始化，建立UI元素與Presenter的關聯（Listener之類），同時自己也會處理一些簡單的邏輯（複雜的邏輯交由 Presenter處理）。專案開發中，UI是容易變化的，且是多樣的，一樣的資料會有N種顯示方式；業務邏輯也是比較容易變化的。為了使得應用具有較大的彈性，我們期望將UI、邏輯（UI的邏輯和業務邏輯）和資料隔離開來，而MVP是一個很好的選擇。在MVP模式裡通常包含3個要素（加上View interface是4個）：

• View:負責繪製UI元素、與使用者進行互動(在Android中體現為Activity)
• Model:負責儲存、檢索、操縱資料(有時也實現一個Model interface用來降低耦合)
• Presenter:作為View與Model互動的中間紐帶，處理與使用者互動的負責邏輯。
• View interface:需要View實現的介面，View通過View interface與Presenter進行互動，降低耦合，方便進行單元測試

優點：

1. Model與View完全分離，修改互不影響
2. 更高效地使用，因為所有的邏輯互動都發生在一個地方—Presenter內部
3. 一個Preseter可用於多個View，而不需要改變Presenter的邏輯（因為View的變化總是比Model的變化頻繁）。
4. 更便於測試。把邏輯放在Presenter中，就可以脫離使用者介面來測試邏輯（單元測試）

缺點：需要拿捏好Presenter、View interface的顆粒度設計，容易出現Presenter過於簡單或則複雜化。

mvvm

MVVM可以算是MVP的升級版，其中的VM是ViewModel的縮寫，ViewModel可以理解成是View的資料模型和Presenter的合體，ViewModel和View之間的互動通過Data Binding完成，而Data Binding可以實現雙向的互動，這就使得檢視和控制層之間的耦合程度進一步降低，關注點分離更為徹底，同時減輕了Activity的壓力

• 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)實現，使得資料傳遞的過程更加簡潔，高效。

推薦教程：

優點：

• 雙向繫結技術，當Model變化時，View-Model會自動更新，View也會自動變化。很好做到資料的一致性
• Google官方支援databing，易於整合

缺點：

• 資料繫結使得 Bug 很難被除錯
• 資料雙向繫結不利於程式碼重用及擴充套件
• 程式碼的閱讀性降低

android-architecture

google在官方示例中給出了一系列不同架構的app實現，專案目的是通過展示各種架構app的不同方式來幫助開發者解決架構問題。專案中通過不同的架構概念及方式實現了功能相同的app。

TODO-MVP-RXJAVA

使用RXJAVA對資料流進行處理，並且通過Repository進行資料的集中管理，通過協議類XXXContract來對View和Presenter的介面進行內部繼承，在presenter的實現類中，可以對Model資料進行操作。例項中，資料的獲取、儲存、資料狀態變化都是model層的任務，presenter會根據需要呼叫該層的資料處理邏輯並在需要時將回調傳入。這樣model、presenter、view都只處理各自的任務，實現單一責任原則。

推薦教程：

元件化

隨著專案的推進，及企業業務的發展。有一天可以發現團隊內部需要開發多個APP，且多個APP中存在相同的業務模組，一開始的做法為了趕專案進度可能就是黏貼複製，到後面就慢慢發現越來越吃力，重複勞動。

慢慢隨著時間的推移，惡性迴圈。慢慢發現專案程式碼結構混亂、層次不清，各業務技術方案不統一；甚至連基本的包結構也是胡亂不堪，都是不停地往上堆砌程式碼新增新功能，前人挖坑後人填。可見元件化對於不斷迭代的專案有著深遠的意義

1. 避免重複造輪子，提高開發效率
2. 減低耦合度，提高複用性
3. 保持團隊的技術方案統一性
4. 便於維護升級

基礎元件化

通常專案中常用的結構如下：

看似沒什麼問題，但通常我們的一些庫都是以程式碼的形式整合在程式碼中，隨著專案推進，慢慢發現一些比較嚴重的問題。

1. 業務程式碼侵入元件程式碼中 （例如一些全域性的網路返回響應，直接在庫中編碼等）
2. 團隊內部沒約束，各自整合不同的基礎庫（例如圖片載入有的用Glide，有的用ImageLoader）
3. 部分第三方元件停止更新，專案程式碼耦合高，替換新方案難

所以在實際設施元件化的過程中，建議參考：

1. 獨立library庫（Common基礎元件），避免在主工程中直接以程式碼整合，使用aar方式引用
2. 第三方的庫呼叫最好再裝一層介面，以便後續維護升級
3. 有成員專門負責維護，可以以SDK的方式提供業務層的呼叫

業務模組化

隨著專案邏輯不斷的增加，慢慢是不是發現程式碼編譯速度是不是越來越慢？（PS：我們目前專案編譯一次2分鐘，且已是經過一些優化處理）

另外當團隊內部有多個專案時，是不是經歷過產品經理讓你把專案A的某個功能移到專案B去，這個時候… …

業務模組化的作用性就很明顯了

1. 業務模組間避免耦合，提高複用性
2. 業務模組獨立編譯執行

推薦教程：

思考

• 專案架構都是不斷演進，不是一蹴而就
• 沒有最好的架構，只有在適當的時機，最合適的架構
• 專案重構過程是艱難的，但長痛不如短痛