一、模塊化、組件化與插件化

項目發展到一定程度，隨著人員的增多，代碼越來越臃腫，這時候就必須進行模塊化的拆分。在我看來，模塊化是一種指導理念，其核心思想就是分而治之、降低耦合。而在 Android 工程中如何實施，目前有兩種途徑，也是兩大流派，一個是組件化，一個是插件化。

提起組件化和插件化的區別，有一個很形象的圖：

上面的圖看上去比較清晰，其實容易導致一些誤解，有下面幾個小問題，圖中可能說的不太清楚：

組件化是一個整體嗎?去了頭和胳膊還能存在嗎?左圖中，似乎組件化是一個有機的整體，需要所有器官都健在才可以存在。而實際上組件化的目標之一就是降低整體(app)與器官(組件)的依賴關系，缺少任何一個器官 app 都是可以存在并正常運行的。

頭和胳膊可以單獨存在嗎?左圖也沒有說明白，其實答案應該是肯定的。每個器官(組件)可以在補足一些基本功能之后都是可以獨立存活的。這個是組件化的第二個目標：組件可以單獨運行。

組件化和插件化可以都用右圖來表示嗎?如果上面兩個問題的答案都是 YES 的話，這個問題的答案自然也是 YES。每個組件都可以看成一個單獨的整體，可以按需的和其他組件(包括主項目)整合在一起，從而完成的形成一個 app。

右圖中的小機器人可以動態的添加和修改嗎?如果組件化和插件化都用右圖來表示，那么這個問題的答案就不一樣了。對于組件化來講，這個問題的答案是部分可以，也就是在編譯期可以動態的添加和修改，但是在運行時就沒法這么做了。而對于插件化，這個問題的答案很干脆，那就是完全可以，不論實在編譯期還是運行時!

本文主要集中講的是組件化的實現思路，對于插件化的技術細節不做討論，我們只是從上面的問答中總結出一個結論：組件化和插件化的***區別(應該也是唯一區別)就是組件化在運行時不具備動態添加和修改組件的功能，但是插件化是可以的。

暫且拋棄對插件化“道德”上的批判，我認為對于一個 Android 開發者來講，插件化的確是一個福音，這將使我們具備極大的靈活性。但是苦于目前還沒有一個完全合適、***兼容的插件化方案(RePlugin 的饑餓營銷做的很好，但還沒看到療效)，特別是對于已經有幾十萬代碼量的一個成熟產品來講，套用任何一個插件化方案都是很危險的工作。所以我們決定先從組件化做起，本著做一個最徹底的組件化方案的思路去進行代碼的重構，下面是最近的思考結果，歡迎大家提出建議和意見。

二、如何實現組件化

要實現組件化，不論采用什么樣的技術路徑，需要考慮的問題主要包括下面幾個：

• 代碼解耦。如何將一個龐大的工程拆分成有機的整體?
• 組件單獨運行。上面也講到了，每個組件都是一個完整的整體，如何讓其單獨運行和調試呢?
• 數據傳遞。因為每個組件都會給其他組件提供的服務，那么主項目(Host)與組件、組件與組件之間如何傳遞數據?
• UI 跳轉。UI 跳轉可以認為是一種特殊的數據傳遞，在實現思路上有啥不同?
• 組件的生命周期。我們的目標是可以做到對組件可以按需、動態的使用，因此就會涉及到組件加載、卸載和降維的生命周期。
• 集成調試。在開發階段如何做到按需的編譯組件?一次調試中可能只有一兩個組件參與集成，這樣編譯的時間就會大大降低，提高開發效率。
• 代碼隔離。組件之間的交互如果還是直接引用的話，那么組件之間根本沒有做到解耦，如何從根本上避免組件之間的直接引用呢?也就是如何從根本上杜絕耦合的產生呢?只有做到這一點才是徹底的組件化。

2.1 代碼解耦

把龐大的代碼進行拆分，Androidstudio 能夠提供很好的支持，使用 IDE 中的 multiple module 這個功能，我們很容易把代碼進行初步的拆分。在這里我們對兩種 module 進行區分：

• 一種是基礎庫 library，這些代碼被其他組件直接引用。比如網絡庫 module 可以認為是一個 library。
• 另一種我們稱之為 Component，這種 module 是一個完整的功能模塊。比如讀書或者分享 module 就是一個 Component。

為了方便，我們統一把 library 稱之為依賴庫，而把 Component 稱之為組件，我們所講的組件化也主要是針對 Component 這種類型。而負責拼裝這些組件以形成一個完成 app 的 module，一般我們稱之為主項目、主 module 或者 Host，方便起見我們也統一稱為主項目。

經過簡單的思考，我們可能就可以把代碼拆分成下面的結構：

組件化簡單拆分

這種拆分都是比較容易做到的，從圖上看，讀書、分享等都已經拆分組件，并共同依賴于公共的依賴庫(簡單起見只畫了一個)，然后這些組件都被主項目所引用。讀書、分享等組件之間沒有直接的聯系，我們可以認為已經做到了組件之間的解耦。但是這個圖有幾個問題需要指出：

• 從上面的圖中，我們似乎可以認為組件只有集成到主項目才可以使用，而實際上我們的希望是每個組件是個整體，可以獨立運行和調試，那么如何做到單獨的調試呢?
• 主項目可以直接引用組件嗎?也就是說我們可以直接使用 compile project(:reader) 這種方式來引用組件嗎?如果是這樣的話，那么主項目和組件之間的耦合就沒有消除啊。我們上面講，組件是可以動態管理的，如果我們刪掉 reader(讀書)這個組件，那么主項目就不能編譯了啊，談何動態管理呢?所以主項目對組件的直接引用是不可以的，但是我們的讀書組件最終是要打到 apk 里面，不僅代碼要和并到 claases.dex 里面，資源也要經過 meage 操作合并到 apk 的資源里面，怎么避免這個矛盾呢?
• 組件與組件之間真的沒有相互引用或者交互嗎?讀書組件也會調用分享模塊啊，而這在圖中根本沒有體現出來啊，那么組件與組件之間怎么交互呢?

這些問題我們后面一個個來解決，首先我們先看代碼解耦要做到什么效果，像上面的直接引用并使用其中的類肯定是不行的了。所以我們認為代碼解耦的首要目標就是組件之間的完全隔離，我們不僅不能直接使用其他組件中的類，***能根本不了解其中的實現細節。只有這種程度的解耦才是我們需要的。

2.2 組件的單獨調試

其實單獨調試比較簡單，只需要把 apply plugin: 'com.android.library'切換成 apply plugin: 'com.android.application'就可以，但是我們還需要修改一下 AndroidManifest 文件，因為一個單獨調試需要有一個入口的 actiivity。

我們可以設置一個變量 isRunAlone，標記當前是否需要單獨調試，根據 isRunAlone 的取值，使用不同的 gradle 插件和 AndroidManifest 文件，甚至可以添加 Application 等 Java 文件，以便可以做一下初始化的操作。

為了避免不同組件之間資源名重復，在每個組件的 build.gradle 中增加 resourcePrefix "xxx_"，從而固定每個組件的資源前綴。下面是讀書組件的 build.gradle 的示例：

if(isRunAlone.toBoolean()){     
apply plugin: 'com.android.application' 
}else{   
apply plugin: 'com.android.library' 
} 
..... 
  resourcePrefix "readerbook_" 
  sourceSets { 
      main { 
          if (isRunAlone.toBoolean()) { 
              manifest.srcFile 'src/main/runalone/AndroidManifest.xml' 
              java.srcDirs = ['src/main/java','src/main/runalone/java'] 
              res.srcDirs = ['src/main/res','src/main/runalone/res'] 
          } else { 
              manifest.srcFile 'src/main/AndroidManifest.xml' 
          } 
      } 
  } 

通過這些額外的代碼，我們給組件搭建了一個測試 Host，從而讓組件的代碼運行在其中，所以我們可以再優化一下我們上面的框架圖。

支持單獨調試的組件化

2.3 組件的數據傳輸

上面我們講到，主項目和組件、組件與組件之間不能直接使用類的相互引用來進行數據交互。那么如何做到這個隔離呢?在這里我們采用接口 + 實現的結構。每個組件聲明自己提供的服務 Service，這些 Service 都是一些抽象類或者接口，組件負責將這些 Service 實現并注冊到一個統一的路由 Router 中去。如果要使用某個組件的功能，只需要向 Router 請求這個 Service 的實現，具體的實現細節我們全然不關心，只要能返回我們需要的結果就可以了。這與 Binder 的 C/S 架構很相像。

因為我們組件之間的數據傳遞都是基于接口編程的，接口和實現是完全分離的，所以組件之間就可以做到解耦，我們可以對組件進行替換、刪除等動態管理。這里面有幾個小問題需要明確：

組件怎么暴露自己提供的服務呢?在項目中我們簡單起見，專門建立了一個 componentservice 的依賴庫，里面定義了每個組件向外提供的 service 和一些公共 model。將所有組件的 service 整合在一起，是為了在拆分初期操作更為簡單，后面需要改為自動化的方式來生成。這個依賴庫需要嚴格遵循開閉原則，以避免出現版本兼容等問題。

service 的具體實現是由所屬組件注冊到 Router 中的，那么是在什么時間注冊的呢?這個就涉及到組件的加載等生命周期，我們在后面專門介紹。

一個很容易犯的小錯誤就是通過持久化的方式來傳遞數據，例如 file、sharedpreference 等方式，這個是需要避免的。

下面就是加上數據傳輸功能之后的架構圖：

組件之間的數據傳輸

2.4 組件之間的 UI 跳轉

可以說 UI 的跳轉也是組件提供的一種特殊的服務，可以歸屬到上面的數據傳遞中去。不過一般 UI 的跳轉我們會單獨處理，一般通過短鏈的方式來跳轉到具體的 Activity。每個組件可以注冊自己所能處理的短鏈的 schme 和 host，并定義傳輸數據的格式。然后注冊到統一的 UIRouter 中，UIRouter 通過 schme 和 host 的匹配關系負責分發路由。

UI 跳轉部分的具體實現是通過在每個 Activity 上添加注解，然后通過 apt 形成具體的邏輯代碼。這個也是目前 Android 中 UI 路由的主流實現方式。

2.5 組件的生命周期

由于我們要動態的管理組件，所以給每個組件添加幾個生命周期狀態：加載、卸載和降維。為此我們給每個組件增加一個 ApplicationLike 類，里面定義了 onCreate 和 onStop 兩個生命周期函數。

加載：上面講了，每個組件負責將自己的服務實現注冊到 Router 中，其具體的實現代碼就寫在 onCreate 方法中。那么主項目調用這個 onCreate 方法就稱之為組件的加載，因為一旦 onCreate 方法執行完，組件就把自己的服務注冊到 Router 里面去了，其他組件就可以直接使用這個服務了。

卸載：卸載與加載基本一致，所不同的就是調用 ApplicationLike 的 onStop 方法，在這個方法中每個組件將自己的服務實現從 Router 中取消注冊。不過這種使用場景可能比較少，一般適用于一些只用一次的組件。

降維：降維使用的場景更為少見，比如一個組件出現了問題，我們想把這個組件從本地實現改為一個 wap 頁。降維一般需要后臺配置才生效，可以在 onCreate 對線上配置進行檢查，如果需要降維，則把所有的 UI 跳轉到配置的 wap 頁上面去。

一個小的細節是，主項目負責加載組件，由于主項目和組件之間是隔離的，那么主項目如何調用組件 ApplicationLike 的生命周期方法呢，目前我們采用的是基于編譯期字節碼插入的方式，掃描所有的 ApplicationLike 類(其有一個共同的父類)，然后通過 javassisit 在主項目的 onCreate 中插入調用 ApplicationLike.onCreate 的代碼。

我們再優化一下組件化的架構圖：

組件的生命周期

2.6 集成調試

每個組件單獨調試通過并不意味著集成在一起沒有問題，因此在開發后期我們需要把幾個組件機集成到一個 app 里面去驗證。由于我們上面的機制保證了組件之間的隔離，所以我們可以任意選擇幾個組件參與集成。這種按需索取的加載機制可以保證在集成調試中有很大的靈活性，并且可以加大的加快編譯速度。

我們的做法是這樣的，每個組件開發完成之后，發布一個 relaese 的 aar 到一個公共倉庫，一般是本地的 maven 庫。然后主項目通過參數配置要集成的組件就可以了。所以我們再稍微改動一下組件與主項目之間的連接線，形成的最終組件化架構圖如下：

最終結構圖

2.7 代碼隔離

此時在回顧我們在剛開始拆分組件化是提出的三個問題，應該說都找到了解決方式，但是還有一個隱患沒有解決，那就是我們可以使用 compile project(xxx:reader.aar) 來引入組件嗎?雖然我們在數據傳輸章節使用了接口 + 實現的架構，組件之間必須針對接口編程，但是一旦我們引入了 reader.aar，那我們就完全可以直接使用到其中的實現類啊，這樣我們針對接口編程的規范就成了一紙空文。千里之堤毀于蟻穴，只要有代碼(不論是有意還是無意)是這么做了，我們前面的工作就白費了。

我們希望只在 assembleDebug 或者 assembleRelease 的時候把 aar 引入進來，而在開發階段，所有組件都是看不到的，這樣就從根本上杜絕了引用實現類的問題。我們把這個問題交給 gradle 來解決，我們創建一個 gradle 插件，然后每個組件都 apply 這個插件，插件的配置代碼也比較簡單：

// 根據配置添加各種組件依賴，并且自動化生成組件加載代碼 
if (project.android instanceof AppExtension) { 
       AssembleTask assembleTask = getTaskInfo(project.gradle.startParameter.taskNames) 
       if (assembleTask.isAssemble 
               && (assembleTask.modules.contains("all") || assembleTask.modules.contains(module))) { 
         // 添加組件依賴 
          project.dependencies.add("compile","xxx:reader-release@aar") 
         // 字節碼插入的部分也在這里實現 
       } 
} 
 
private AssembleTask getTaskInfo(List<String> taskNames) { 
   AssembleTask assembleTask = new AssembleTask(); 
   for (String task : taskNames) { 
       if (task.toUpperCase().contains("ASSEMBLE")) { 
           assembleTask.isAssemble = true; 
           String[] strs = task.split(":") 
           assembleTask.modules.add(strs.length > 1 ? strs[strs.length - 2] : "all"); 
       } 
   } 
   return assembleTask 
} 

三、組件化的拆分步驟和動態需求

3.1 拆分原則

組件化的拆分是個龐大的工程，特別是從幾十萬行代碼的大工程拆分出去，所要考慮的事情千頭萬緒。為此我覺得可以分成三步：

從產品需求到開發階段再到運營階段都有清晰邊界的功能開始拆分，比如讀書模塊、直播模塊等，這些開始分批先拆分出去

在拆分中，造成組件依賴主項目的依賴的模塊繼續拆出去，比如賬戶體系等

最終主項目就是一個 Host，包含很小的功能模塊(比如啟動圖)以及組件之間的拼接邏輯

3.2 組件化的動態需求

最開始我們講到，理想的代碼組織形式是插件化的方式，屆時就具備了完備的運行時動態化。在向插件化遷徙的過程中，我們可以通過下面的集中方式來實現編譯速度的提升和動態更新。

在快速編譯上，采用組件級別的增量編譯。在抽離組件之前可以使用代碼級別的增量編譯工具如 freeline(但 databinding 支持較差)、fastdex 等

動態更新方面，暫時不支持新增組件等大的功能改進。可以臨時采用方法級別的熱修復或者功能級別的 Tinker 等工具，Tinker 的接入成本較高。

四、總結

本文是筆者在設計“得到 app”的組件化中總結一些想法，在設計之初參考了目前已有的組件化和插件化方案，站在巨人的肩膀上又加了一點自己的想法，主要是組件化生命周期以及完全的代碼隔離方面。特別是***的代碼隔離，不僅要有規范上的約束(針對接口編程)，更要有機制保證開發者不犯錯，我覺得只有做到這一點才能認為是一個徹底的組件化方案。