Android組件化架構設計與實踐

標籤：XML   啟動進程   登入   static   網路   架構設計   blog   proguard   生活   

在目前移動互連網時代，每個 APP 就是流量入口，與過去 PC 網頁瀏覽器時代不同的是，APP 的體驗與迭代速度影響著使用者的粘性，這同時也對從事移動開發人員提出更高要求，進而移動端架構也層出不窮。

顯示的是傳統的服務端架構和用戶端 App 架構對比。傳統的服務端架構中最底下是一個 OS，一般是 Linux，最上面服務端的業務，而中間有非常多的層次可以在架構上，按照我們的意願搭建中間的各個層次的銜接環節，使得架構具有足夠的靈活性和擴充性。但是到了 App 就會面對一個完全不同的現狀，App 的OS（Android或iOS）本質上並不是一個很瘦的像 Linux 這樣的 OS，而是在 OS 上有一個很重的 App Framework，開發一個普通的用戶端應用所要用到的絕大多數介面都在 Framework 裡，而上面的業務也是一個非常複雜多樣化的業務，最後會發現“架構”是在中間的一個非常尷尬的夾心層，因為會遇到很多在服務端架構中不需要面臨的挑戰。比如以下兩點：

• 體積的制約。體積對使用者來說是一個非常敏感的概念，如果我們要在架構上做很多事情的話，通常意味著架構佔據的代碼量會比較大。在服務端架構中我們可以容忍我們在架構層面去做幾十兆的代碼。但是對於用戶端架構，即使你的架構只有一兩兆，對於一個用戶端可能都佔據了 10%，20%的容量。
• 效能的挑戰。從效能上來看，對於服務端架構我們通常關注的是吞吐率，我們不會去關注啟動速度。一個服務端的啟動哪怕是花了一兩分鐘，只要它運作起來吞吐率足夠高，支援的並發能力足夠好，響應速度足夠快，我們就認為這是一個良好的架構。但用戶端不同，用戶端的進程對使用者而言，往往是一個棧態的，手機裡面使用完一個應用，退出之後可能過不了多久就會被回收掉，當使用者下次再開啟的時候，它會再次啟動進程，需要重新完成一次初始化的流程。如果在這個上面做了很多事情的話，會導致程式啟動的速度會很慢，在很多使用者看來，這就是一種不可接受的使用者體驗。

用戶端 APP 與服務端在架構上是有著一定的區別，在選擇對用戶端架構需要謹慎對待，需要有許多權衡的條件，在此前提上，是否有一種歸一的方式呢，可以分而治之，並行開發，把業務分隔成一個個單獨的組件，整個架構圍繞組件開發，構建也是組件，一切皆組件。答案是有的，那就是打造用戶端組件架構。

起源，為何組件化

用戶端 APP 自身在飛速發展，APP 版本不斷迭代，新功能不斷增加，業務模組數量不斷增加，業務上的處理邏輯越變越複雜，同時每個模組代碼也變得越來越多，這就引發一個問題，所維護的代碼成本越來越高，稍微一改動可能就牽一髮而動全身，改個小的功能點就需要迴歸整個 APP 測試，這就對開發和維護帶來很大的挑戰。同時原來APP 架構方式是單一工程模式，業務規模擴大，隨之帶來的是團隊規模擴大，那就涉及到多人協作問題，每個移動端軟體開發人員勢必要熟悉如此之多代碼，如果不按照一定的模組組件機制去劃分，將很難進行多人協作開發，隨著單一項目變大，而且 Andorid 項目在編譯代碼方面就會變得非常卡頓，在單一工程代碼耦合嚴重，每修改一處代碼後都需要重新編譯打包測試，導致非常耗時，最重要的是這樣的代碼想要做單元測試根本無從下手，所以必須要有一個更靈活的架構去代替過去單一工程模式。

同樣這樣的問題在我們工作具體項目中處處碰到，就拿我們組內負責的某個移動端 APP 來說，就碰到如下幾個問題：

1. 代碼量膨脹，不利於維護，不利於新功能的開發。
2. 項目工程構建速度慢，在一些電腦上寫兩句代碼，重新編譯測試的話編譯速度起碼 10-20 分鐘，有的甚至更長。
3. 不同模組之間代碼耦合嚴重，比如訊息模組嚴重耦合視頻模組，如果修改視頻模組，相應的訊息模組也需要修改，不然會產生一連串問題。
4. 每個模組之間都有引用第三方庫，但有些第三方庫版本不一致，導致打包 APP 時候代碼冗餘，容易引起版本衝突。
5. 有些定製項目如果只需要訊息模組，其他模組不需要的話，做不到按需載入打包，因為模組之間有互聯依賴。
6. 現有項目基於以前其他人項目基礎上開發，經手的人次過多，存在著不同的代碼風格，項目中代碼規範亂，類似的功能寫法卻不一樣，導致不統一。

項目工程架構模式改變是大勢所趨，那又該如何做呢？那就是：打造組件化開發架構，用以解決目前所面臨問題，在講解如何打造之前，需要談談組件化概念，組件化架構是什麼。

概念，組件化是什麼

問：什麼是組件，什麼是組件化？

答：在軟體開發領域，組件（Component）是對資料和方法的簡單封裝，功能單一，高內聚，並且是業務能劃分的最小粒度。舉個我們生活中常見的例子就是電腦主板上每個元件電容器件，每個元件負責的功能單一、容易組裝、即插即拔，但作用有限，需要一定的依賴條件才可使用。如：

那麼同樣，組件化 就是基於組件可重用的目的上，將一個大的軟體系統按照分離關注點的形式，拆分成多個獨立的組件，使得整個軟體系統也做到電路板一樣，是單個或多個組件元件組裝起來，哪個組件壞了，整個系統可繼續運行，而不出現崩潰或不正常現象，做到更少的耦合和更高的內聚。

問：組件化、模組化容易混淆，兩者區別又是什嗎？

答：模組化就是將一個程式按照其功能做拆分，分成相互獨立的模組，以便於每個模組只包含與其功能相關的內容，模組我們相對熟悉,比如登入功能可以是一個模組,搜尋功能可以是一個模組等等。而組件化就是更關注可複用性，更注重關注點分離，如果從集合角度來看的話，可以說往往一個模組包含了一個或多個組件，或者說模組是一個容器，由組件組裝而成。簡單來說，組件化相比模組化粒度更小，兩者的本質思想都是一致的，都是把大往小的方向拆分，都是為了複用和解耦，只不過模組化更加側重於業務功能的劃分，偏向於複用，組件化更加側重於單一功能的內聚，偏向於解耦。

問：組件化能帶來什麼好處？

答：簡單來說就是提高工作效率，解放生產力，好處如下：

• 代碼簡潔，冗餘量少，維護方便，易擴充新功能。
• 提高編譯速度，從而提高並行開發效率。
• 避免模組之間的交叉依賴，做到低耦合、高內聚。
• 引用的第三方庫代碼統一管理，避免版本統一，減少引入冗餘庫。
• 定製項目可按需載入，組件之間可以靈活組建，快速產生不同類型的定製產品。
• 制定相應的組件開發規範，可促成代碼風格規範，寫法統一。
• 系統級的控制力度細化到組件級的控制力度，複雜系統構建變成組件構建。
• 每個組件有自己獨立的版本，可以獨立編譯、測試、打包和部署。

設計，構建組件化架構

回到剛開始講的 APP 單一工程模式，看張常見 APP 單一工程模式架構圖：

是目前比較普遍使用的 Android APP 技術架構，往往是在一個介面中存在大量的商務邏輯，而商務邏輯中充斥著各種網路請求、資料操作等行為，整個項目中也沒有模組的概念，只有簡單的以商務邏輯劃分的檔案夾，並且業務之間也是直接相互調用、高度耦合在一起的。單一工程模型下的業務關係，總的來說就是：你中有我，我中有你，相互依賴，無法分離。如：

組件化的指導思想是：分而治之，並行開發，一切皆組件。要實現組件化，無論採用什麼樣的技術方式，需要考慮以下七個方面問題：

1. 代碼解耦。如何將一個龐大的工程分成有機的整體？

2. 組件單獨運行。因為每個組件都是高度內聚的，是一個完整的整體，如何讓其單獨運行和調試？

3. 組件間通訊。由於每個組件具體實現細節都互相不瞭解，但每個組件都需要給其他調用方提供服務，那麼主專案與組件、組件與組件之間如何通訊就變成關鍵？
4. UI 跳轉。UI 跳轉指的是特殊的資料傳遞，跟組件間通訊區別有什麼不同？
5. 組件生命週期。這裡的生命週期指的是組件在應用中存在的時間，組件是否可以做到按需、動態使用、因此就會涉及到組件載入、卸載等管理問題。
6. 整合調試。在開發階段如何做到按需編譯組件？一次調試中可能有一兩個組件參與整合，這樣編譯時間就會大大降低，提高開發效率。

7. 代碼隔離。組件之間的互動如果還是直接引用的話，那麼組件之間根本沒有做到解耦，如何從根本上避免組件之間的直接引用，也就是如何從根本上杜絕耦合的產生？

組件化架構目標：告別結構臃腫，讓各個業務變得相對獨立，業務組件在組件模式下可以獨立開發，而在整合模式下又可以變為 AAR 包整合到“ APP 殼工程”中，組成一個完整功能的 APP。

先給出架構設計圖，然後再對這七個問題進行一一解答。

可以看到，業務組件之間是獨立的，互相沒有關聯，這些業務組件在整合模式下是一個個 Library，被 APP 殼工程所依賴，組成一個具有完整業務功能的 APP 應用，但是在組件開發模式下，業務組件又變成了一個個 Application，它們可以獨立開發和調試，由於在組件開發模式下，業務組件們的代碼量相比於完整的項目差了很遠，因此在運行時可以顯著減少編譯時間。

各個業務組件通訊是通過路由轉寄，

這是組件化工程模型下的業務關係，業務之間將不再直接引用和依賴，而是通過“路由”這樣一個中轉站間接產生聯絡。

那麼針對以上提出的七個問題，具體解決如下：

1，代碼解耦問題

對已存在的項目進行模組拆分，模組分為兩種類型，一種是功能組件模組，封裝一些公用的方法服務等，作為依賴庫對外提供，一種是業務組件模組，專門處理商務邏輯等功能，這些業務組件模組最終負責組裝APP。

2，組件單獨運行問題

通過 Gradle 指令碼配置方式，進行不同環境切換。比如只需要把 Apply plugin: ‘com.android.library‘ 切換成Apply plugin: ‘com.android.application‘ 就可以，同時還需要在 AndroidManifest 資訊清單檔上進行設定，因為一個單獨調試需要有一個入口的 Activity。比如設定一個變數 isModule，標記當前是否需要單獨調試，根據isModule 的取值，使用不同的 gradle 外掛程式和 AndroidManifest 資訊清單檔，甚至可以添加 Application 等 Java 檔案，以便可以做一下初始化的操作。

3，組件間通訊問題

通過介面+實現的結構進行組件間的通訊。每個組件聲明自己提供的服務 Service API，這些 Service 都是一些介面，組件負責將這些 Service 實現並註冊到一個統一的路由 Router 中去，如果要使用某個組件的功能，只需要向Router 請求這個 Service 的實現，具體的實現細節我們全然不關心，只要能返回我們需要的結果就可以了。在組件化架構設計圖中 Common 組件就包含了路由服務元件，裡麵包括了每個組件的路由入口和跳轉。

4，UI 跳轉問題

可以說 UI 跳轉也是組件間通訊的一種，但是屬於比較特殊的資料傳遞。不過一般 UI 跳轉基本都會單獨處理，一般通過短鏈的方式來跳轉到具體的 Activity。每個組件可以註冊自己所能處理的短鏈的 Scheme 和 Host，並定義傳輸資料的格式，然後註冊到統一的 UIRouter 中，UIRouter 通過 Scheme 和 Host 的匹配關係負責分發路由。但目前比較主流的做法是通過在每個 Activity 上添加註解，然後通過 APT 形成具體的邏輯代碼。目前方式是引用阿里的 ARouter 架構，通過註解方式進行頁面跳轉。

5，組件生命週期問題

在架構圖中的核心管理組件會定義一個組件生命週期介面，通過在每個組件設定一個設定檔,這個設定檔是通過使用註解方式在編譯時間自動產生，設定檔中指明具體實現組件生命週期介面的實作類別，來完成組件一些需要初始化操作並且做到自動註冊，暫時沒有提供手動註冊的方式。

6，整合調試問題

每個組件單獨調試通過並不意味著整合在一起沒有問題，因此在開發後期我們需要把幾個組件機整合到一個 APP 裡面去驗證。由於經過前面幾個步驟保證了組件之間的隔離，所以可以任意選擇幾個組件參與整合，這種按需索取的載入機制可以保證在整合調試中有很大的靈活性，並且可以加大的加快編譯速度。需要注意的一點是，每個組件開發完成之後，需要把 isModule 設定為 true並同步，這樣主專案就可以通過參數配置統一進行編譯。

7，代碼隔離問題

如果還是 compile project(xxx:xxx.aar) 來引入組件，我們就完全可以直接使用到其中的實作類別，那麼主專案和組件之間的耦合就沒有消除，那之前針對介面編程就變得毫無意義。我們希望只在 assembleDebug 或者 assembleRelease 的時候把 AAR 引入進來，而在開發階段，所有組件都是看不到的，這樣就從根本上杜絕了引用實作類別的問題。

目前做法是主專案只依賴 Common 的依賴庫，業務組件通過路由服務依賴庫按需進行尋找，用反射方式進行組件載入，然後在主工程中調用元件服務，組件與組件之間調用則是通過介面+實現進行通訊，後續規劃通過自訂Gradle 外掛程式，通過位元組碼自動插入組件的依賴進行編譯打包，實現自動篩選 assembleDebug 或 assembleRelease 這兩個編譯命任務，只有屬於包含這兩個任務的命令才引入具體實作類別，其他的則不引入。

代碼，具體項目實踐

一，建立工程

1，APP空殼工程

通過AndroidStudio建立一個APP空殼工程，

然後在 APP 工程添加依賴具體業務組件 Module。比如：

2，具體業務組件Module

需要遵循一定組件命名規範，為何需要規範呢，因為需要通過組件命名規範來約束和保證組件的統一性和一致性，避免出現衝突。比如登陸組件，那麼名稱：b(類型)-ga(部門縮寫)-login(組件名稱)，這就是我們基於共同的約定進行命名的，為後期維護和擴充都帶來辨識度。

二，業務組件設定檔

1，build.gradle配置文修改。如下：

if (isModule.toBoolean()) {    apply plugin: 'com.android.application'} else {    apply plugin: 'com.android.library'}android {    compileSdkVersion rootProject.ext.compileSdkVersion    buildToolsVersion rootProject.ext.buildToolsVersion    defaultConfig {        minSdkVersion rootProject.ext.minSdkVersion        targetSdkVersion rootProject.ext.targetSdkVersion        if (isModule.toBoolean()) {            applicationId "com.hik.ga.business.login"            versionCode 1            versionName "1.0"        } else {            //ARouter            javaCompileOptions {                annotationProcessorOptions {                    arguments = [ moduleName : project.getName() ]                }            }        }    }    sourceSets {        main {            if (isModule.toBoolean()) {                manifest.srcFile 'src/main/module/AndroidManifest.xml'            } else {                manifest.srcFile 'src/main/AndroidManifest.xml'                //整合開發模式下排除debug檔案夾中的所有Java檔案                java {                    exclude 'debug/**'                }            }        }    }    buildTypes {        release {            minifyEnabled false            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'        }    }}dependencies {    implementation project(':b-ga-common-function-comlib')    if (!isModule.toBoolean()) {        annotationProcessor "com.alibaba:arouter-compiler:${rootProject.annotationProcessor}"    }}

這裡需要有幾點說明一下：

1，通過 isModule.toBoolean() 方法來進行組件間整合模式和組件模式的切換，包括模組是屬於Application 還是 Library，由於整合了 ARouter，所以需要對 ARouter 設定檔進行處理。

2，如果組件模式下， 則需要重新設定 AndroidManifest.xml 檔案，裡面配置新的Application路徑。比如Login組件單獨運行 AndroidManifest 資訊清單檔

<manifest xmlns:android="http://schemas.android.com/apk/res/android"    package="hik.ga.business.applogin" >    <application        android:name="debug.LoginApplication"        android:allowBackup="false"        android:icon="@mipmap/ic_launcher"        android:label="@string/login_btn_str"        android:supportsRtl="true"        android:theme="@style/Theme.AppCompat.Light.NoActionBar">        <activity            android:name="hik.ga.business.applogin.login.views.LoginActivity"            android:label="@string/login_btn_str"            android:launchMode="singleTop"            android:screenOrientation="portrait"            android:theme="@style/AppTheme.NoActionBarFullScreen">            <intent-filter>                <action android:name="android.intent.action.MAIN" />                <category android:name="android.intent.category.LAUNCHER" />            </intent-filter>        </activity>    </application></manifest>

3，實現組件全域應用配置類，這個類的目的是在組件載入時初始化一些組件自身的資源，如下：

public class LoginApplicationDelegate implements IApplicationDelegate {    private static final String TAG = "LoginApplicationDelegate";    @Override    public void onCreate() {        EFLog.d(TAG, "*------------------onCreate()---------------->");    }    @Override    public void enterBackground() {        EFLog.d(TAG, "*------------------enterBackground()---------------->");    }    @Override    public void enterForeground() {        EFLog.d(TAG, "*------------------enterForeground()---------------->");    }    @Override    public void receiveRemoteNotification(Map<String, String> message) {        EFLog.d(TAG, "receiveRemoteNotification msg = " + message);    }    @Override    public void onTerminate() {        EFLog.d(TAG, "*------------------onTerminate()---------------->");    }    @Override    public void onConfigurationChanged(Configuration configuration) {        EFLog.d(TAG, "*------------------onConfigurationChanged()---------------->");    }    @Override    public void onLowMemory() {        EFLog.d(TAG, "*------------------onLowMemory()---------------->");    }    @Override    public void onTrimMemory(int var1) {        EFLog.d(TAG, "*------------------onTrimMemory()---------------->");    }}

三，路由服務

1，定義公用組件路由API和入口，通過路由服務元件尋找，

2，組件路由實現

每個組件對外提供什麼能力，首先需要在路由服務元件建立一個介面檔案，如下是登陸組件介面聲明和實現。

Login 介面：

具體實現：

路由使用：比如我們想從設定頁面跳轉到登陸頁面，使用 Login 介面裡的方法，使用如下：

ILoginProvider loginService = (ILoginProvider) ARouter.getInstance().build(RouterPath.ROUTER_PATH_TO_LOGIN_SERVICE).navigation();if(loginService != null){    loginService.accountToLogin(AccountActivity.this);}

小結

總的來說，通過應用組件化架構，使得我們工作中的具體項目變得更輕、好組裝、編譯構建更快，不僅提高工作效率，同時自我對行動裝置 App開發認知有進一步的提升。因為組件化架構具有通用性，特別適用於業務模組迭代多，量大的大中型項目，是一個很好的解決方案。至於組件化架構之後演化的道路，則是打造組件倉庫，完善組件開發規範，豐富組件功能庫，有一些粒度大的業務組件可以進一步的細化，對組件功能進行更單一的內聚，同時基於現有組件化架構，便於過度在未來打造外掛程式化架構，進一步升級 APP 動態能力，比如熱載入、熱修複等，那又是另一種使用情境和設計架構了，其實組件化和外掛程式化架構最大的區別就是在是否具備動態更新能力。

把項目簡化下，github地址：DemoComponent，感興趣的可以下過去看看。

參考文章：

1，Android組件化方案

2，Android徹底組件化方案實踐

Android組件化架構設計與實踐