Android 開發:由模塊化到組件化

模塊化和組件化

模塊化

組件化不是個新概念,其在各行各業都一直備受重視.至於組件化何時在軟件工程領域提出已經無從考究了,不過呢能夠確認的是組件化最先應用於服務端開發,後來在該思想的指導下,前端開發和移動端開發也產生各自的開發方式.

在瞭解組件化以前,先來回顧下模塊化的定義

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.

簡單來講,模塊化就是將一個程序按照其功能作拆分，分紅相互獨立的模塊，以便於每一個模塊只包含與其功能相關的內容。模塊咱們相對熟悉,好比登陸功能能夠是一個模塊,搜索功能能夠是一個模塊,汽車的發送機也但是一個模塊.

組件化

如今來看看」組件化開發」,這裏咱們看一下其定義:

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.

通俗點就是:組件化就是基於可重用的目的，將一個大的軟件系統按照分離關注點的形式，拆分紅多個獨立的組件，已較少耦合。

咋樣一看仍是很是抽象,說了這麼多好像仍是不明白.什麼是組件呢?組件能夠是模塊、web資源,軟件包,好比汽車的發動機是一個模塊,也是一個組件,再或者前端中的一個日曆控件是一個模塊,也一個組件.

模塊化 vs 組件化

當你看到這的時候,想必心理一陣惡寒:模塊化?組件化?究竟是什麼鬼?有啥區別. 
有這種感受纔是對的,模塊化和組件化本質思想是同樣的,都是」大化小」,二者的目的都是爲了重用和解耦,只是叫法不同.若是非要說區別,那麼能夠認爲模塊化粒度更小,更側重於重用,而組件化粒度稍大於模塊,更側重於業務解耦.

組件化優缺點

組件化開發的好處是顯而易見:系統級的控制力度細化到組件級的控制力度,一個複雜系統的構建最後就是組件集成的結果.每一個組件都有本身獨立的版本,能夠獨立的編譯,測試,打包和部署

產品組件化後可以實現完整意義上的按需求進行產品配置和銷售,用戶能夠選擇使用那些組件,組件之間能夠靈活的組建.

配置管理,開發,測試,打包,發佈徹底控制到組建層面,並帶來不少好處.好比一個組件小版本進行升級,若是對外提供的接口沒有發生任何變化,其餘組件徹底不須要再進行測試.

可是組件化的實施對開發人員和團隊管理者提出了更高水平的要求.相對傳統方式,在項目的管理和組織上難度加大,要求開發人員對業務有更深層次上的理解.

進軍Android 項目

爲何要在Android中實行組件化開發

爲何要在Android中實行組件化開發呢,其根本緣由在於業務的增加提升了項目的複雜性,爲了更好的適應團隊開發,提升開發效率,實行組件化乃大勢所趨.

爲了更好的幫助你們理解上面這句話,我將從最先的Android 項目開發方式提及.

簡單開發模型

所謂的簡單開發模型是最基礎的開發方式,工程中沒有所謂的模塊,沒有所謂的規劃,常見於初學者學習階段或者是我的學習過程所寫的demo,其結構大概以下: 

不難發現,每每是在一個界面中存在着大量的業務邏輯,而業務邏輯中充斥着各類各類網絡請求,數據操做等行爲,整個項目中沒有所謂的模塊的概念,項目組成的基本單位不是模塊,而是方法級的.

關於這種開發模型沒什麼須要介紹的,咱們早期都經歷過,如今除了不多很是古老的項目以及初學者練手之做,已經不多見到.

單工程開發模型

該種開發模型已經有了明確的模塊劃分,而且經過邏輯上的分層呈現出較好結構,該模型最爲咱們所熟悉,一般用於早期產品的快速開發,團隊規模較小的狀況下.該種開發模型結構以下: 

隨着產品的迭代,業務愈來愈複雜,隨之帶來的是項目結構複雜度的極度增長,此時咱們面臨着幾個問題:

1. 實際業務變化很是快,可是工程以前的業務模塊耦合度過高,牽一髮而動全身.
2. 對工程所作的任何修改都必需要編譯整個工程
3. 功能測試和系統測試每次都要進行.
4. 團隊協同開發存在較多的衝突.不得不花費更多的時間去溝通和協調,而且在開發過程當中,任何一位成員沒辦法專一於本身的功能點,影響開發效率.
5. 不能靈活的對工程進行配置和組裝.好比今天產品經理說加上這個功能,明天又說去掉,後天在加上.

在面臨這些問題的前提下,咱們從新來思考組件化,看看它是否能解決咱們在Android 項目開發中所遇到的難題.

主工程多組件開發模型

藉助組件化這一思想,咱們在」單工程」模型的基礎上,將業務層中的各業務抽取出來,封裝成相應的業務組件,將基礎庫中各部分抽取出來,封裝成基礎組件,而主工程是一個可運行的app,做爲各組件的入口(主工程也被稱之爲殼程序).這些組件或以jar的形式呈現,或以aar的形式呈現.主工程經過依賴的方式使用組件所提供的功能.

(須要注意這是理想狀態下的結構圖,實際項目中,業務組件之間會產生通訊,也會產生依賴,關於這一點,咱們在下文會談)

不管是jar仍是aar,本質上都是Library,他們不能脫離主工程而單獨的運行.當團隊中成員共同參與項目的開發時,每一個成員的開發設備中必須至少同時具有主工程和各自負責組件,不難看出經過對項目實行組件化,每一個成員能夠專一本身所負責的業務,並不影響其餘業務,同時藉助穩定的基礎組件,能夠極大減小代碼缺陷,於是整個團隊能夠以並行開發的方式高效的推動開發進度.

不但如此,組件化能夠靈活的讓咱們進行產品組裝,要作的無非就是根據需求配置相應的組件,最後生產出咱們想要的產品.這有點像玩積木,經過不一樣擺放,咱們就能獲得本身想要的形狀.

對測試同窗而言,能有效的減小測試的時間:原有的業務不須要再次進行功能測試,能夠專一於發生變化的業務的測試,以及最終的集成測試便可.

到如今爲止,咱們已經有效解決了」單工程開發模型」中一些問題,對於大部分團隊來講這種已經能夠了,可是該模型仍然存在一些能夠改進的點:每次修改依賴包,就須要從新編譯生成lib或者aar.好比說小顏同窗接手了一個項目有40多個組件,在最後集成全部組件的時候,小顏同窗發現其中某組件存在問題,爲了定位和修改該組件中的問題,小顏同窗不斷這調試該組件.因爲在該模型下,組件不能脫離主工程,那麼意味着,每次修改後,小顏同窗都要在漫長的編譯過程當中等待.更糟糕的是,如今離上線只有5小時了,每次編譯10分鐘,爲改這個bug,編譯了20次,恩….什麼也不用幹了,能夠提交離職報告了

如何解決這種每次修改組件都要連同主工程一塊兒編譯的問題?下面咱們來看主工程多子工程開發模型是如何解決該問題的.

主工程多子工程開發模型

該種開發模型在」主工程多組件」開發模型的基礎上作了改進,其結構圖以下:

不難發現,該種開發模型在結構上和」主工程多組件」並沒有不一樣,惟一的區別在於:全部業務組件再也不是mouble而是做爲一個子工程,基礎組件可使moudle,也能夠是子工程,該子工程和主工程不一樣:Debug模式下下做爲app,能夠單獨的開發,運行,調試;Release模式下做爲Library,被主工程所依賴,向主工程提供服務.

在該種模型下,當小顏同窗發現某個業務組件存在缺陷,會如何作呢?好比是基礎組件2出現問題,因爲在Debug模式下,基礎組件2做爲app能夠獨立運行的,所以能夠很容易地對該模塊進行單獨修改,調試.最後修改完後只須要從新編譯一次整個項目便可.

不難發現該種開發模型有效的減小了全編譯的次數,減小編譯耗時的同時,方便開發者進行開發調試.

對測試同窗來講,功能測試能夠提早,而且可以及時的參與到開發環節中,將風險降到最低.

到如今,咱們在理論層次上講明瞭採用組件化開發給咱們帶來的便利,空口無憑是沒有說服力的,在下面的一小節中,咱們來談談如何組件化在Android中的實施過程.

組件化過程當中遇到的問題

組件劃分

組件化首要作的事情就是劃分組件.如何劃分並無一個確切的標準,我建議早期實施組件化的時候,能夠以一種」較粗」的粒度來進行,這樣左右的好處在於後期隨着對業務的理解進行再次細分,而不會有太大的成本.固然,我建議劃分組件這一工做有團隊架構人員和業務人員協商定製.

子工程工做方式切換

在」主工程多子工程模型」中,咱們提到子工程在Debug模式下作爲單獨的Application運行,在Release模式下做爲Library運行,如何去動態修改子工程的運行模式呢?咱們都知道採用Gradle構建的工程中,用apply plugin: 'com.android.application'來標識該爲Application,而apply plugin: 'com.android.library'標誌位Library.所以,咱們能夠在編譯的是同經過判斷構建環境中的參數來修改子工程的工做方式,在子工程的gradle腳本頭部加入如下腳本片斷:

if (isDebug.toBoolean()) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

•  

除此以外,子工程中在不一樣的運行方式下,其AndroidMainifest.xml也是不相同的,須要爲其分別提供本身AndroidManifest.xml文件:在子工程src目錄下(其餘位置建立)建立兩個目錄,用來存放不一樣的AndroidManifest.xml,好比這裏我建立了debug和release目錄 
 
接下來一樣須要在該子工程的gradle構建腳本中根據構建方式制定:

android {
    sourceSets {
        main {
            if(isDebug.toBoolean()) {
                manifest.srcFile 'src/debug/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/release/AndroidManifest.xml'
            }
        }
    }
}

•  

組件通訊與組件依賴

在」主工程多組件」這種理想模型下業務組件是不存在相互通訊和依賴的,但現實倒是相反的,以下圖: 

這裏,業務組件1和業務組件3同時向業務組件2提供服務,即業務組件2須要同時依賴業務組件3和業務組件1.

如今咱們再來看一種更糟糕的狀況: 

由此看來,在業務複雜的狀況下,組件與組件之間的相互依賴會帶來兩個問題:

• 重複依賴:好比可能存在業務組件3依賴業務組件1,而業務組件2又依賴業務組件3和業務組件1,此時就致使了業務組件1被重複依賴.
• 子系統通訊方式不能依靠傳統的顯示意圖.在該種模型下,使用顯示意圖將致使組件高度耦合.好比業務組件2依賴業務組件1,並經過顯示意圖的方式進行通訊,一旦業務組件1再也不使用,那麼業務組件2中使用現實意圖的地方會出現錯誤,這顯然與咱們組件化的目的背道而馳.

解決組件通訊

先來解決業務組件通訊問題.當年看到上面那張複雜的組件通訊圖時,咱們不難想到操做系統引入總線機制來解決設備掛載問題,一樣,借用總線的概念咱們在工程添加」組件總線」,用於不一樣組件間的通訊,此時結構以下: 

全部掛載到組件總線上的業務組件,均可以實現雙向通訊.而通訊協議和HTTP通訊協議相似,即基於URL的方式進行.至於實現的方式一種能夠基於系統提供的隱式意圖的方式,另外一種則是徹底自行實現組件總線.這篇文章不打算在此不作詳細說明了.

解決重複依賴

對於採用aar方式輸出的Library而言,在構建項目時,gradle會爲咱們保留最新版本的aar,換言之,若是以aar的方式向主工程提供提供依賴不會存在重複依賴的問題.而若是是直接以project形式提供依賴,則在打包過程當中會出現重複的代碼.解決project重複依賴問題目前有兩種作法:1.對於純代碼工程的庫或jar包而言,只在最終項目中執行compile,其餘狀況採用provider方式;2.在編譯時檢測依賴的包,已經依賴的再也不依賴

資源id衝突

在合併多個組件到主工程中時,可能會出現資源引用衝突, 
最簡單的方式是經過實現約定資源前綴名(resourcePrefix)來避免,須要在組件的gradle腳本中配置:

andorid{
    ...

    buildTypes{
        ...
    }

    resourcePrefix "moudle_prefix"

}

• 一旦配置resourcePrefix,全部的資源必須以該前綴名開頭.好比上面配置了前綴名爲moudle_prefix,那麼全部的資源名都要加上該前綴,如:mouble_prefix_btn_save.

組件上下文(Context)

最後須要注意在Debug模式下和Release模式下,所須要的Context是不是你所但願的,以免產生強轉異常.

結束語

最先接觸組件化這個概念是在從事廣告SDK工做中,最近陸續續的作了一些總結,所以有了這篇關於」組件化開發」的文章.另外,組件化開發不是銀彈,並不能徹底解決當前業務複雜的狀況,在進行項目實施和改進以前,必定要多加考量.