前言
為什么要組件化八孝?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 中