Android系統上移動組件化應用框架設計

李 勇 張 俊

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

0 引 言

移動互聯網就是將移動通信和互聯網相結合起來，其正逐漸滲透到我們的生活、學習和工作當中。隨著移動互聯網用戶規模激增，移動應用市場成為企業發展的必爭之地[2]。

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

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

1 組件化和相關技術介紹

1.1 組件化原理

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

1.2 組件化開發框架

組件化開發是把重復代碼提煉封裝成一個個組件提供功能服務，即把一個App拆分成多個Module，每個Module就是一個組件，各組件間低耦合、高內聚，可以相互調用，但不能相互依賴，每個組件可以單獨調試運行，組合各組件就可以得到一個完整的應用[10]。

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

圖1 組件化開發框架結構圖

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

圖2 知乎Android組件化開發框架結構圖

1.3 多渠道打包

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

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

2 移動組件化應用框架設計

2.1 應用框架整體設計

本應用框架一共分為四層，從低到高依次是基礎功能組件層、基礎業務組件層、普通業務組件層、宿主層(App殼工程)，其中基礎功能組件層和基礎業務組件層構成移動端基礎中臺。該框架能解決單一工程開發架構和組件層次不清的問題，具有以下優點：

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

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

圖3為移動端組件化應用框架結構圖。

圖3 基于Android系統的組件化應用框架結構圖

2.2 應用框架各層實現

2.2.1基礎功能組件層

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

2.2.2基礎業務組件層

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

2.2.3普通業務組件層

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

圖4為移動端業務組件化通信結構圖。

圖4 業務組件通信結構圖

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

圖5 App業務組件劃分

//集成開發模式

apply plugin:’com.android.library’

//組件開發模式，可以獨立運行

apply plugin:’com.android.application’

(2) 核心路由組件。在Android中，通過startActivity來實現頁面間的跳轉。但是根據組件化遵循的原則，業務組件按照功能模塊進行拆分解耦之后是不能相互依賴的，那么核心路由組件就可以解決組件之間通信跳轉的問題。路由的定義是通過網絡把信息從源地址傳輸到目的地址的過程[6]。組件化之后所有頁面跳轉必須通過定義的資源標識符來實現，因此可以為每個頁面定義一個統一的資源標識符，在網絡中能夠被其他頁面訪問，從而實現不同組件的通信跳轉。業界主流的路由框架包括阿里的ARouter和美團的WMRouter。

2.2.4宿主層

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

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

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

2.3 基礎庫和版本管理

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

3 應用程序實例

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

圖6 移動端組件化項目結構圖

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

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

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

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

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

isNeedLoginModule=false

isNeedOrderModule=false

即可單獨編譯loginModule和orderModule組件。

項目工程已由集成模式變為組件模式打包，如圖8所示。

圖8 集成模式轉組件模式打包示意圖

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

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

需要注意的是，由于Android的API14后，組件開發中的資源不再是常量[10]，因此，對于多個控件的監聽需要由switch-case轉為if-else if-else結構。

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

圖9 由殼App跳轉到組件一

圖10 由組件一跳轉到組件二

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

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

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

4 結 語

總之，隨著移動互聯網技術的發展，人們對Android系統應用軟件的研發也提出了更高的要求，在保證應用軟件功能實現的基礎上，合理地對開發框架進行優化，可以提升開發系統的使用效率、提高代碼的復用率。因此，這種組件化開發框架在移動互聯網產業開發中具有很高的實用價值，不僅能夠有效提高個人和企業開發效率，提升應用軟件價值，更能為互聯網企業創造更高的效益和利潤。