前言
為什么要組件化？app 業(yè)務迭代，模塊越來越多，代碼量超10萬是很正常的，代碼混雜在一起，對工程所做的任何修改都必須要編譯整個工程，維護成本越來越高，因此就需要進行模塊化，組件化
Android工程的組件一般分為兩種，lib組件和application組件。lib組件是指該組件屬于app的一部分，可以供其它組件使用但是本身不能打包成apk；application組件是指該組件本身就可以運行并打包成app
定義
模塊化：將一個程序按照其功能做拆分，分成相互獨立的模塊，以便于每個模塊只包含與其功能相關的內(nèi)容
組件化：將一個app分成多個模塊，每個模塊都是一個組件（Module），開發(fā)的過程中我們可以讓這些組件相互依賴或者單獨調(diào)試部分組件等，但是最終發(fā)布的時候是將這些組件合并統(tǒng)一成一個apk
插件化：和組件化開發(fā)略有不用，插件化開發(fā)時將整個app拆分成很多模塊，這些模塊包括一個宿主和多個插件，每個模塊都是一個apk（組件化的每個模塊是個lib），最終打包的時候?qū)⑺拗鱝pk和插件apk分開或者聯(lián)合打包
區(qū)別
模塊化 VS 組件化：模塊化和組件化本質(zhì)思想是一樣的，都是"大化小"，兩者的目的都是為了重用和解耦，只是叫法不一樣。如果非要說區(qū)別，那么可以認為模塊化粒度更小，更側(cè)重于重用，而組件化粒度稍大于模塊，更側(cè)重于業(yè)務解耦
組件化 VS 插件化：組件化可以說和插件化有異曲同工之妙，只不過插件化是在［運行時］，而組件化是在［編譯時］。換句話說，插件化是基于多APK的，而組件化本質(zhì)上還是只有一個APK
優(yōu)點
業(yè)務橫向隔離、縱向解耦
系統(tǒng)級的控制力度細化到組件級的控制力度
沉淀出底層Library層，新建項目直接復用，節(jié)省人力
各組件可以采用靈活的架構(gòu)形式：MVC、MVP、MVVP等
每個組件都有自己獨立的版本，可以獨立的編譯、測試、打包和部署
為插件化做準備
組件化演變
簡單開發(fā)模型：最基礎的開發(fā)方式，工程中沒有所謂的模塊概念，項目組成的基本單位是方法。頁面中夾雜著業(yè)務邏輯、數(shù)據(jù)操作、網(wǎng)絡請求等
單工程開發(fā)模型：明確的模塊劃分，并且通過邏輯上的分層呈現(xiàn)出較好結(jié)構(gòu)，該模型最為我們所熟悉，通常用于早期產(chǎn)品的快速開發(fā)，團隊規(guī)模較小的情況下
主工程多子工程開發(fā)模型：借助組件化這一思想，我們在”單工程”模型的基礎上，將業(yè)務層中的各業(yè)務抽取出來，封裝成相應的業(yè)務組件，將基礎庫中各部分抽取出來，封裝成基礎組件，而主工程是一個可運行的app，作為各組件的入口(主工程也被稱之為殼程序)。這些組件或以jar的形式呈現(xiàn)，或以aar的形式呈現(xiàn)。主工程通過依賴的方式使用組件所提供的功能
不論是jar還是aar，本質(zhì)上都是Library，他們不能脫離主工程而單獨的運行。當團隊中成員共同參與項目的開發(fā)時，每個成員的開發(fā)設備中必須至少同時具備主工程和各自負責組件，不難看出通過對項目實行組件化，每個成員可以專注自己所負責的業(yè)務，并不影響其他業(yè)務，同時借助穩(wěn)定的基礎組件，可以極大減少代碼缺陷，因而整個團隊可以以并行開發(fā)的方式高效的推進開發(fā)進度
不但如此，組件化可以靈活的讓我們進行產(chǎn)品組裝，要做的無非就是根據(jù)需求配置相應的組件，最后生產(chǎn)出我們想要的產(chǎn)品。這有點像玩積木，通過不同擺放，我們就能得到自己想要的形狀
對測試同學而言，能有效的減少測試的時間：原有的業(yè)務不需要再次進行功能測試，可以專注于發(fā)生變化的業(yè)務的測試，以及最終的集成測試即可
所有業(yè)務組件不再是mouble而是作為一個子工程，基礎組件可以是moudle，也可以是子工程。業(yè)務組件和主工程不同：Debug模式下下作為app，可以單獨的開發(fā)、運行、調(diào)試；Release模式下作為Library，被主工程所依賴，向主工程提供服務
Android項目如何組件化？
組件間如何通信？可以采用開源的Router處理，核心是 Android 的 Scheme 機制。
UrlRouter?? ||?? ActivityRouter?? || ?? DeepLinkDispatch?
如何提升編譯速度？業(yè)務組件在Debug模式下做為單獨的Application，在Release模式下作為Library，如何去動態(tài)修改子工程的運行模式呢?
注意事項
單一開閉原則：每個模塊只代表一個功能模塊或一個公共業(yè)務，對于個性化或定制功能以接口形式對外開放
拆分粒度：項目的演進是不斷進行的，沒必要將每個細小組件都拆分出來，這樣不僅增加了項目的復雜度，同時也會影響編譯時間
依賴關系：通過依賴圖整理依賴關系，防止重復依賴，同時梳理出沉淀關系
組件間通信：放棄原來造成耦合嚴重的 EventBus，改用原生的隱式Intent通信方式，包括原生 (startActivityForResult) 、內(nèi)部廣播、回調(diào)等
資源沖突：為了解決不同Module間資源命名相同，資源調(diào)用時不知道調(diào)用哪個，建議每個Module的 *.gradle 添加? resourcePrefix "****_" ，****一般為模塊名稱，模塊內(nèi)每個資源文件命名以****為開頭。但是涉及declare-styleable的資源命名比較長
ActivityNotFoundException：如果某個 Activity 移到底層之后，主工程中AndroidManifest 中對應的注冊也應相應地遷移到對應 Module 的 AndroidManifest 中
