在Android SDK一文中彪薛，我們談到模塊化和組件化，現(xiàn)在我們來聊聊組件化開發(fā)坯汤。
以下高能,請(qǐng)做好心理準(zhǔn)備,看不懂請(qǐng)發(fā)私信來交流.接下來還是先喊口號(hào):
每天點(diǎn)我,點(diǎn)我,不要倒數(shù)第一
每天點(diǎn)我,點(diǎn)我,不要倒數(shù)第二
每天點(diǎn)我,點(diǎn)我,不要倒數(shù)第三
模塊化和組件化
模塊化
組件化不是個(gè)新概念,其在各行各業(yè)都一直備受重視.至于組件化什么時(shí)候在軟件工程領(lǐng)域提出已經(jīng)無從考究了,不過呢可以確認(rèn)的是組件化最早應(yīng)用于服務(wù)端開發(fā),后來在該思想的指導(dǎo)下,前端開發(fā)和移動(dòng)端開發(fā)也產(chǎn)生各自的開發(fā)方式.
在了解組件化之前,先來回顧下模塊化的定義
Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.
簡單來說,模塊化就是將一個(gè)程序按照其功能做拆分虐唠，分成相互獨(dú)立的模塊，以便于每個(gè)模塊只包含與其功能相關(guān)的內(nèi)容惰聂。模塊我們相對(duì)熟悉,比如登錄功能可以是一個(gè)模塊,搜索功能可以是一個(gè)模塊,汽車的發(fā)送機(jī)也可是一個(gè)模塊.
組件化
現(xiàn)在來看看"組件化開發(fā)",這里我們看一下其定義:
Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.
通俗點(diǎn)就是:組件化就是基于可重用的目的疆偿，將一個(gè)大的軟件系統(tǒng)按照分離關(guān)注點(diǎn)的形式，拆分成多個(gè)獨(dú)立的組件搓幌，已較少耦合杆故。
咋樣一看還是非常抽象,說了這么多好像還是不明白.什么是組件呢?組件可以是模塊、web資源,軟件包,比如汽車的發(fā)動(dòng)機(jī)是一個(gè)模塊,也是一個(gè)組件,再或者前端中的一個(gè)日歷控件是一個(gè)模塊,也一個(gè)組件.
模塊化 vs 組件化
當(dāng)你看到這的時(shí)候,想必心理一陣惡寒:模塊化?組件化?到底是什么鬼?有啥區(qū)別.
有這種感覺才是對(duì)的,模塊化和組件化本質(zhì)思想是一樣的,都是"大化小",兩者的目的都是為了重用和解耦,只是叫法不一樣.如果非要說區(qū)別,那么可以認(rèn)為模塊化粒度更小,更側(cè)重于重用,而組件化粒度稍大于模塊,更側(cè)重于業(yè)務(wù)解耦.
組件化優(yōu)缺點(diǎn)
組件化開發(fā)的好處是顯而易見:系統(tǒng)級(jí)的控制力度細(xì)化到組件級(jí)的控制力度,一個(gè)復(fù)雜系統(tǒng)的構(gòu)建最后就是組件集成的結(jié)果.每個(gè)組件都有自己獨(dú)立的版本,可以獨(dú)立的編譯,測(cè)試,打包和部署
產(chǎn)品組件化后能夠?qū)崿F(xiàn)完整意義上的按需求進(jìn)行產(chǎn)品配置和銷售,用戶可以選擇使用那些組件,組件之間可以靈活的組建.
配置管理,開發(fā),測(cè)試,打包,發(fā)布完全控制到組建層面,并帶來很多好處.比如一個(gè)組件小版本進(jìn)行升級(jí),如果對(duì)外提供的接口沒有發(fā)生任何變化,其他組件完全不需要再進(jìn)行測(cè)試.
但是組件化的實(shí)施對(duì)開發(fā)人員和團(tuán)隊(duì)管理者提出了更高水平的要求.相對(duì)傳統(tǒng)方式,在項(xiàng)目的管理和組織上難度加大,要求開發(fā)人員對(duì)業(yè)務(wù)有更深層次上的理解.
進(jìn)軍Android 項(xiàng)目
為什么要在Android中實(shí)行組件化開發(fā)
為什么要在Android中實(shí)行組件化開發(fā)呢,其根本原因在于業(yè)務(wù)的增長提高了項(xiàng)目的復(fù)雜性,為了更好的適應(yīng)團(tuán)隊(duì)開發(fā),提高開發(fā)效率,實(shí)行組件化乃大勢(shì)所趨.
為了更好的幫助大家理解上面這句話,我將從最早的Android 項(xiàng)目開發(fā)方式說起.
簡單開發(fā)模型
所謂的簡單開發(fā)模型是最基礎(chǔ)的開發(fā)方式,工程中沒有所謂的模塊,沒有所謂的規(guī)劃,常見于初學(xué)者學(xué)習(xí)階段或者是個(gè)人學(xué)習(xí)過程所寫的demo,其結(jié)構(gòu)大概如下:
不難發(fā)現(xiàn),往往是在一個(gè)界面中存在著大量的業(yè)務(wù)邏輯,而業(yè)務(wù)邏輯中充斥著各種各種網(wǎng)絡(luò)請(qǐng)求,數(shù)據(jù)操作等行為,整個(gè)項(xiàng)目中沒有所謂的模塊的概念,項(xiàng)目組成的基本單位不是模塊,而是方法級(jí)的.
關(guān)于這種開發(fā)模型沒什么需要介紹的,我們?cè)缙诙冀?jīng)歷過,現(xiàn)在除了很少非常古老的項(xiàng)目以及初學(xué)者練手之作,已經(jīng)很少見到.
單工程開發(fā)模型
該種開發(fā)模型已經(jīng)有了明確的模塊劃分,并且通過邏輯上的分層呈現(xiàn)出較好結(jié)構(gòu),該模型最為我們所熟悉,通常用于早期產(chǎn)品的快速開發(fā),團(tuán)隊(duì)規(guī)模較小的情況下.該種開發(fā)模型結(jié)構(gòu)如下:
隨著產(chǎn)品的迭代,業(yè)務(wù)越來越復(fù)雜,隨之帶來的是項(xiàng)目結(jié)構(gòu)復(fù)雜度的極度增加,此時(shí)我們面臨著幾個(gè)問題:
- 實(shí)際業(yè)務(wù)變化非掣瘸睿快,但是工程之前的業(yè)務(wù)模塊耦合度太高,牽一發(fā)而動(dòng)全身.
- 對(duì)工程所做的任何修改都必須要編譯整個(gè)工程
- 功能測(cè)試和系統(tǒng)測(cè)試每次都要進(jìn)行.
- 團(tuán)隊(duì)協(xié)同開發(fā)存在較多的沖突.不得不花費(fèi)更多的時(shí)間去溝通和協(xié)調(diào),并且在開發(fā)過程中,任何一位成員沒辦法專注于自己的功能點(diǎn),影響開發(fā)效率.
- 不能靈活的對(duì)工程進(jìn)行配置和組裝.比如今天產(chǎn)品經(jīng)理說加上這個(gè)功能,明天又說去掉,后天在加上.
在面臨這些問題的前提下,我們重新來思考組件化,看看它是否能解決我們?cè)贏ndroid 項(xiàng)目開發(fā)中所遇到的難題.
主工程多組件開發(fā)模型
借助組件化這一思想,我們?cè)?單工程"模型的基礎(chǔ)上,將業(yè)務(wù)層中的各業(yè)務(wù)抽取出來,封裝成相應(yīng)的業(yè)務(wù)組件,將基礎(chǔ)庫中各部分抽取出來,封裝成基礎(chǔ)組件,而主工程是一個(gè)可運(yùn)行的app,作為各組件的入口(主工程也被稱之為殼程序).這些組件或以jar的形式呈現(xiàn),或以aar的形式呈現(xiàn).主工程通過依賴的方式使用組件所提供的功能.
(需要注意這是理想狀態(tài)下的結(jié)構(gòu)圖,實(shí)際項(xiàng)目中,業(yè)務(wù)組件之間會(huì)產(chǎn)生通信,也會(huì)產(chǎn)生依賴,關(guān)于這一點(diǎn),我們?cè)谙挛臅?huì)談)
不論是jar還是aar,本質(zhì)上都是Library,他們不能脫離主工程而單獨(dú)的運(yùn)行.當(dāng)團(tuán)隊(duì)中成員共同參與項(xiàng)目的開發(fā)時(shí),每個(gè)成員的開發(fā)設(shè)備中必須至少同時(shí)具備主工程和各自負(fù)責(zé)組件,不難看出通過對(duì)項(xiàng)目實(shí)行組件化,每個(gè)成員可以專注自己所負(fù)責(zé)的業(yè)務(wù),并不影響其他業(yè)務(wù),同時(shí)借助穩(wěn)定的基礎(chǔ)組件,可以極大減少代碼缺陷,因而整個(gè)團(tuán)隊(duì)可以以并行開發(fā)的方式高效的推進(jìn)開發(fā)進(jìn)度.
不但如此,組件化可以靈活的讓我們進(jìn)行產(chǎn)品組裝,要做的無非就是根據(jù)需求配置相應(yīng)的組件,最后生產(chǎn)出我們想要的產(chǎn)品.這有點(diǎn)像玩積木,通過不同擺放,我們就能得到自己想要的形狀.
對(duì)測(cè)試同學(xué)而言,能有效的減少測(cè)試的時(shí)間:原有的業(yè)務(wù)不需要再次進(jìn)行功能測(cè)試,可以專注于發(fā)生變化的業(yè)務(wù)的測(cè)試,以及最終的集成測(cè)試即可.
到現(xiàn)在為止,我們已經(jīng)有效解決了"單工程開發(fā)模型"中一些問題,對(duì)于大部分團(tuán)隊(duì)來說這種已經(jīng)可以了,但是該模型仍然存在一些可以改進(jìn)的點(diǎn):每次修改依賴包,就需要重新編譯生成lib或者aar.比如說小顏同學(xué)接手了一個(gè)項(xiàng)目有40多個(gè)組件,在最后集成所有組件的時(shí)候,小顏同學(xué)發(fā)現(xiàn)其中某組件存在問題,為了定位和修改該組件中的問題,小顏同學(xué)不斷這調(diào)試該組件.由于在該模型下,組件不能脫離主工程,那么意味著,每次修改后,小顏同學(xué)都要在漫長的編譯過程中等待.更糟糕的是,現(xiàn)在離上線只有5小時(shí)了,每次編譯10分鐘,為改這個(gè)bug,編譯了20次,恩....什么也不用干了,可以提交離職報(bào)告了
如何解決這種每次修改組件都要連同主工程一起編譯的問題?下面我們來看主工程多子工程開發(fā)模型是如何解決該問題的.
主工程多子工程開發(fā)模型
該種開發(fā)模型在"主工程多組件"開發(fā)模型的基礎(chǔ)上做了改進(jìn),其結(jié)構(gòu)圖如下:
不難發(fā)現(xiàn),該種開發(fā)模型在結(jié)構(gòu)上和"主工程多組件"并無不同,唯一的區(qū)別在于:所有業(yè)務(wù)組件不再是mouble而是作為一個(gè)子工程,基礎(chǔ)組件可以使moudle,也可以是子工程,該子工程和主工程不同:Debug模式下下作為app,可以單獨(dú)的開發(fā),運(yùn)行,調(diào)試;Release模式下作為Library,被主工程所依賴,向主工程提供服務(wù).
在該種模型下,當(dāng)小顏同學(xué)發(fā)現(xiàn)某個(gè)業(yè)務(wù)組件存在缺陷,會(huì)如何做呢?比如是基礎(chǔ)組件2出現(xiàn)問題,由于在Debug模式下,基礎(chǔ)組件2作為app可以獨(dú)立運(yùn)行的,因此可以很容易地對(duì)該模塊進(jìn)行單獨(dú)修改,調(diào)試.最后修改完后只需要重新編譯一次整個(gè)項(xiàng)目即可.
不難發(fā)現(xiàn)該種開發(fā)模型有效的減少了全編譯的次數(shù),減少編譯耗時(shí)的同時(shí),方便開發(fā)者進(jìn)行開發(fā)調(diào)試.
對(duì)測(cè)試同學(xué)來說,功能測(cè)試可以提前,并且能夠及時(shí)的參與到開發(fā)環(huán)節(jié)中,將風(fēng)險(xiǎn)降到最低.
到現(xiàn)在,我們?cè)诶碚搶哟紊现v明了采用組件化開發(fā)給我們帶來的便利,空口無憑是沒有說服力的,在下面的一小節(jié)中,我們來談?wù)勅绾谓M件化在Android中的實(shí)施過程.
組件化過程中遇到的問題
組件劃分
組件化首要做的事情就是劃分組件.如何劃分并沒有一個(gè)確切的標(biāo)準(zhǔn),我建議早期實(shí)施組件化的時(shí)候,可以以一種"較粗"的粒度來進(jìn)行,這樣左右的好處在于后期隨著對(duì)業(yè)務(wù)的理解進(jìn)行再次細(xì)分,而不會(huì)有太大的成本.當(dāng)然,我建議劃分組件這一工作有團(tuán)隊(duì)架構(gòu)人員和業(yè)務(wù)人員協(xié)商定制.
子工程工作方式切換
在"主工程多子工程模型"中,我們提到子工程在Debug模式下做為單獨(dú)的Application運(yùn)行,在Release模式下作為Library運(yùn)行,如何去動(dòng)態(tài)修改子工程的運(yùn)行模式呢?我們都知道采用Gradle構(gòu)建的工程中,用apply plugin: 'com.android.application'來標(biāo)識(shí)該為Application,而apply plugin: 'com.android.library'標(biāo)志位Library.因此,我們可以在編譯的是同通過判斷構(gòu)建環(huán)境中的參數(shù)來修改子工程的工作方式,在子工程的gradle腳本頭部加入以下腳本片段:
if (isDebug.toBoolean()) {
apply plugin: 'com.android.application'
} else {
apply plugin: 'com.android.library'
}
除此之外,子工程中在不同的運(yùn)行方式下,其AndroidMainifest.xml也是不相同的,需要為其分別提供自己AndroidManifest.xml文件:在子工程src目錄下(其他位置創(chuàng)建)創(chuàng)建兩個(gè)目錄,用來存放不同的AndroidManifest.xml,比如這里我創(chuàng)建了debug和release目錄
接下來同樣需要在該子工程的gradle構(gòu)建腳本中根據(jù)構(gòu)建方式制定:
android {
sourceSets {
main {
if(isDebug.toBoolean()) {
manifest.srcFile 'src/debug/AndroidManifest.xml'
} else {
manifest.srcFile 'src/release/AndroidManifest.xml'
}
}
}
}
組件通信與組件依賴
在"主工程多組件"這種理想模型下業(yè)務(wù)組件是不存在相互通信和依賴的,但現(xiàn)實(shí)卻是相反的,如下圖:
這里,業(yè)務(wù)組件1和業(yè)務(wù)組件3同時(shí)向業(yè)務(wù)組件2提供服務(wù),即業(yè)務(wù)組件2需要同時(shí)依賴業(yè)務(wù)組件3和業(yè)務(wù)組件1.
現(xiàn)在我們?cè)賮砜匆环N更糟糕的情況:
由此看來,在業(yè)務(wù)復(fù)雜的情況下,組件與組件之間的相互依賴會(huì)帶來兩個(gè)問題:
- 重復(fù)依賴:比如可能存在業(yè)務(wù)組件3依賴業(yè)務(wù)組件1,而業(yè)務(wù)組件2又依賴業(yè)務(wù)組件3和業(yè)務(wù)組件1,此時(shí)就導(dǎo)致了業(yè)務(wù)組件1被重復(fù)依賴.
- 子系統(tǒng)通信方式不能依靠傳統(tǒng)的顯示意圖.在該種模型下,使用顯示意圖將導(dǎo)致組件高度耦合.比如業(yè)務(wù)組件2依賴業(yè)務(wù)組件1,并通過顯示意圖的方式進(jìn)行通信,一旦業(yè)務(wù)組件1不再使用,那么業(yè)務(wù)組件2中使用現(xiàn)實(shí)意圖的地方會(huì)出現(xiàn)錯(cuò)誤,這顯然與我們組件化的目的背道而馳.
解決組件通信
先來解決業(yè)務(wù)組件通信問題.當(dāng)年看到上面那張復(fù)雜的組件通信圖時(shí),我們不難想到操作系統(tǒng)引入總線機(jī)制來解決設(shè)備掛載問題,同樣,借用總線的概念我們?cè)诠こ烫砑?組件總線",用于不同組件間的通信,此時(shí)結(jié)構(gòu)如下:
所有掛載到組件總線上的業(yè)務(wù)組件,都可以實(shí)現(xiàn)雙向通信.而通信協(xié)議和HTTP通信協(xié)議類似,即基于URL的方式進(jìn)行.至于實(shí)現(xiàn)的方式一種可以基于系統(tǒng)提供的隱式意圖的方式,另一種則是完全自行實(shí)現(xiàn)組件總線.這篇文章不打算在此不做詳細(xì)說明了.
解決重復(fù)依賴
對(duì)于采用aar方式輸出的Library而言,在構(gòu)建項(xiàng)目時(shí),gradle會(huì)為我們保留最新版本的aar,換言之,如果以aar的方式向主工程提供提供依賴不會(huì)存在重復(fù)依賴的問題.而如果是直接以project形式提供依賴,則在打包過程中會(huì)出現(xiàn)重復(fù)的代碼.解決project重復(fù)依賴問題目前有兩種做法:1.對(duì)于純代碼工程的庫或jar包而言,只在最終項(xiàng)目中執(zhí)行compile,其他情況采用provider方式;2.在編譯時(shí)檢測(cè)依賴的包,已經(jīng)依賴的不再依賴
資源id沖突
在合并多個(gè)組件到主工程中時(shí),可能會(huì)出現(xiàn)資源引用沖突,
最簡單的方式是通過實(shí)現(xiàn)約定資源前綴名(resourcePrefix)來避免,需要在組件的gradle腳本中配置:
andorid{
...
buildTypes{
...
}
resourcePrefix "moudle_prefix"
}
一旦配置resourcePrefix,所有的資源必須以該前綴名開頭.比如上面配置了前綴名為moudle_prefix,那么所有的資源名都要加上該前綴,如:mouble_prefix_btn_save.
組件上下文(Context)
最后需要注意在Debug模式下和Release模式下,所需要的Context是否是你所希望的,以避免產(chǎn)生強(qiáng)轉(zhuǎn)異常.
結(jié)束語
最早接觸組件化這個(gè)概念是在從事廣告SDK工作中,最近陸續(xù)續(xù)的做了一些總結(jié),因此有了這篇關(guān)于"組件化開發(fā)"的文章.另外,組件化開發(fā)不是銀彈,并不能完全解決當(dāng)前業(yè)務(wù)復(fù)雜的情況,在進(jìn)行項(xiàng)目實(shí)施和改進(jìn)之前,一定要多加考量.
關(guān)于Demo,后面我會(huì)再"師父說"中提交.有興趣的同學(xué)聯(lián)系我,相互交流.最后呢,還是要喊喊口號(hào):
每天點(diǎn)我,點(diǎn)我,一切為了妹紙
