在2019的9月份，我參與了公司內部將多個app整合成為一個app的項目改造，并負責整個的實施過程。期間碰到一些問題，偶爾有些心得，特記錄如下。

直接來看，這 N個項目的共同點在于都有統一的登錄流程，之后有各自差異化的初始化流程和對應的feature。另外底層的infrastructure也有共有的部分，如EventBus，網絡層組件，下載組件等。最初的設想是將所有現存的app都變?yōu)閙odule，然而初期評估下來，核心app部分的改動可能過大，于是圍繞它，準備將其它（N-1）個app集成進去。總體上的步驟可分為以下幾點：

先統一登錄模塊，初始化邏輯獨立遷移

底層通用業(yè)務模塊中獨立定義 IAuthenticationService接口，然后在其它模塊中實現。使用SPI (Service Provider Interface)的機制來查找實現，并添加到公共的服務管理類 ServiceManager 中。這一步在Android上可以使用 AutoService 來實現。

建立底層基礎模塊 (BaseComponent)

• Deeplink
  對于模塊間的deeplink跳轉邏輯, 暫時統一定義在此處（后續(xù)看來更好的辦法，或可以嘗試引入ARoute）。

• App內部語言切換
  按IAuthenticationService相似的實現策略，可以對ILanguageService 也做出相似的實現，以便全局管理app中的語言切換。

interfaces.jpg

抽取/復用通用的 infrastructure libraries

包括 Downloader，NetworkMonitor，StorageMonitor，出于性能因素，復用 4.x 版本以后的 OkHttpClient 等等。

模塊化后，編譯配置的變更

• 為了防止資源重復，將library中的資源增加前綴(prefix)以防止命名沖突

android {
    resourcePrefix 'lib_a_'
    // ...
}

• 當編譯時出現依賴的dependency重復相關的錯誤時 ? ，可以使用compileOnly (...), 或

implementation(a_lib) {
    exclude module: 'duplicate_module'
}

或是自定義多版本沖突后的解決策略：

configurations.all {
    resolutionStrategy {
        forcedModules = [
                "com.google.code.gson:gson:$gsonVersion",
                // ...
        ]
    }
}   

各個module中 proguard 的聲明變化

apply plugin: 'com.android.library'
android {
    defaultConfig {
        consumerProguardFiles 'your-proguard file'
    }
}

【可選】支持單獨的module作為獨立可運行的app

在module的build.gradle中更改配置

if (isStandalone()) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

以上區(qū)分了App 或 library 的配置，還要應用于dependencies, defaultConfig, ProguardFiles 等。

改造后的模塊結構圖

comp.png

利用WMRouter 解耦Service的定義與實現

按上圖將各個通用的Service 接口定義在BaseComponent中，而實現可以放在上層的Component 或獨立的模塊。在其它模塊中可以經由ServiceManager 通過統一的 Router.getService(XService.class) 調用方式，查找并使用對應的服務。

TODO

• 新增功能可配置化

P.S. 組件圖是由在線繪圖工具 diagrams 繪制。

?? 贊賞支持

請支持我進行更好地創(chuàng)作 ??