Android應用架構前世今生（轉）
前言
Android的開發生態系統發展迅速，在開發Android的幾年的時間里，用來構建Android應用的架構與技術一直在不斷進化。隨著項目的不斷更新迭代，應用的架構也有不一樣的變化。由于開發人員的數量、項目的業務復雜度、需求的開發時間、應用的使用量級，使用的技術架構也不相同。沒有最好的架構，只有最合適的。通過設計使程序模塊化，做到模塊內部的高聚合和模塊之間的低耦合。這樣做的好處是使得程序在開發的過程中，開發人員只需要專注于一點，提高程序開發的效率，便于項目的后期維護。下面總結及匯總一下目前Android使用的主要應用架構及其優缺點和使用的學習心得，如有不對之處，歡迎交流糾正。
還記得以前學生時代學習.NET的時候，第一次接觸到項目架構叫三層架構。應用層、業務邏輯層及數據訪問層。mvc的思想其實也一樣，都是一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。Android的項目設計本身也是采用了mvc的設計思想。
視圖層(View)
一般采用XML文件進行界面的描述，使用的時候可以非常方便的引入。同時便于后期界面的修改。邏輯中與界面對應的id不變化則代碼不用修改，大大增強了代碼的可維護性。
控制層(Controller)
Android的控制層主要就是Activity層。相關View層交互觸發及數據展示邏輯都在Activity中進行編碼。
模型層(Model)
我們通常針對業務數據，都會定義好對應的Model層。數據庫的操作、對網絡等的操作都應該在Model里面處理，當然對業務計算等操作也是必須放在的該層的
所以一直以來我們使用Android默認的項目結構開發，主要都是在采用mvc的架構思想。
優點：?適用了簡單的頁面展示，業務邏輯不復雜。開發效果高，代碼層級也簡單易懂
缺點：?當業務復雜時，Activity非常臃腫，不便于維護及測試
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進行交互，降低耦合，方便進行單元測試
優點：
Model與View完全分離，修改互不影響
更高效地使用，因為所有的邏輯交互都發生在一個地方—Presenter內部
一個Preseter可用于多個View，而不需要改變Presenter的邏輯（因為View的變化總是比Model的變化頻繁）。
更便于測試。把邏輯放在Presenter中，就可以脫離用戶接口來測試邏輯（單元測試）
缺點：?需要拿捏好Presenter、View interface的顆粒度設計，容易出現Presenter過于簡單或則復雜化。
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 很難被調試
數據雙向綁定不利于代碼重用及擴展
代碼的閱讀性降低
google在官方示例中給出了一系列不同架構的app實現，項目目的是通過展示各種架構app的不同方式來幫助開發者解決架構問題。項目中通過不同的架構概念及方式實現了功能相同的app。
使用RXJAVA對數據流進行處理，并且通過Repository進行數據的集中管理，通過協議類XXXContract來對View和Presenter的接口進行內部繼承，在presenter的實現類中，可以對Model數據進行操作。實例中，數據的獲取、存儲、數據狀態變化都是model層的任務，presenter會根據需要調用該層的數據處理邏輯并在需要時將回調傳入。這樣model、presenter、view都只處理各自的任務，實現單一責任原則。
推薦教程：
隨著項目的推進，及企業業務的發展。有一天可以發現團隊內部需要開發多個APP，且多個APP中存在相同的業務模塊，一開始的做法為了趕項目進度可能就是黏貼復制，到后面就慢慢發現越來越吃力，重復勞動。
慢慢隨著時間的推移，惡性循環。慢慢發現項目代碼結構混亂、層次不清，各業務技術方案不統一；甚至連基本的包結構也是胡亂不堪，都是不停地往上堆砌代碼添加新功能，前人挖坑后人填。可見組件化對于不斷迭代的項目有著深遠的意義
避免重復造輪子，提高開發效率
減低耦合度，提高復用性
保持團隊的技術方案統一性
便于維護升級
通常項目中常用的結構如下：
看似沒什么問題，但通常我們的一些庫都是以代碼的形式集成在代碼中，隨著項目推進，慢慢發現一些比較嚴重的問題。
業務代碼侵入組件代碼中 （例如一些全局的網絡返回響應，直接在庫中編碼等）
團隊內部沒約束，各自集成不同的基礎庫（例如圖片加載有的用Glide，有的用ImageLoader）
部分第三方組件停止更新，項目代碼耦合高，替換新方案難
所以在實際設施組件化的過程中，建議參考：
獨立library庫（Common基礎組件），避免在主工程中直接以代碼集成，使用aar方式引用
第三方的庫調用最好再裝一層接口，以便后續維護升級
有成員專門負責維護，可以以SDK的方式提供業務層的調用
隨著項目邏輯不斷的增加，慢慢是不是發現代碼編譯速度是不是越來越慢？（PS：我們目前項目編譯一次2分鐘，且已是經過一些優化處理）
另外當團隊內部有多個項目時，是不是經歷過產品經理讓你把項目A的某個功能移到項目B去，這個時候… …
業務模塊化的作用性就很明顯了
業務模塊間避免耦合，提高復用性
業務模塊獨立編譯運行
推薦教程：
項目架構都是不斷演進，不是一蹴而就
沒有最好的架構，只有在適當的時機，最合適的架構
項目重構過程是艱難的，但長痛不如短痛
