在目前移動互聯網時代，每個 APP 就是流量入口，與過去 PC Web 瀏覽器時代不同的是，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 動態能力，比如熱加載、熱修復等，那又是另一種使用場景和設計架構了，其實組件化和插件化框架最大的區別就是在是否具備動態更新能力。

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

參考文章：

1，Android組件化方案

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

Android組件化框架設計與實踐