Android元件化和插件化開發

項目發展到一定程度，就必須進行子產品的拆分。子產品化是一種指導理念，其核心思想就是分而治之、降低耦合。而在 Android 工程實踐，目前有兩種途徑，一個是元件化，一個是插件化。

元件化開發

說起元件化少不了提起AS子產品化的概念，其實兩種方式的本質思想是一樣的，都是為了代碼重用和業務解耦。

子產品化

子產品(Module)，Android Studio提出的概念，它是根據不同關注點将原項目中共享的部分或業務抽取出來形成獨立module，這就類似我們內建的第三方庫的SDK。 Module包含兩種格式: application， library。application格式的module就可以打包成一個apk，一個library可以形成一個aar包（類似java中的jar包）。在我們實際開發中，通常會抽取第三方庫、使用封裝的網絡庫、圖檔庫、視訊庫、Utils工具類、自定義View 等到一個共有的common子產品中，其他子產品在配置Gradle依賴後，就能夠調用這些API。它 相比于包來講，子產品更靈活，耦合更低，随意插拔，想引入哪個就引入哪個。根據不同的關注點，将一個項目的可以共享的部分抽取出來，形成獨立的Module，就是子產品化。

元件化

元件化是基于子產品化的，元件化是建立在子產品化思想上的一次演進，一個變種。元件化本來就是子產品化的概念，但是元件化的核心是：子產品角色的可轉換性，可以在打包時是設定為library，開始調試運作是設定成application。

通俗的講元件化就是基于可重用的目的，将一個大的軟體系統按照分離關注點的形式，拆分成多個獨立的元件。 元件的出現是為了解決全局工程中有很多重複代碼的問題，是為了複用，而且劃分力度是相對較小的子產品。元件化的另一個目的是為了解耦，把系統拆分成多個元件，分離元件邊界和責任，便于獨立更新和維護。

元件化開發的結構

圖中從上向下分别為應用層、元件層，功能基礎層

1. 基礎層： 基礎層包含的是一些基礎庫以及對基礎庫的封裝，比如常用的圖檔加載，網絡請求，資料存儲操作等等，它往往是一些功能性的，其他子產品或者元件都可以引用同一套基礎庫，這樣不但隻需要開發一套代碼，還解耦了基礎功能和業務功能的耦合，在基礎庫變更時更加容易操作。
2. 元件層： 基礎層往上是元件層，元件層就包含就是根據我們應用劃分的業務元件，例如登入子產品，消息子產品等。
3. 應用層： 工程根據需要加入自己的業務元件。

元件化開發帶來的優點：

• 業務子產品分開，解耦的同時也降低了項目的複雜度，結構非常清晰。
• 開發調試時不需要對整個項目進行編譯，每個子產品可獨立編譯，提高了編譯速度。
• 多人合作時可以隻關注自己的業務子產品，把某一業務當成單一項目來開發，可以提升開發，測試效率。
• 可以靈活的對業務子產品進行組裝和拆分。
• 避免重複造輪子，節省開發維護成本；

多個團隊公用同一個元件，在一定層度上確定了技術方案的統一性。

總結：其實元件化更多的是适合于項目大 但是功能相對集中的一些項目。比如 一個金融類的App 裡面隻包含金融的功能，金融功能又會有 借貸，理财，線下交易，把這些子產品抽成單獨的元件。

插件化開發

插件化是将一個apk根據業務功能拆分成不同的子apk（也就是不同的插件），每個子apk可以獨立編譯打包，最終釋出上線的是內建後的apk。在apk使用時，每個插件是動态加載的，插件也可以進行熱修複和熱更新。它也是屬于子產品化的一種展現。不過它的機關是apk，一個完整的項目。靈活性在于加載apk，按需下載下傳，動态更新。

如果一個應用所有的功能是非常多的，比如滴滴、美團、支付寶，他們除了一些基礎的業務功能，還有其他的業務功能，如果都打成一個apk，檔案将非常大，用插件化的方式開發後，apk隻包含基礎的業務功能，使用過程中使用者可以按需加載自己需要的功能子產品。

插件化的開發并沒有一個官方的插件化方案，它是國内提出的一種技術實作，利用虛拟機的類的加載機制實作的一種技術手段，往往需要hook一些系統api，而Google從Android9.0開始限制對系統私有api的使用，也就造成了插件化的相容性問題，現在幾個流行的插件化技術架構，都是大廠根據自己的需求，開源出來的，如滴滴的VirtualAPK，360的RePlugin等。

總結：插件化開發适合于項目超級大 但是功能相對不集中比如 一個支付寶App 裡面即包含共享單車 也包含 電影票。這種與本業務完全不同的 可以做成插件的形式。

插件化群組件化的差別

技術	機關	實作内容	靈活性	特性	靜動态
元件化	元件（module）	解耦與加快編譯， 隔離不需要關注的部分	按加載時機切換，是作為lib，還是apk；元件化能做的隻是， 朋友圈已經有了，我想單獨調試，維護，和别人不耦合。但是和整個項目還是有關聯的。	組：每個元件，可以獨立編譯，開發；但本質上他不是完全獨立的，例如一個登入子產品，它是和整個項目有關聯的，是項目的組成部分	編譯期可以動态的添加和修改，運作時不具備
插件化	apk(一個完整的應用)	解耦與加快編譯，同時實作熱插拔也就是熱更新	加載的是apk，可以動态下載下傳，動态更新，比元件化更靈活；插件化是朋友圈就是一個app, 我需要整合了，把它整合進微信這個大的app裡面	插：是獨立的apk，每個插件可以作為一個完全獨立的apk運作，也可以和其他插件內建為大apk。	編譯期和運作時都可以動态的添加和修改，是以它比元件化更靈活

插件化群組件化的選擇

理想的代碼組織形式應該是插件化的方式，屆時就具備了完備的運作時動态化，更靈活，各個插件的開發獨立自主性更強。

但是目前還沒有一個完美相容的插件化方案。

選擇插件化需要考慮兩個方面：

• 相容性。一是插件化不可避免的去 hook 一些系統的 api，也就不可避免地有相容性的問題，是以每個插件化方案需要有專門的團隊去負責維護；
• 開發節奏。二是從一個業務邏輯複雜的項目中去拆分插件化需要的時間可能是非常巨大的，同時把原有的項目內建到一個平台上，需要使用插件化的相關技術去修改，對Android四大元件的相容性，對原來實作方式的适配都是一個挑戰。
• 支援性。應用市場的支援：目前Google Play是不允許插件化的這種動态加載，增量更新方式的app上架的，因為這樣會繞過稽核，保不齊一些不良 App “挂羊頭賣狗肉”，等使用者下載下傳、安裝 App 之後，熱更新出其他不良功能。目前國内市場還沒明文規定。技術上的支援：一定程度上說，谷歌是不鼓勵這種開發方式的，對私有api的限制以後會越來越嚴格，現有市場上的架構都是三年之前的。

大多數情況下，元件化都是一個不錯甚至最佳的選擇，它沒有相容性，可以更友善地拆分，并且幾乎沒有技術障礙，可以更順利地去執行。特别是對急需拆分的産品來說，元件化是一個可退可守的方案，可以更快地執行下去，并且将來要是遷移到插件化，元件化拆分也是必經的一步。

最後

關于元件化方面的具體知識，推薦大家去看玉剛說和楊充兩位大佬的兩篇文章，個人感覺講的很全面，也容易了解：

Android 元件化最佳實踐

Android元件化開發實踐和案例分享

本文在開源項目：https://github.com/Android-Alvin/Android-LearningNotes 中已收錄，裡面包含不同方向的自學程式設計路線、面試題集合/面經、及系列技術文章等，資源持續更新中…

作者：行者點com

連結：https://juejin.cn/post/6953600472045486111