前言
鑑於個人文筆有限，上篇博文Android元件化文章寫的太爛 Android元件化、模組化開發圖文以及解釋做的太過粗糙。
本篇咱們根據圖表對比，優缺點，講述具體的實現步驟以及gradle自動化指令碼的書寫等。

為什麼元件化
隨著移動網際網路的發展，或許中小型專案還可以用單工程+MVC/MVP/MVVM的架構來完成，但當專案到了一定程度之後，編譯時間 原來越長，測試或者開發任何一個模組功能都需要整個專案重啟執行。

常規單工程+MVC/MVP/MVVM專案：

乍一看，這樣的結構只要咱們模組分層明確，是不存在大問題的，但是隨著業務的快速迭代，面臨以下問題：

1.需求瘋狂變化，上週剛討論出一套方案，你花了兩天搞定，這個時候PM告訴你，這個咱們修改或者不要了，是否想抓狂呢。

2.所有業務都在一個專案，不管基於什麼原因，有時候咱們為了快速完成一個功能，或多或少存在耦合，任何改動都可能顯的比較吃力，解決了一個BUG又出現另外一個BUG。

3.團隊人數達到一定程度後，並行開發過程中，如果某個成員不小心犯錯並且提交了程式碼，可能導致專案暫時無法執行，不得不停下來協同查詢問題，嚴重影響開發效率

4.業務越來越多，專案越來越大，編譯執行一次要10秒…20秒…1分鐘…5分鐘…累計幾個月下來的時間說不得抽出來都可以去找個女朋友了…

基於以上問題，咱們的元件化應運而生。

元件化結構圖

對比上張圖，這裡的APP主要由業務元件構成，嚴格來說這5個業務元件也可以是5個App,當實現以上架構圖，看看元件化的優缺點：

元件化優點

• 業務元件可以單獨分配並行開發

• 單個元件業務可以由開發者自行決定採取MVC/MVP/MVVM架構而不影響整體大局

• 新人接手專案分配任務可單獨分配某一個模組任務，不必關心整個專案

• 開發效率提升，開發過程僅僅需要維護開發自己的元件內容

• 若公司有多個團隊，優秀程式碼元件可快速移植複用

• 積累個人的元件倉庫，擺脫貼上複製的“搬磚工”身份

• 測試可單獨測試某個模組

元件化的坑

• 元件與元件之間的呼叫，資料等互動

• 多個元件，在使用application的時候怎辦

• 多個元件資源命名重複

• 多個元件引用不同版本的相同的庫

瞭解了優缺點，咱們進入正式的元件化開發整合，後續將會描述如何解決元件化的一些坑。

前文說過，咱們的5個元件可以理解為5個app，下面開始整合。

先看看咱們的元件化效果，手機展示效果，

1：首先統一元件之間的版本以及第三方庫版本
利用Gradle統一版本號，可參考 android使用Gradle統一配置依賴版本

2:咱們的元件又是Lib，又是application，如何控制除錯，如何在主APP選擇

在config.build處新增一個布林isBuildApp作為標誌判斷依賴，true表示作為application存在，false表示lib存在

ext {
    isBuildApp=false;//false:作為Lib元件存在， true:作為application存在
    ...
}

在每個元件的build根據isBuildApp來選擇依賴

if(rootProject.ext.isBuildApp){
    apply plugin: "com.android.application"
}else{
    apply plugin: 'com.android.library'

}
android{
...
 defaultConfig {
        if(rootProject.ext.isBuildApp){
            applicationId "com.allure.shop"
        }
        ...
    }
}

ibrary與application執行時需要manifest,依然根據isBuildApp判斷

   sourceSets {
        main {
            if (rootProject.ext.isBuildApp) {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/release/AndroidManifest.xml'
                java {
                    exclude 'debug/**'
                }
            }
        }
    }

資源的命名為了避免重複，建議按照元件名開頭，如Login元件，命名login_xxx，BaiDuMap元件命bd_map_xxx
可用gradle進行強制檢測

resourcePrefix "login_"

主專案的引用

 if (rootProject.ext.isBuildApp) {
        compile project(':modulebase')
    } else {
        compile project(':modulecore:moduleLogin')
        compile project(':modulecore:moduleShop')
    }

解決元件與元件的互動：
方案1：可採用建立中介軟體的方式來統一管理元件之間的互動,如電影元件與首頁元件需要跳轉傳值等可採用開源的ActivityRouter，EventBus來完成

方案2：在主專案APP建立統一的入口類，針對元件與元件的互動建立方法，實現介面等，但此方式有一定溝通成本，元件與元件之間的互動維護可能需要一份文件來約束。

application的使用：
方案1：統一使用基礎庫的單例BaseApplication
方案2：反射ActivityThread

Lib與Application的切換
修改config.build裡的isBuildApp屬性並且重新sync

專案結構圖：
作為元件Lib

作為單獨的application

總結

元件化技術難度不大，難點在於業務的解耦。具體是否選擇元件化方式還是要根據專案大小來確定。 當然採取了元件化是極好的。
本身元件化是應用於複雜業務的場景，DEMO也不大好做，簡單的從專案抽取做了一份案例，後續考慮在此基礎上更新