模塊化，組件化傻傻分不清？

每日英文

Sometimes, we"re so busy wishing for what we want that we forget all that we already have.

有時候，人太關注於想要得到的東西，卻忘記了自己所擁有的一切。

樂樂有話說

無論你活成什麼樣子，背地裡都會有人對你說三道四。一笑了之，給自己一個燦爛的陽光，一片自由的海洋，讓自己不斷變強，其實就是最好的蔑視。

來自：亓春傑

鏈接：https://www.jianshu.com/p/f5212cf7df55

從本篇開始，打算從廣義上探究一下移動架構的思想；包括現在仍然比較火熱的模塊化，組件化， 插件化等架構思想。話說在前面，本篇旨在說明當前主流架構的設計概念，讓大家了解當前的架構形式，以及主要用了什麼設計思想，什麼設計思路，算是引導篇…

模塊化，組件化，插件化

上述概念已經好久了，或許還是有一些同胞對這些概念不是很清楚，大體知道是什麼，但是詳細也不知道是什麼。現在來解析一下。

單工程模式

移動開發誕生，我們開發移動項目，我相信大多用的是單工程單任務的開發模式，二話不說，直接就開始寫起，是不是這樣呢？ new Project -> 分包 -> 寫起。我相信都經歷過，也寫的比較爽，為什麼呢？ 這種模式不涉及亂七八糟的處理方式， 上手快，開發快，足夠敏捷。那麼原因是什麼呢？Mobile Project 剛起步，項目都偏小，一些附加業務還沒綁到App上。

模塊化

Android Studio出來了，多出來了一個新的概念， Project, Module… 模塊；當時以包的形式分離的公共包common,現在成了AS中的Module。大家都知道，Module包含兩種格式: application， library。也就是說，一個Module就是一個小的項目，也是AS概念中的模塊。因此我們開始設計common模塊， common_business模塊，甚至db模塊。模塊的好處是什麼？ 相比於包來講，模塊更靈活，耦合更低，隨意插拔，想引入哪個就引入哪個。根據不同的關注點，將一個項目的可以共享的部分抽取出來，形成獨立的Module，就是模塊化。模塊化不只包含公共部分，當然也可以是業務模塊。

組件化

平時看看論壇，好多人都在問：模塊化和組件化有什麼區別？到底有什麼區別呢，其實很小；但並不是完全相同的概念。通過以上模塊化的概念講述，應該對模塊化有了一個了解，那麼區別是什麼呢？

組件化是建立在模塊化思想上的一次演進，一個變種。組件化本來就是模塊化的概念。但是組件化的核心是

什麼？ 是模塊角色的可轉換性。是的，就是可轉換性。

組件化的核心是角色的轉換。 在打包時， 是library; 在調試時， 是application。

怎麼理解組件化的概念 ？

Module的模式分兩種， application和library。 library就是引用庫，如你抽取的common。 application就是一個apk， 是一個完整的項目。

在調試時，我只關心我負責的模塊，我希望我的模塊是一個單獨的app,因為這樣更小，業務更專一，相對來講修改與調試就會越省時省心，編譯就會越快。試想當你需要改一段代碼，既要關注自己的，也要關注別人的，是一種什麼體驗 ？ 或者， 編譯一個項目10M的代碼和一個工程全部1G的代碼，哪個比較舒服一些？

插件化

又有人問了： 插件化和組件化又有什麼區別呢？插件化嚴格意義來講，其實也算是模塊化的觀念。將一個完整的工程，按業務劃分為不同的插件，都是分治法的一種體現。化整為零，相互配合。，越小的模塊越容易維護。插件化按理也算是模塊化的一種體現，和組件化就不一個概念了。那麼，到底有什麼區別呢？

組件化的單位是組件（module）。

插件化的單位是apk(一個完整的應用)。

組件化實現的是解耦與加快編譯， 隔離不需要關注的部分。

插件化實現的也是解耦與加快編譯，同時實現熱插拔也就是熱更新。

組件化的靈活性在於按載入時機切換，分離出獨立的業務組件，比如微信的朋友圈

插件化的靈活性在於是載入apk, 完全可以動態下載，動態更新，比組件化更靈活。

組件化能做的只是， 朋友圈已經有了，我想單獨調試，維護，和別人不耦合。但是和整個項目還是有關聯的。

插件化可以說朋友圈就是一個app, 我需要整合了，把它整合進微信這個大的app裡面

其實從框架名稱就可以看出： 組 和 插。

組本來就是一個系統，你把微信分為朋友圈，聊天， 通訊錄按意義上劃為獨立模塊，但並不是真正意義上的獨立模塊。

插本來就是不同的apk， 你把微信的朋友圈，聊天，通訊錄單獨做一個完全獨立的app, 需要微信的時候插在一起，就是一個大型的app了。

插件化的載入是動態的，這點很重要，也是靈活的根源。

以上是對三個思想的解析，相信應該能明白不同的概念的具體意義和區別在哪了。在《關於移動架構的思考與總結》中我指出，所謂架構，無非兩個方面： 分層和通信方式。 其實廣義的架構也可以說是這兩個方面：子模塊（子系統）劃分和通信。

子模塊劃分

除了大家公認的common部分， 業務模塊的劃分尤為重要，相比於狹義上的架構，廣義上的子系統的劃分的關注點，很考驗技術經驗以及對業務的理解。

通信方式

模塊化的通信方式，無非是相互引入；我抽取了common, 其他模塊使用自然要引入這個module

組件化的通信方式，按理說可以劃分為多種，主流的是隱式和路由。隱式的存在使解耦與靈活大大降低，因此路由是主流

插件化的通信方式，不同插件本身就是不同的進程了。因此通信方式偏向於Binder機制類似的進程間通信

廢話說了這麼多，其實本篇作為組件化的引導篇，本意是要探究一下組件化的思路的，嗯，本篇只講思路；其實思路清晰了，結合一定的技術儲備，完全可以自己來實現。好了，開始切入主題…

組件化的技術準備

反射與apt

gradle與groovy

路由機制

情報篇

做一件事，首先要明白我們要做什麼， 然後劃分步驟，哪一步怎麼做，最後逐個解決。這也是分治法的一種思維方式，它當然不只是一種演算法的解決思想。只有這樣，我們才會建立信息，不會一下子被嚇傻從而放棄。

組件化的思想是Module模式的切換。 上面已經說過,在打包時，業務module為library; 調試時，業務module成了application。

1.如何切換module的模式呢 ？

我相信都能想到，定義一個Boolean變數作為開關。根據開關分別設置module的模式，如下

2.兩種模式的區別是什麼？

applicationId (包的配置)

只存在於apply plugin: "com.android.application"模式下

Manifest.xml（主頁面的配置）

集成模式下，使用app模塊下的Manifest.xml配置； 組件模式下，使用組件自己的Manifest.xml配置

Application

不同的組件肯定有自己的初始化的資源或框架，因此自定義的Application也是必要的。但是集成模式下，會造成重複的Application

3. 面臨的問題

問題1：多業務模塊下的統一配置

問題2：Application分發

問題3：資源的衝突

注意：不同的業務模塊禁止彼此依賴

解決方案1：

不同的模塊（20個業務模塊）的配置，必須做到統一配置。在Java代碼實現統一配置，SO Easy ~ 但是在gradle中呢 ？ 那就是定義一個配置文件，統一存放需要配置的項。如下

在Project下創建一個config.gradle(什麼？創建不了？那就把Project自帶的build.gradle複製一份rename & clear)。 ext是groovy提供的擴展參數，不可修改的。 以下可以隨意定義自己的配置，如代碼。這裡說下兩個概念：

佔位符 $ 佔據一個位置，然後用｛｝裡面的變數補充，達到一致配置的目的

android = [

compileSdkVersion: 26

]

以上相當於定義了一個Map, 存放鍵值對，以Key: Value的形式，以，分隔。這是groovy的寫法。android 為Map的名稱，你可以用你自己的命名，但是注意不要和系統變數衝突

以上是統一變數的定義，配置文件config.gradle。 配置文件定義好了，那麼如何引入呢？

在[Project]下的build.gradle引入配置文件

image.png

2.在Module中引用是通過rootProject.ext.你定義的名稱。但是每次這麼用比較繁瑣，推薦定義變數實現，如下

解決方案2：

application的分發，錯誤的做法是不同的組件下初始化自己的框架，工具等。正確的做法是在BaseApplication或統一實現公共模塊如網路， 緩存， 資料庫等的初始化，在各Module實現自己需要的初始化，來避免重複的初始化與衝突。

解決方案3：

資源的衝突解決辦法有兩個：

1） 公共資源建議由公共模塊管理

2） 模塊私有資源，添加前綴限制 （只能解決xml衝突）

3）資源謹慎命名

資源命名只能在開發中加以注意， 通過以上共有資源和前綴極大可能的保證資源不會衝突，且不會重複浪費。至於萬一的衝突，只能交給開發規範了。

解決方案4：

這個是新加的，也就是前面說的，怎麼控制application和library的轉換，全部配置如下：

以上配置在相應Module中的build.gradle的android下

本來打算出這篇為Router原理思想的，結果為了引導從模塊化的概念直到組件化的核心概念以及初步實現。因為真的不少人可能對這些概念了解不是很清楚，包括以前的我，比如模塊化和組件化。從整篇來看，組件化無非就是實現了一次轉換，解決的一些轉換過程中涉及的問題。沒那麼難， 也存在一些坑，只有在開發過程中隨著遇到進一步填平。組件化的配置核心就是library和application的toggle。 真正實現的功能核心卻是通信部分的路由實現部分，下一篇講一下，如何手寫Rooter通信框架。

如果您覺得不錯，請別忘了轉發、分享、點贊讓更多的人去學習， 您的舉手之勞，就是對小樂最好的支持，非常感謝！

著作權歸作者所有，歡迎大家投稿。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！