Android 架構系列：
Android 架構一：Android 架構淺析
Android 架構二：縱向橫向結合構建項目
Android 架構三：組件化思想
Android 架構四：組件化架構實戰
Android 架構五：MVVM+Data Binding構建項目
……
一、前言
過去的開發思想，一般都是采取縱向結構的方式去架構項目，自從推出組件化的橫向架構后，我們一般都會縱橫結合地去構建我們的項目。
前面已經介紹了最近出的幾種架構思想，無論是最初的MVC, 還是近幾年風頭極盛的MVP, Google推出的MVVM,還是系統層面的組件化，他們都具有自己適用的場景，我們因地制宜，選擇自己合適的架構，才能將設計效益最大化。
二、如何架構項目
無論是最初的MVC, 還是近幾年風頭極盛的MVP, Google推出的MVVM,還是系統層面的組件化，最終遵循的架構原則無非就是三點：
1、橫向劃分模塊
2、縱向劃分層次
3、解耦通信
1、橫向分塊
一個大的項目，代碼量是極大的，甚至達到1G以上；這時必須先以大的層級進行劃分，才能有效達到分離的目的。
現在流行的組件化思想便有了用武之地；組件化是指解耦復雜系統時將多個功能模塊拆分、重組的過程，它是一種高效的處理復雜應用系統，更好的明確功能模塊作用的方式，分離組件邊界和責任，便于獨立升級和維護。
組件化思想主張將一個系統橫向切分為不同的子系統或者可以稱之為組件，根據業務與開發需要將工程劃分為：基礎庫組件，工具庫組件，業務組件1， 業務組件2... ，同時不同的模塊之間從大的層級實現職責單一原則。
2、組件之間解耦
一個系統劃分為若干組件后，那么問題就產生了，就是每個子模塊之間不能直接調用，那么我們怎么進行模塊之間的跳轉與數據交流呢。
首先想到的解決的辦法有兩個，隱式跳轉和反射，但是，這兩種方式一種實現維護麻煩，一種對性能會有影響，都不是理想的解決辦法。
那么，什么方式是實現組件之間交互的的理想方法，從而達到解耦的目的呢？
組件化的解耦思路是實現一套注冊路由機制，根據一套統一的注冊路由系統來統一實現跨組件通信，當前比較流行的框架有ActivityRouter, ARouter等
另外，插件化的解耦則直接通過Android系統提供的Binder機制來進行
3、縱向分層
從橫向做了組件劃分后，每個組件必然也需要自己的架構，這時候就需要使用縱向分層的思想了，也就是要說的縱向分層策略。MVC, MVP, MVVM 這些設計則使用了縱向分層的思想；它們都執行了三層劃分的標準，雖然各有不同，但大致可以理解：
- Model層： 處理數據**
- View層： 處理UI顯示**
-
MVC 的 Controller、
MVP 的 Presenter、
MVVM 的 ViewModel 則處理主要邏輯**
經以上劃分后，數據處理， Ui顯示， 邏輯處理都放到了各自的層進行處理，每個層僅執行本層應該做的操作。分層后，代碼已經做到了結構清晰，盡可能的解耦， 易于理解維護。
4、層次間解耦
根據CleanArchitecture原則，采用圓蔥形式的分層與解耦策略，因此在設計時注意：
- 1） 明確的層次限定
- 2） 禁止跨層次調用
- 3） 從內到外單向調用
拿MVP為例，根據洋蔥結構，由內到外我們可以得到Model-> Presenter -> UI;
在調用時，某層只能調用向內的鄰接層，如Presenter只能調用Model層，而不能出現Model層調用Presenter層的現象；相同的，UI層只能調用Presenter層，而不能跨層調用Model層；
層與層之間的通信，必然不能通過直接調用的方式（特別是View層與Presenter層），我們可以參考MVP模式中的接口通信方式來實現。
三、結語
我們這里只是從理輪上分析，如何搭建我們的項目架構
- 組件化 + MVC
- 組件化 + MVP
- 組件化 + MVVM
橫向只有組件化，而縱向選擇多樣化，并不是越新推出就越好，要根據自己的情況選擇。
如果你的項目非常短小，就幾個禮拜的功夫就可以搞完，就沒必要考慮什么縱橫分塊分層架構了，掄起鍵盤一頓敲就是了。
當然還有插件化，理論上插件化不能說是項目上的設計，而是產品上的設計。
理論講完，接下來，我們就開始實戰吧。
