Android開發之元件化架構

當APP規模達到一定時，利用元件化架構能夠有效的簡化APP的邏輯。按業務邏輯分組，各個團隊隻需關注于自己的子產品實作，編譯釋出APP時再把各個子產品集合在一起。元件化架構方式能讓這一切變得簡單而易于維護，特别适用于不同團隊之間的協作開發。本文主要介紹元件化架構的代碼組織方式。

元件化架構需要各個元件不僅能夠單獨運作而且也能無縫的內建到主程式中，在這個過程中會遇到以下問題：

TODO:

在項目的根目錄下的gradle.properties檔案中聲明一個變量isModule(該變量能對整個項目中所有的gradle檔案生效)代表是否是元件開發模式。

gradle.properties isModule=false

在每個元件build.gradle檔案中添加以下代碼，根據剛才定義的變量動态建構該子產品。

可以為元件模式和工程模式分别指定不同的AndroidManifest.xml檔案，并同時維護兩份檔案。這兩份xml檔案的差別就是，在元件模式下要去掉LAUNCHER Activity的聲明，其他均相同。

由于每個APP都有唯一個Application對象，在元件合并時沒法做到互相調用，這時候就需要有一個全局子產品來統一管理這個Application了。

在元件化工程模型圖中，功能元件集合中有一個 Common 元件， Common 有公共、公用、共同的意思，是以這個元件中主要封裝了項目中需要的基礎功能，并且每一個業務元件都要依賴Common元件，Common 元件就像是萬丈高樓的地基，而業務元件就是在 Common 元件這個地基上搭建起來我們的APP的，在Common元件中我們封裝了項目中用到的各種Base類，這些基類中就有BaseApplication 類。

BaseApplication 主要用于各個業務元件和app殼工程中聲明的 Application 類繼承用的，隻要各個業務元件和app殼工程中聲明的Application類繼承了 BaseApplication，當應用啟動時 BaseApplication 就會被動執行個體化，由于所有元件都依賴于Common元件，是以任何元件都可以操作BaseApplication類，這樣也就實作了Application的集中管理。

元件化不可避免的會出現資源名沖突的問題，如A和B元件裡面有相同名稱的圖檔等。解決這個問題最簡單的辦法就是在項目中約定資源檔案命名規約，比如強制使每個資源檔案的名稱以元件名開始，這個可以根據實際情況和開發人員制定規則。當然了萬能的Gradle建構工具也提供了解決方法，通過在在元件的build.gradle中添加如下的代碼：

利用第三方路由架構實作元件間的跳轉，如ARouter或ActivityRouter等。

在元件化工程模型中主要有common子產品，空殼子產品，普通業務子產品三種類型。common子產品管理了所有的依賴關系，所有子產品都依賴common子產品。空殼子產品是彙聚整合整個項目的子產品，它依賴了所有的業務子產品（moudleA,moudleB,moudleC）,app名稱，圖檔代碼混淆等都在這裡實作。普通業務子產品即根據業務細分的子產品，承擔各個業務獨立的功能。

common子產品始終為com.android.library類型。它的主要用作是統籌管理所有依賴關系，各種Android權限的聲明以及工具庫的實作。所有子產品都依賴common子產品。它的主要作用如下：

Common元件的AndroidManifest.xml中聲明Android應用的所有權限uses-permission和uses-feature。所有業務元件無需在自己的AndroidManifest.xml中再重複聲明權限了。

Common元件的build.gradle需要統一依賴業務元件中用到的各種第三方依賴庫和jar包，如ARouter、Okhttp等。

Common元件中封裝了項目中的公共元件，工具類，以及全局BaseApplication。

Common元件的資源檔案中需要放置項目公用的Drawable、layout、sting、dimen、color和style 等等，另外項目中的 Activity主題必須定義在Common中，友善和BaseActivity配合保持整個Android應用的界面風格統一。

空殼子產品就是一個空殼工程，沒有任何的業務代碼，也不能有Activity，但它又必須被單獨劃分成一個元件，而不能融合到其他元件中，是因為它有如下幾點重要功能：

空殼子產品中聲明了我們Android應用的Application，這個 Application必須繼承自Common元件中的 BaseApplication（如果你無需實作自己的Application可以直接在表單聲明BaseApplication），因為隻有這樣，在打包應用後才能讓BaseApplication中的Context生效，當然你還可以在這個 Application中初始化我們工程中使用到的庫檔案，還可以在這裡解決Android引用方法數不能超過65535 的限制，對崩潰事件的捕獲和發送也可以在這裡聲明。

空殼子產品的 AndroidManifest.xml 是我Android應用的根表單，應用的名稱、圖示以及是否支援備份等等屬性都是在這份表單中配置的，其他元件中的表單最終在內建開發模式下都被合并到這份 AndroidManifest.xml 中。

空殼子產品的build.gradle 是比較特殊的，app殼不管是在內建開發模式還是元件開發模式，它的屬性始終都是：com.android.application，因為最終其他的元件都要被app殼工程所依賴，被打包進app殼工程中，這一點從元件化工程模型圖中就能展現出來，是以app殼工程是不需要單獨調試單獨開發的。另外Android應用的打包簽名代碼混淆，以及buildTypes和defaultConfig都需要在這裡配置。

這個就是和業務相關的子產品，無特殊的說明，如moudleA，moudleB，moudleC。

依賴關系：

殼子產品依賴moudleA moudleB moudleC

各個moudle均依賴common