不使用元件化哪裡不好？
在使用元件化之前，所有業務集中在一個Module中。隨著業務的增加，整個專案結構的複雜度也在不斷增加，最後的效果就會是這樣的：
所有的內容都放到app模組中，裡面包含了各種業務，各種第三方功能和框架。這樣的缺點有很多，比如：
1、業務之間直接相互呼叫，你中有我，我中有你，程式碼高度耦合，牽一髮而動全身
2、開發人員需要花費大量的時間與其他業務開發人員溝通與協調，無法專注於自己的功能點，影響開發效率
3、不能靈活的對工程進行配置和組裝
什麼是元件化技術？
元件化是指解耦複雜系統時將多個功能模組拆分、重組的過程。在Android工程表現上就是把 app 按照其業務的不同，劃分為不同的Module。
App殼工程：負責管理各個業務元件和打包APK，沒有具體的業務功能；
業務元件層：根據不同的業務構成獨立的業務元件；
功能元件層：對上層提供基礎功能服務，如登入、日誌服務等；
基礎庫 ：包含了各種開源庫以及和業務無關的各種自研工具庫使用了元件化有什麼好處？
1、各個元件專注自身功能的實現，模組中程式碼高度聚合，只負責一項任務，也就是常說的單一責任原則
2、各業務研發可以互不干擾、提升協作效率
3、業務可進行拔插，靈活多變
4、業務之間將不再直接引用和依賴，各個業務模組元件更加獨立，降低耦合
5、加快編譯速度，提高開發效率etc...
如何使用元件化？
以上說了這麼多，我們已經知道了元件化的重要性，那麼應該如何應用元件化技術到我們的實際專案中呢？其實很簡單，只需要做好元件模式和整合模式的轉換就好了。
1、gradle.properties中定義變數
2、在業務元件層中的build.gradle修改為動態匯入不同外掛
if (isModule.toBoolean())
{ //整合模式 整合進入app
apply
plugin:
‘com.android.library’
} else { //元件模式 單獨執行
apply
plugin:
'com.android.application'
}
3.業務元件中的AndroidManifest需要動態更改
sourceSets {
main {
if (isModule.toBoolean()) {
manifest.srcFile 'src/main/module/AndroidManifest.xml'
} else {
manifest.srcFile 'src/main/AndroidManifest.xml'
}
}
}
備註：這樣修改的目的是當業務元件作為整合模式整合進入app時不需要launcher，如果有launcher會導致app安裝後多個入口。
業務元件作為單獨module執行時manifest檔案如下：
業務元件整合入app時manifest檔案如下：
元件間activity應該如何跳轉？
元件間通訊最常用例子之一就是跳轉到不同元件下面的介面了，這樣是不能直接跳轉的，必須通過Router的方式，給每一個介面起一個key，然後通過key來獲取到需要跳轉的介面。具體儲存key-value的方式可以通過APT生成程式碼，然後執行時尋找所有APT生成的對應關係程式碼來新增到hashmap中，這樣就可以通過key來獲取到了。
步驟一 自定義註解類用來生成對應關係，這裡的value就是activity儲存的value
步驟二 給需要提供給其他元件進行跳轉的activity使用註解,相當於起了一個別名
步驟三 註解處理器生成對應關係的程式碼
這裡的generatedClass2方法就是生成路徑和Activity對應關係的。匯入相關的類包，然後做完以後編譯一下，就可以看到生成好了java檔案，這個檔案其實就是將註解上標註的字串和activity一一對應起來，這樣就可以找到activity進行跳轉了。
步驟三 給routes倉庫賦值
以上準備操作已經做好了，但是目前只是生成了相關需要執行的程式碼，實際並沒有執行，那麼應該怎麼執行剛剛生成的程式碼呢？這裡可以通過遍歷包中所有類的方式，找到其中由Route註解生成的類，然後呼叫其中的onLoad方法來實現。
步驟四 跳轉到其他元件下的介面
總結：以上已經完成了元件化的框架搭建，並且實現了一個簡單的跳轉router。但是有了這些還遠遠不夠，比如元件間怎麼進行資料的互動通訊？這裡內容比較多，下篇中將會詳細介紹這一塊實現的各種方式優劣性對比以及發展過程。