前言
為什么要組件化八孝？app 業(yè)務(wù)迭代董朝，模塊越來越多，代碼量超10萬是很正常的干跛，代碼混雜在一起子姜，對工程所做的任何修改都必須要編譯整個工程，維護(hù)成本越來越高驯鳖，因此就需要進(jìn)行模塊化闲询，組件化
Android工程的組件一般分為兩種，lib組件和application組件浅辙。lib組件是指該組件屬于app的一部分扭弧，可以供其它組件使用但是本身不能打包成apk；application組件是指該組件本身就可以運(yùn)行并打包成app
定義
模塊化：將一個程序按照其功能做拆分记舆，分成相互獨(dú)立的模塊鸽捻，以便于每個模塊只包含與其功能相關(guān)的內(nèi)容
組件化：將一個app分成多個模塊，每個模塊都是一個組件（Module）泽腮，開發(fā)的過程中我們可以讓這些組件相互依賴或者單獨(dú)調(diào)試部分組件等御蒲，但是最終發(fā)布的時(shí)候是將這些組件合并統(tǒng)一成一個apk
插件化：和組件化開發(fā)略有不用，插件化開發(fā)時(shí)將整個app拆分成很多模塊诊赊，這些模塊包括一個宿主和多個插件厚满，每個模塊都是一個apk（組件化的每個模塊是個lib），最終打包的時(shí)候?qū)⑺拗鱝pk和插件apk分開或者聯(lián)合打包
區(qū)別
模塊化 VS 組件化：模塊化和組件化本質(zhì)思想是一樣的碧磅，都是"大化小"碘箍，兩者的目的都是為了重用和解耦，只是叫法不一樣鲸郊。如果非要說區(qū)別丰榴，那么可以認(rèn)為模塊化粒度更小，更側(cè)重于重用秆撮，而組件化粒度稍大于模塊四濒，更側(cè)重于業(yè)務(wù)解耦
組件化 VS 插件化：組件化可以說和插件化有異曲同工之妙，只不過插件化是在［運(yùn)行時(shí)］职辨，而組件化是在［編譯時(shí)］盗蟆。換句話說，插件化是基于多APK的舒裤，而組件化本質(zhì)上還是只有一個APK
優(yōu)點(diǎn)
業(yè)務(wù)橫向隔離姆涩、縱向解耦
系統(tǒng)級的控制力度細(xì)化到組件級的控制力度
沉淀出底層Library層，新建項(xiàng)目直接復(fù)用惭每，節(jié)省人力
各組件可以采用靈活的架構(gòu)形式：MVC骨饿、MVP亏栈、MVVP等
每個組件都有自己獨(dú)立的版本，可以獨(dú)立的編譯宏赘、測試绒北、打包和部署
為插件化做準(zhǔn)備
組件化演變
簡單開發(fā)模型：最基礎(chǔ)的開發(fā)方式，工程中沒有所謂的模塊概念察署，項(xiàng)目組成的基本單位是方法闷游。頁面中夾雜著業(yè)務(wù)邏輯、數(shù)據(jù)操作贴汪、網(wǎng)絡(luò)請求等
單工程開發(fā)模型：明確的模塊劃分脐往，并且通過邏輯上的分層呈現(xiàn)出較好結(jié)構(gòu)，該模型最為我們所熟悉扳埂，通常用于早期產(chǎn)品的快速開發(fā)业簿，團(tuán)隊(duì)規(guī)模較小的情況下
主工程多子工程開發(fā)模型：借助組件化這一思想，我們在”單工程”模型的基礎(chǔ)上阳懂，將業(yè)務(wù)層中的各業(yè)務(wù)抽取出來梅尤，封裝成相應(yīng)的業(yè)務(wù)組件，將基礎(chǔ)庫中各部分抽取出來岩调，封裝成基礎(chǔ)組件巷燥，而主工程是一個可運(yùn)行的app，作為各組件的入口(主工程也被稱之為殼程序)号枕。這些組件或以jar的形式呈現(xiàn)缰揪，或以aar的形式呈現(xiàn)。主工程通過依賴的方式使用組件所提供的功能
不論是jar還是aar葱淳，本質(zhì)上都是Library邀跃，他們不能脫離主工程而單獨(dú)的運(yùn)行。當(dāng)團(tuán)隊(duì)中成員共同參與項(xiàng)目的開發(fā)時(shí)蛙紫，每個成員的開發(fā)設(shè)備中必須至少同時(shí)具備主工程和各自負(fù)責(zé)組件，不難看出通過對項(xiàng)目實(shí)行組件化途戒，每個成員可以專注自己所負(fù)責(zé)的業(yè)務(wù)坑傅，并不影響其他業(yè)務(wù)，同時(shí)借助穩(wěn)定的基礎(chǔ)組件喷斋，可以極大減少代碼缺陷唁毒，因而整個團(tuán)隊(duì)可以以并行開發(fā)的方式高效的推進(jìn)開發(fā)進(jìn)度
不但如此，組件化可以靈活的讓我們進(jìn)行產(chǎn)品組裝星爪，要做的無非就是根據(jù)需求配置相應(yīng)的組件浆西，最后生產(chǎn)出我們想要的產(chǎn)品。這有點(diǎn)像玩積木顽腾，通過不同擺放近零，我們就能得到自己想要的形狀
對測試同學(xué)而言诺核，能有效的減少測試的時(shí)間：原有的業(yè)務(wù)不需要再次進(jìn)行功能測試，可以專注于發(fā)生變化的業(yè)務(wù)的測試久信，以及最終的集成測試即可
所有業(yè)務(wù)組件不再是mouble而是作為一個子工程窖杀，基礎(chǔ)組件可以是moudle，也可以是子工程裙士。業(yè)務(wù)組件和主工程不同：Debug模式下下作為app入客，可以單獨(dú)的開發(fā)、運(yùn)行腿椎、調(diào)試桌硫；Release模式下作為Library，被主工程所依賴啃炸，向主工程提供服務(wù)
Android項(xiàng)目如何組件化铆隘？
組件間如何通信？可以采用開源的Router處理肮帐，核心是 Android 的 Scheme 機(jī)制咖驮。
UrlRouter?? ||?? ActivityRouter?? || ?? DeepLinkDispatch?
如何提升編譯速度？業(yè)務(wù)組件在Debug模式下做為單獨(dú)的Application训枢，在Release模式下作為Library托修，如何去動態(tài)修改子工程的運(yùn)行模式呢?
注意事項(xiàng)
單一開閉原則：每個模塊只代表一個功能模塊或一個公共業(yè)務(wù)，對于個性化或定制功能以接口形式對外開放
拆分粒度：項(xiàng)目的演進(jìn)是不斷進(jìn)行的恒界，沒必要將每個細(xì)小組件都拆分出來睦刃，這樣不僅增加了項(xiàng)目的復(fù)雜度，同時(shí)也會影響編譯時(shí)間
依賴關(guān)系：通過依賴圖整理依賴關(guān)系十酣，防止重復(fù)依賴涩拙，同時(shí)梳理出沉淀關(guān)系
組件間通信：放棄原來造成耦合嚴(yán)重的 EventBus，改用原生的隱式Intent通信方式耸采，包括原生 (startActivityForResult) 兴泥、內(nèi)部廣播、回調(diào)等
資源沖突：為了解決不同Module間資源命名相同虾宇，資源調(diào)用時(shí)不知道調(diào)用哪個搓彻，建議每個Module的 *.gradle 添加? resourcePrefix "****_" ，****一般為模塊名稱嘱朽，模塊內(nèi)每個資源文件命名以****為開頭旭贬。但是涉及declare-styleable的資源命名比較長
ActivityNotFoundException：如果某個 Activity 移到底層之后，主工程中AndroidManifest 中對應(yīng)的注冊也應(yīng)相應(yīng)地遷移到對應(yīng) Module 的 AndroidManifest 中
