Android組件化架構

Android組件化架構

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

組件化架構需要各個組件不僅能夠單獨運行而且也能無縫的集成到主程序中，在這個過程中會遇到以下問題：

1. 組件可在Application和Library之間自由切換

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

gradle.properties
isModule=false

在每個組件build.gradle文件中添加以下代碼，根據剛纔定義的變量動態構建該模塊。

if (isModule.toBoolean()) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

2.組件AndroidManifest.xml與工程AndroidManifest.xml衝突的問題

TODO:
可以爲組件模式和工程模式分別指定不同的AndroidManifest.xml文件，並同時維護兩份文件。這兩份xml文件的區別就是，在組件模式下要去掉LAUNCHER Activity的聲明，其他均相同。

//每個模塊下的build.gradle文件
sourceSets {
        main {
            if (isModule.toBoolean()) {
                manifest.srcFile 'src/main/module/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/AndroidManifest.xml'
            }
        }
    }

3.組件Application與主工程Application衝突的處理

TODO:
由於每個APP都有唯一個Application對象，在組件合併時沒法做到相互調用，這時候就需要有一個全局模塊來統一管理這個Application了。
在組件化工程模型圖中，功能組件集合中有一個 Common 組件， Common 有公共、公用、共同的意思，所以這個組件中主要封裝了項目中需要的基礎功能，並且每一個業務組件都要依賴Common組件，Common 組件就像是萬丈高樓的地基，而業務組件就是在 Common 組件這個地基上搭建起來我們的APP的，在Common組件中我們封裝了項目中用到的各種Base類，這些基類中就有BaseApplication 類。

BaseApplication 主要用於各個業務組件和app殼工程中聲明的 Application 類繼承用的，只要各個業務組件和app殼工程中聲明的Application類繼承了 BaseApplication，當應用啓動時 BaseApplication 就會被動實例化，由於所有組件都依賴於Common組件，所以任何組件都可以操作BaseApplication類，這樣也就實現了Application的集中管理。

4.組件資源名重複的問題

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

//設置了resourcePrefix值後，所有的資源名必須以指定的字符串做前綴，否則會報錯。
//但是resourcePrefix這個值只能限定xml裏面的資源，並不能限定圖片資源，所有圖片資源仍然需要手動去修改資源名。
resourcePrefix "modulea_"

5.跨跳轉問題，路由選擇

TODO:
利用第三方路由框架實現組件間的跳轉，如ARouter或ActivityRouter等。

代碼方案

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

common模塊

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

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

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

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

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

空殼模塊

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

1. 空殼模塊中聲明瞭我們Android應用的Application，這個 Application必須繼承自Common組件中的 BaseApplication（如果你無需實現自己的Application可以直接在表單聲明BaseApplication），因爲只有這樣，在打包應用後才能讓BaseApplication中的Context生效，當然你還可以在這個 Application中初始化我們工程中使用到的庫文件，還可以在這裏解決Android引用方法數不能超過65535 的限制，對崩潰事件的捕獲和發送也可以在這裏聲明。

2. 空殼模塊的 AndroidManifest.xml 是我Android應用的根表單，應用的名稱、圖標以及是否支持備份等等屬性都是在這份表單中配置的，其他組件中的表單最終在集成開發模式下都被合併到這份 AndroidManifest.xml 中。

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

普通業務模塊

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

依賴關係：
殼模塊依賴moudleA moudleB moudleC
各個moudle均依賴common