李 勇 張 俊

1(中科美絡(luò)科技股份有限公司 安徽 合肥 230000) 2(中國科學(xué)院合肥物質(zhì)科學(xué)研究院 安徽 合肥 230000)

0 引 言

移動互聯(lián)網(wǎng)就是將移動通信和互聯(lián)網(wǎng)相結(jié)合起來，其正逐漸滲透到我們的生活、學(xué)習(xí)和工作當(dāng)中。隨著移動互聯(lián)網(wǎng)用戶規(guī)模激增，移動應(yīng)用市場成為企業(yè)發(fā)展的必爭之地[2]。

隨著Android版本6.0以后，Android Studio(AS)成為主流的開發(fā)工具，其集成開發(fā)環(huán)境(IDE)提供了豐富的功能插件和高效的用戶體驗(yàn)。此時，單一工程開發(fā)框架隨著用戶需求的增長，其代碼逐漸變得臃腫和高耦合，任何修改需編譯整個項(xiàng)目工程，調(diào)試非常耗時，且影響團(tuán)隊(duì)協(xié)同開發(fā)效率。因此，接入組件化開發(fā)是未來Android大型工程開發(fā)的趨勢[5]。

本文基于組件化和分層設(shè)計思想，同時結(jié)合多渠道深度定制的特點(diǎn)，提出了一種移動端組件化開發(fā)框架設(shè)計方案。本應(yīng)用框架基于Android系統(tǒng)移動設(shè)備平臺，實(shí)現(xiàn)一套代碼管理生成多個App應(yīng)用的需求[8]。特別是在項(xiàng)目龐大、功能模塊復(fù)雜的場景下，其可以實(shí)現(xiàn)團(tuán)隊(duì)人員的并行研發(fā)及應(yīng)用組件的單獨(dú)編譯運(yùn)行，有助于提高研發(fā)效率。

1 組件化和相關(guān)技術(shù)介紹

1.1 組件化原理

Android組件化設(shè)計使用的IDE是Android Studio(AS)。AS不僅提供Android軟件開發(fā)環(huán)境，而且IDE提供Gradle插件負(fù)責(zé)項(xiàng)目編譯過程，組件化的實(shí)現(xiàn)就是由AS集成的Modules功能與編譯插件Gradle完成[10]。AS項(xiàng)目中，可以添加library庫作為一個獨(dú)立的依賴文件，為主工程提供功能服務(wù)和數(shù)據(jù)服務(wù)[11]。而IDE提供的Gradle插件，負(fù)責(zé)Android工程的依賴、編譯、打包等過程，組件化設(shè)計使用Gradle插件在通用構(gòu)建規(guī)則下，通過Groovy語言為Gradle制定新的構(gòu)建規(guī)則，動態(tài)改變項(xiàng)目的編譯過程[11]。在開發(fā)階段，通過修改Gradle文件配置，將組件變成可獨(dú)立運(yùn)行模式；在集成階段，通過修改Gradle文件配置，將組件變成library依賴添加到App主體工程中。

1.2 組件化開發(fā)框架

組件化開發(fā)是把重復(fù)代碼提煉封裝成一個個組件提供功能服務(wù)，即把一個App拆分成多個Module，每個Module就是一個組件，各組件間低耦合、高內(nèi)聚，可以相互調(diào)用，但不能相互依賴，每個組件可以單獨(dú)調(diào)試運(yùn)行，組合各組件就可以得到一個完整的應(yīng)用[10]。

組件化開發(fā)能降低Android業(yè)務(wù)開發(fā)的耦合性、提高編譯速度和協(xié)同開發(fā)效率，是未來Android大型工程開發(fā)的趨勢[4]。通常組件的劃分一般包括App殼工程、業(yè)務(wù)組件和功能組件(含第三方庫)，如圖1所示，但隨著需求的增多與版本的迭代升級，帶來的主要問題就是框架層次不清晰，不利于后續(xù)維護(hù)。

圖1 組件化開發(fā)框架結(jié)構(gòu)圖

知乎Android客戶端早期使用的也是單一工程開發(fā)框，所有業(yè)務(wù)邏輯都放在主工程App中，后來隨著業(yè)務(wù)的發(fā)展，代碼耦合導(dǎo)致的問題逐漸顯現(xiàn)出來，開始采用組件化重構(gòu)，分為主工程、業(yè)務(wù)組件、基礎(chǔ)組件、基礎(chǔ)SDK[8]，如圖2所示。該開發(fā)框架是組件化開發(fā)框架實(shí)踐的一個很好案例，但隨著用戶需求的變化，深度定制的問題就顯現(xiàn)出來，特別是面向不同客戶群體的私有化部署，對App名稱、logo和啟動頁等都有差異化要求，需要滿足做好一套代碼管理生成多個App應(yīng)用的需求，以提高開發(fā)效率，節(jié)約企業(yè)人力成本。

圖2 知乎Android組件化開發(fā)框架結(jié)構(gòu)圖

1.3 多渠道打包

多渠道包是為了滿足在不同應(yīng)用市場運(yùn)營統(tǒng)計的需求，在安裝包中添加不同標(biāo)識的過程[5]?；贗DE提供的Gradle插件來修改manifest中的mate-date內(nèi)容，可以在Java中通過API獲取對應(yīng)的統(tǒng)計數(shù)據(jù)。

多渠道打包分為兩種，第一種是為了簡單的渠道標(biāo)識，通常在代碼中做一些必要的邏輯處理；第二種是為了對代碼、資源、配置等做深度的定制，如設(shè)置不同的AppId、啟動頁、logo和App名稱等，通常采用官方的productflavors實(shí)現(xiàn)[8]。本文采用第二種實(shí)現(xiàn)方式，以實(shí)現(xiàn)App的深度定制，滿足市場的需要。

2 移動組件化應(yīng)用框架設(shè)計

2.1 應(yīng)用框架整體設(shè)計

本應(yīng)用框架一共分為四層，從低到高依次是基礎(chǔ)功能組件層、基礎(chǔ)業(yè)務(wù)組件層、普通業(yè)務(wù)組件層、宿主層(App殼工程)，其中基礎(chǔ)功能組件層和基礎(chǔ)業(yè)務(wù)組件層構(gòu)成移動端基礎(chǔ)中臺。該框架能解決單一工程開發(fā)架構(gòu)和組件層次不清的問題，具有以下優(yōu)點(diǎn)：

(1) 解耦性：組件之間相互解耦，彼此互不影響，業(yè)務(wù)組件之間通過路由進(jìn)行通信；(2) 可定制：通過多渠道配置，可以定制不同應(yīng)用ID的App，批量生成多個不同應(yīng)用App；(3) 層次性：對移動端基礎(chǔ)中臺再劃分，使框架層次更加清晰，符合“組件化架構(gòu)”的思想。

同時，各組件層之間須遵循兩個原則：(1) 只有上層組件才能依賴下層組件，不能反向依賴；(2) 同層之間的組件不能相互依賴，以達(dá)到組件間解耦的目的。

圖3為移動端組件化應(yīng)用框架結(jié)構(gòu)圖。

圖3 基于Android系統(tǒng)的組件化應(yīng)用框架結(jié)構(gòu)圖

2.2 應(yīng)用框架各層實(shí)現(xiàn)

2.2.1基礎(chǔ)功能組件層

開發(fā)應(yīng)用程序過程中，工具類是幫助我們快速開發(fā)的基礎(chǔ)，它不但可以精簡代碼結(jié)構(gòu)，還有利于提高團(tuán)隊(duì)開發(fā)效率。該層組件是對基礎(chǔ)功能的抽取，封裝成一些通用的工具類，不包含任何業(yè)務(wù)邏輯，為上層提供簡潔、易用的訪問接口[7]。例如：網(wǎng)絡(luò)訪問組件封裝了網(wǎng)絡(luò)的請求訪問能力；數(shù)據(jù)存儲組件封裝了數(shù)據(jù)緩存的能力；版本更新組件封裝了App應(yīng)用版本升級的能力；自定義view組件提供了全局通用的視圖資源庫。

2.2.2基礎(chǔ)業(yè)務(wù)組件層

除了基礎(chǔ)工具類的封裝，在系統(tǒng)開發(fā)過程中，一些通用的業(yè)務(wù)能力也可以封裝成組件。它對下依賴基礎(chǔ)功能組件，對上提供支撐上層業(yè)務(wù)組件運(yùn)行的通用業(yè)務(wù)能力。例如公共業(yè)務(wù)組件，它封裝了BaseActivity、BaseFragment、BaseApplication等基類信息；推送能力組件，它封裝了極光、個推等消息推送能力；支付能力組件，它提供支付寶、微信和銀聯(lián)支付能力等。對基礎(chǔ)業(yè)務(wù)組件進(jìn)行封裝，建立移動端基礎(chǔ)業(yè)務(wù)中臺，將移動端應(yīng)用框架核心能力以共享服務(wù)中心進(jìn)行沉淀，能最大限度地提升團(tuán)隊(duì)協(xié)作效率[6]。

2.2.3普通業(yè)務(wù)組件層

普通業(yè)務(wù)組件層是業(yè)務(wù)組件存放的容器，它包含業(yè)務(wù)組件和核心路由組件兩個部分。每個業(yè)務(wù)組件既可以單獨(dú)打包成APK在手機(jī)上運(yùn)行，又可以向上提供給宿主層集成。同時每個業(yè)務(wù)組件通過核心路由組件實(shí)現(xiàn)業(yè)務(wù)通信，實(shí)現(xiàn)業(yè)務(wù)組件之間的解耦。

圖4為移動端業(yè)務(wù)組件化通信結(jié)構(gòu)圖。

圖4 業(yè)務(wù)組件通信結(jié)構(gòu)圖

(1) 業(yè)務(wù)組件。業(yè)務(wù)組件通常按照功能模塊進(jìn)行劃分[10]，如圖5所示。例如用戶模塊組件封裝了用戶個人中心業(yè)務(wù)相關(guān)的功能模塊，包括注冊登錄等；積分模塊組件封裝了積分業(yè)務(wù)相關(guān)的功能模塊等。通過Gradle腳本配置方式，實(shí)現(xiàn)集成模式和組件模式切換，其中組件模式需要對AndroidManifest文件中設(shè)置入口Activity，即可單獨(dú)運(yùn)行編譯，以提高開發(fā)人員調(diào)試編譯效率；集成模式則以library形式集成在宿主層。其配置是在業(yè)務(wù)組件的build.gradle中，關(guān)鍵配置如下：

圖5 App業(yè)務(wù)組件劃分

//集成開發(fā)模式

apply plugin:’com.android.library’

//組件開發(fā)模式，可以獨(dú)立運(yùn)行

apply plugin:’com.android.application’

(2) 核心路由組件。在Android中，通過startActivity來實(shí)現(xiàn)頁面間的跳轉(zhuǎn)。但是根據(jù)組件化遵循的原則，業(yè)務(wù)組件按照功能模塊進(jìn)行拆分解耦之后是不能相互依賴的，那么核心路由組件就可以解決組件之間通信跳轉(zhuǎn)的問題。路由的定義是通過網(wǎng)絡(luò)把信息從源地址傳輸?shù)侥康牡刂返倪^程[6]。組件化之后所有頁面跳轉(zhuǎn)必須通過定義的資源標(biāo)識符來實(shí)現(xiàn)，因此可以為每個頁面定義一個統(tǒng)一的資源標(biāo)識符，在網(wǎng)絡(luò)中能夠被其他頁面訪問，從而實(shí)現(xiàn)不同組件的通信跳轉(zhuǎn)。業(yè)界主流的路由框架包括阿里的ARouter和美團(tuán)的WMRouter。

2.2.4宿主層

宿主層(App殼工程)集成普通業(yè)務(wù)組件，它包含兩個配置，分別為組件依賴配置和多渠道配置，沒有任何代碼邏輯。開發(fā)者可以根據(jù)組件依賴配置，選擇普通業(yè)務(wù)組件到宿主層中，同時依據(jù)多渠道配置生成不同應(yīng)用ID的App。通過上述配置，可以達(dá)到一套代碼管理生成多個App應(yīng)用的目的。

(1) 組件依賴配置。Android Studio采用Gradle構(gòu)建項(xiàng)目，創(chuàng)建Android項(xiàng)目時會在宿主層App下生成build.gradle配置文件(其他組件類似)，其支持自定義構(gòu)建配置，包括組件依賴的配置。

(2) 多渠道配置。多渠道打包能為應(yīng)用市場個性化的要求實(shí)現(xiàn)更深度的定制，包括生成不同應(yīng)用ID、應(yīng)用圖標(biāo)和啟動頁等，實(shí)現(xiàn)一套代碼生成多個個性化App應(yīng)用的目的，其配置依然是在宿主層App下的build.gradle中。

2.3 基礎(chǔ)庫和版本管理

在組件化實(shí)施過程中，不同組件依賴的SDK版本不一致或者引入的第三方庫版本不一致則會導(dǎo)致兼容性問題而使項(xiàng)目無法編譯[5]。在此，引入配置文件config.xml對基礎(chǔ)庫與版本集中管理，同時通過腳本配置完成組件對配置文件的依賴，達(dá)到每個組件依賴的SDK版本和第三方庫版本一致的目的。

3 應(yīng)用程序?qū)嵗?/h2>

按照上述組件化開發(fā)框架設(shè)計，完成了測試工程的基本搭建。項(xiàng)目工程包括一個App殼工程(含多渠道配置和組件依賴配置)、普通業(yè)務(wù)組件層commonBusinessModule(含路由組件框架)、移動端基礎(chǔ)中臺(含基礎(chǔ)業(yè)務(wù)組件baseBusinessModule和基礎(chǔ)功能組件baseFunctionModule)，工程項(xiàng)目結(jié)構(gòu)如圖6所示。

圖6 移動端組件化項(xiàng)目結(jié)構(gòu)圖

測試程序以殼工程App下面的Activity為主界面，分別對App、普通業(yè)務(wù)組件loginModule和orderModule進(jìn)行開發(fā)測試，修改config.gradle和gradle.properties中的全局配置變量。

(1) 多渠道配置測試。實(shí)現(xiàn)定制不同應(yīng)用ID、不同logo、不同名稱等的App。修改殼工程App下的build.gradle渠道配置，同時在殼工程App/src目錄之下新建對應(yīng)渠道的名稱(和build.gradle中名稱一致)，然后在渠道目錄之下新建res資源文件(和main下的res一樣)，用于定制不同應(yīng)用App的logo、啟動頁等資源。

多渠道打包效果圖如圖7所示。

圖7 多渠道的資源配置示意圖和打包效果圖

(2) 組件依賴配置測試。修改gradle.properties中的全局配置變量為：

isNeedLoginModule=false

isNeedOrderModule=false

即可單獨(dú)編譯loginModule和orderModule組件。

項(xiàng)目工程已由集成模式變?yōu)榻M件模式打包，如圖8所示。

圖8 集成模式轉(zhuǎn)組件模式打包示意圖

(3) 路由功能測試。本測試工程使用阿里的ARouter路由框架。為每個普通業(yè)務(wù)組件的啟動窗口添加如下注解代碼，如loginModule組件的路由路徑為：@Route(path=“路由地址常量”)，控件點(diǎn)擊觸發(fā)路由跳轉(zhuǎn)部分代碼如下：

ARouter.getInstance().build(“路由地址”).navigation()

需要注意的是，由于Android的API14后，組件開發(fā)中的資源不再是常量[10]，因此，對于多個控件的監(jiān)聽需要由switch-case轉(zhuǎn)為if-else if-else結(jié)構(gòu)。

測試由殼App跳轉(zhuǎn)到loginModule組件和orderModule組件(如圖9所示)，orderModule組件跳轉(zhuǎn)到loginModule組件(如圖10所示)。

圖9 由殼App跳轉(zhuǎn)到組件一

圖10 由組件一跳轉(zhuǎn)到組件二

(4) 整體測試。本測試包括把所有組件以集成模式打包成一個App；把所有組件單獨(dú)編譯生成獨(dú)立的App。

修改gradle.properties中的組件全局配置變量，通過編譯得到一個由組件組合的完整App應(yīng)用，如圖11所示。圖11中前三個App由組件組合編譯而成(包括多渠道的定制配置，如logo、名稱)，最后兩個App是由loginModule組件和orderModule組件單獨(dú)編譯生成。

圖11 集成模式打包和組件模式打包的APK

4 結(jié) 語

總之，隨著移動互聯(lián)網(wǎng)技術(shù)的發(fā)展，人們對Android系統(tǒng)應(yīng)用軟件的研發(fā)也提出了更高的要求，在保證應(yīng)用軟件功能實(shí)現(xiàn)的基礎(chǔ)上，合理地對開發(fā)框架進(jìn)行優(yōu)化，可以提升開發(fā)系統(tǒng)的使用效率、提高代碼的復(fù)用率。因此，這種組件化開發(fā)框架在移動互聯(lián)網(wǎng)產(chǎn)業(yè)開發(fā)中具有很高的實(shí)用價值，不僅能夠有效提高個人和企業(yè)開發(fā)效率，提升應(yīng)用軟件價值，更能為互聯(lián)網(wǎng)企業(yè)創(chuàng)造更高的效益和利潤。