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'
}
           

• 1
• 2
• 3
• 4
• 5
• 6

除此之外,子工程中在不同的運作方式下,其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
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

元件通信與元件依賴

在”主工程多元件”這種理想模型下業務元件是不存在互相通信和依賴的,但現實卻是相反的,如下圖: 

這裡,業務元件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"

}
           

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

一旦配置resourcePrefix,所有的資源必須以該字首名開頭.比如上面配置了字首名為moudle_prefix,那麼所有的資源名都要加上該字首,如:mouble_prefix_btn_save.

元件上下文(Context)

最後需要注意在Debug模式下和Release模式下,所需要的Context是否是你所希望的,以避免産生強轉異常.

結束語

最早接觸元件化這個概念是在從事廣告SDK工作中,最近陸續續的做了一些總結,是以有了這篇關于”元件化開發”的文章.另外,元件化開發不是銀彈,并不能完全解決目前業務複雜的情況,在進行項目實施和改進之前,一定要多加考量.

敬請期待第二篇,我們将在第二篇内介紹如何對項目實施元件化.

原文位址：http://blog.csdn.net/dd864140130/article/details/53645290