在上一文中我們談到模塊化和組件化宛乃，現(xiàn)在我們來聊聊組件化開發(fā)售葡。
以下高能,請做好心理準備,看不懂請發(fā)私信來交流.
模塊化和組件化
模塊化
組件化不是個新概念,其在各行各業(yè)都一直備受重視.至于組件化什么時候在軟件工程領(lǐng)域提出已經(jīng)無從考究了,不過呢可以確認的是組件化最早應(yīng)用于服務(wù)端開發(fā),后來在該思想的指導下,前端開發(fā)和移動端開發(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.
簡單來說,模塊化就是將一個程序按照其功能做拆分，分成相互獨立的模塊猫态，以便于每個模塊只包含與其功能相關(guān)的內(nèi)容望薄。模塊我們相對熟悉,比如登錄功能可以是一個模塊,搜索功能可以是一個模塊,汽車的發(fā)送機也可是一個模塊.
組件化
現(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.
通俗點就是:組件化就是基于可重用的目的，將一個大的軟件系統(tǒng)按照分離關(guān)注點的形式握侧，拆分成多個獨立的組件，已較少耦合嘿期。
咋樣一看還是非常抽象,說了這么多好像還是不明白.什么是組件呢?組件可以是模塊品擎、web資源,軟件包,比如汽車的發(fā)動機是一個模塊,也是一個組件,再或者前端中的一個日歷控件是一個模塊,也一個組件.
模塊化 vs 組件化
當你看到這的時候,想必心理一陣惡寒:模塊化?組件化?到底是什么鬼?有啥區(qū)別.
有這種感覺才是對的,模塊化和組件化本質(zhì)思想是一樣的,都是"大化小",兩者的目的都是為了重用和解耦,只是叫法不一樣.如果非要說區(qū)別,那么可以認為模塊化粒度更小,更側(cè)重于重用,而組件化粒度稍大于模塊,更側(cè)重于業(yè)務(wù)解耦.
組件化優(yōu)缺點
組件化開發(fā)的好處是顯而易見:系統(tǒng)級的控制力度細化到組件級的控制力度,一個復雜系統(tǒng)的構(gòu)建最后就是組件集成的結(jié)果.每個組件都有自己獨立的版本,可以獨立的編譯,測試,打包和部署
產(chǎn)品組件化后能夠?qū)崿F(xiàn)完整意義上的按需求進行產(chǎn)品配置和銷售,用戶可以選擇使用那些組件,組件之間可以靈活的組建.
配置管理,開發(fā),測試,打包,發(fā)布完全控制到組建層面,并帶來很多好處.比如一個組件小版本進行升級,如果對外提供的接口沒有發(fā)生任何變化,其他組件完全不需要再進行測試.
但是組件化的實施對開發(fā)人員和團隊管理者提出了更高水平的要求.相對傳統(tǒng)方式,在項目的管理和組織上難度加大,要求開發(fā)人員對業(yè)務(wù)有更深層次上的理解.
進軍Android 項目
為什么要在Android中實行組件化開發(fā)
為什么要在Android中實行組件化開發(fā)呢,其根本原因在于業(yè)務(wù)的增長提高了項目的復雜性,為了更好的適應(yīng)團隊開發(fā),提高開發(fā)效率,實行組件化乃大勢所趨.
為了更好的幫助大家理解上面這句話,我將從最早的Android 項目開發(fā)方式說起.
簡單開發(fā)模型
所謂的簡單開發(fā)模型是最基礎(chǔ)的開發(fā)方式,工程中沒有所謂的模塊,沒有所謂的規(guī)劃,常見于初學者學習階段或者是個人學習過程所寫的demo,其結(jié)構(gòu)大概如下:
不難發(fā)現(xiàn),往往是在一個界面中存在著大量的業(yè)務(wù)邏輯,而業(yè)務(wù)邏輯中充斥著各種各種網(wǎng)絡(luò)請求,數(shù)據(jù)操作等行為,整個項目中沒有所謂的模塊的概念,項目組成的基本單位不是模塊,而是方法級的.
關(guān)于這種開發(fā)模型沒什么需要介紹的,我們早期都經(jīng)歷過,現(xiàn)在除了很少非常古老的項目以及初學者練手之作,已經(jīng)很少見到.
單工程開發(fā)模型
該種開發(fā)模型已經(jīng)有了明確的模塊劃分,并且通過邏輯上的分層呈現(xiàn)出較好結(jié)構(gòu),該模型最為我們所熟悉,通常用于早期產(chǎn)品的快速開發(fā),團隊規(guī)模較小的情況下.該種開發(fā)模型結(jié)構(gòu)如下:
隨著產(chǎn)品的迭代,業(yè)務(wù)越來越復雜,隨之帶來的是項目結(jié)構(gòu)復雜度的極度增加,此時我們面臨著幾個問題:
- 實際業(yè)務(wù)變化非常快,但是工程之前的業(yè)務(wù)模塊耦合度太高,牽一發(fā)而動全身.
- 對工程所做的任何修改都必須要編譯整個工程
- 功能測試和系統(tǒng)測試每次都要進行.
- 團隊協(xié)同開發(fā)存在較多的沖突.不得不花費更多的時間去溝通和協(xié)調(diào),并且在開發(fā)過程中,任何一位成員沒辦法專注于自己的功能點,影響開發(fā)效率.
- 不能靈活的對工程進行配置和組裝.比如今天產(chǎn)品經(jīng)理說加上這個功能,明天又說去掉,后天在加上.
在面臨這些問題的前提下,我們重新來思考組件化,看看它是否能解決我們在Android 項目開發(fā)中所遇到的難題.
主工程多組件開發(fā)模型
借助組件化這一思想,我們在"單工程"模型的基礎(chǔ)上,將業(yè)務(wù)層中的各業(yè)務(wù)抽取出來,封裝成相應(yīng)的業(yè)務(wù)組件,將基礎(chǔ)庫中各部分抽取出來,封裝成基礎(chǔ)組件,而主工程是一個可運行的app,作為各組件的入口(主工程也被稱之為殼程序).這些組件或以jar的形式呈現(xiàn),或以aar的形式呈現(xiàn).主工程通過依賴的方式使用組件所提供的功能.
(需要注意這是理想狀態(tài)下的結(jié)構(gòu)圖,實際項目中,業(yè)務(wù)組件之間會產(chǎn)生通信,也會產(chǎn)生依賴,關(guān)于這一點,我們在下文會談)
不論是jar還是aar,本質(zhì)上都是Library,他們不能脫離主工程而單獨的運行.當團隊中成員共同參與項目的開發(fā)時,每個成員的開發(fā)設(shè)備中必須至少同時具備主工程和各自負責組件,不難看出通過對項目實行組件化,每個成員可以專注自己所負責的業(yè)務(wù),并不影響其他業(yè)務(wù),同時借助穩(wěn)定的基礎(chǔ)組件,可以極大減少代碼缺陷,因而整個團隊可以以并行開發(fā)的方式高效的推進開發(fā)進度.
不但如此,組件化可以靈活的讓我們進行產(chǎn)品組裝,要做的無非就是根據(jù)需求配置相應(yīng)的組件,最后生產(chǎn)出我們想要的產(chǎn)品.這有點像玩積木,通過不同擺放,我們就能得到自己想要的形狀.
對測試同學而言,能有效的減少測試的時間:原有的業(yè)務(wù)不需要再次進行功能測試,可以專注于發(fā)生變化的業(yè)務(wù)的測試,以及最終的集成測試即可.
到現(xiàn)在為止,我們已經(jīng)有效解決了"單工程開發(fā)模型"中一些問題,對于大部分團隊來說這種已經(jīng)可以了,但是該模型仍然存在一些可以改進的點:每次修改依賴包,就需要重新編譯生成lib或者aar.比如說小顏同學接手了一個項目有40多個組件,在最后集成所有組件的時候,小顏同學發(fā)現(xiàn)其中某組件存在問題,為了定位和修改該組件中的問題,小顏同學不斷這調(diào)試該組件.由于在該模型下,組件不能脫離主工程,那么意味著,每次修改后,小顏同學都要在漫長的編譯過程中等待.更糟糕的是,現(xiàn)在離上線只有5小時了,每次編譯10分鐘,為改這個bug,編譯了20次,恩....什么也不用干了,可以提交離職報告了
如何解決這種每次修改組件都要連同主工程一起編譯的問題?下面我們來看主工程多子工程開發(fā)模型是如何解決該問題的.
主工程多子工程開發(fā)模型
該種開發(fā)模型在"主工程多組件"開發(fā)模型的基礎(chǔ)上做了改進,其結(jié)構(gòu)圖如下:
不難發(fā)現(xiàn),該種開發(fā)模型在結(jié)構(gòu)上和"主工程多組件"并無不同,唯一的區(qū)別在于:所有業(yè)務(wù)組件不再是mouble而是作為一個子工程,基礎(chǔ)組件可以使moudle,也可以是子工程,該子工程和主工程不同:Debug模式下下作為app,可以單獨的開發(fā),運行,調(diào)試;Release模式下作為Library,被主工程所依賴,向主工程提供服務(wù).
在該種模型下,當小顏同學發(fā)現(xiàn)某個業(yè)務(wù)組件存在缺陷,會如何做呢?比如是基礎(chǔ)組件2出現(xiàn)問題,由于在Debug模式下,基礎(chǔ)組件2作為app可以獨立運行的,因此可以很容易地對該模塊進行單獨修改,調(diào)試.最后修改完后只需要重新編譯一次整個項目即可.
不難發(fā)現(xiàn)該種開發(fā)模型有效的減少了全編譯的次數(shù),減少編譯耗時的同時,方便開發(fā)者進行開發(fā)調(diào)試.
對測試同學來說,功能測試可以提前,并且能夠及時的參與到開發(fā)環(huán)節(jié)中,將風險降到最低.
到現(xiàn)在,我們在理論層次上講明了采用組件化開發(fā)給我們帶來的便利,空口無憑是沒有說服力的,在下面的一小節(jié)中,我們來談?wù)勅绾谓M件化在Android中的實施過程.
組件化過程中遇到的問題
組件劃分
組件化首要做的事情就是劃分組件.如何劃分并沒有一個確切的標準,我建議早期實施組件化的時候,可以以一種"較粗"的粒度來進行,這樣左右的好處在于后期隨著對業(yè)務(wù)的理解進行再次細分,而不會有太大的成本.當然,我建議劃分組件這一工作有團隊架構(gòu)人員和業(yè)務(wù)人員協(xié)商定制.
子工程工作方式切換
在"主工程多子工程模型"中,我們提到子工程在Debug模式下做為單獨的Application運行,在Release模式下作為Library運行,如何去動態(tài)修改子工程的運行模式呢?我們都知道采用Gradle構(gòu)建的工程中,用apply plugin: 'com.android.application'來標識該為Application,而apply plugin: 'com.android.library'標志位Library.因此,我們可以在編譯的是同通過判斷構(gòu)建環(huán)境中的參數(shù)來修改子工程的工作方式,在子工程的gradle腳本頭部加入以下腳本片段:
if (isDebug.toBoolean()) {
apply plugin: 'com.android.application'
} else {
apply plugin: 'com.android.library'
}
除此之外,子工程中在不同的運行方式下,其AndroidMainifest.xml也是不相同的,需要為其分別提供自己AndroidManifest.xml文件:在子工程src目錄下(其他位置創(chuàng)建)創(chuàng)建兩個目錄,用來存放不同的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)實卻是相反的,如下圖:
這里,業(yè)務(wù)組件1和業(yè)務(wù)組件3同時向業(yè)務(wù)組件2提供服務(wù),即業(yè)務(wù)組件2需要同時依賴業(yè)務(wù)組件3和業(yè)務(wù)組件1.
現(xiàn)在我們再來看一種更糟糕的情況:
由此看來,在業(yè)務(wù)復雜的情況下,組件與組件之間的相互依賴會帶來兩個問題:
- 重復依賴:比如可能存在業(yè)務(wù)組件3依賴業(yè)務(wù)組件1,而業(yè)務(wù)組件2又依賴業(yè)務(wù)組件3和業(yè)務(wù)組件1,此時就導致了業(yè)務(wù)組件1被重復依賴.
- 子系統(tǒng)通信方式不能依靠傳統(tǒng)的顯示意圖.在該種模型下,使用顯示意圖將導致組件高度耦合.比如業(yè)務(wù)組件2依賴業(yè)務(wù)組件1,并通過顯示意圖的方式進行通信,一旦業(yè)務(wù)組件1不再使用,那么業(yè)務(wù)組件2中使用現(xiàn)實意圖的地方會出現(xiàn)錯誤,這顯然與我們組件化的目的背道而馳.
解決組件通信
先來解決業(yè)務(wù)組件通信問題.當年看到上面那張復雜的組件通信圖時,我們不難想到操作系統(tǒng)引入總線機制來解決設(shè)備掛載問題,同樣,借用總線的概念我們在工程添加"組件總線",用于不同組件間的通信,此時結(jié)構(gòu)如下:
所有掛載到組件總線上的業(yè)務(wù)組件,都可以實現(xiàn)雙向通信.而通信協(xié)議和HTTP通信協(xié)議類似,即基于URL的方式進行.至于實現(xiàn)的方式一種可以基于系統(tǒng)提供的隱式意圖的方式,另一種則是完全自行實現(xiàn)組件總線.這篇文章不打算在此不做詳細說明了.
解決重復依賴
對于采用aar方式輸出的Library而言,在構(gòu)建項目時,gradle會為我們保留最新版本的aar,換言之,如果以aar的方式向主工程提供提供依賴不會存在重復依賴的問題.而如果是直接以project形式提供依賴,則在打包過程中會出現(xiàn)重復的代碼.解決project重復依賴問題目前有兩種做法:1.對于純代碼工程的庫或jar包而言,只在最終項目中執(zhí)行compile,其他情況采用provider方式;2.在編譯時檢測依賴的包,已經(jīng)依賴的不再依賴
資源id沖突
在合并多個組件到主工程中時,可能會出現(xiàn)資源引用沖突,
最簡單的方式是通過實現(xiàn)約定資源前綴名(resourcePrefix)來避免,需要在組件的gradle腳本中配置:
andorid{
...
buildTypes{
...
}
resourcePrefix "moudle_prefix"
}
一旦配置resourcePrefix,所有的資源必須以該前綴名開頭.比如上面配置了前綴名為moudle_prefix,那么所有的資源名都要加上該前綴,如:mouble_prefix_btn_save.
組件上下文(Context)
最后需要注意在Debug模式下和Release模式下,所需要的Context是否是你所希望的,以避免產(chǎn)生強轉(zhuǎn)異常.
結(jié)束語
最早接觸組件化這個概念是在從事廣告SDK工作中,最近陸續(xù)續(xù)的做了一些總結(jié),因此有了這篇關(guān)于"組件化開發(fā)"的文章.另外,組件化開發(fā)不是銀彈,并不能完全解決當前業(yè)務(wù)復雜的情況,在進行項目實施和改進之前,一定要多加考量.
關(guān)于Demo,后面我會再"師父說"中提交.有興趣的同學聯(lián)系我,相互交流.當然也可以關(guān)注我,搜索"代碼之道,編程之法".
