[Android] 組件化 & 模塊化 & 插件化演進

時間 2019-11-09

標籤 android 組件模塊化插件演進欄目 Android 简体版

原文原文鏈接

你們好，我係蒼王。
java

如下是我這個系列的相關文章，有興趣能夠參考一下，能夠給個喜歡或者關注個人文章。git

[Android]如何作一個崩潰率少於千分之三噶應用app--章節列表網絡

寫了二十多篇的簡書，到這裏已經寫了不少關於不少組件化內容的文章，可是不少對組件化，模塊化，插件化的概念仍是不理解。架構

不少同窗，都以爲如何劃分模塊，如何劃分組件，如何作隔離解耦，如何作分層產生了疑慮，有些時候無從下手。app

這裏仍是須要給你們普及一下概念性的說明吧。框架

一.組件化

關於組件化，看過我第一編開篇文章的，會看到這個圖。socket

這個圖實際上是咱們組件化入門所接觸到的圖，這樣簡單的分明的分層。模塊化

基礎組件化圖

（1）base module集成基礎用到的組件svn

（2）一個組件意爲着一個業務組件化

（3）App module是統籌每一個的集成層。

這是最基礎最簡陋的組件化工程，比較適合中小型開發項目架構。其基礎的接口，例如存儲io，圖片等，須要輕量級封裝，只須要使用一個類封裝就能夠了。而業務獨立簡單，只須要一個base module便可以完成基礎依賴。

二.模塊化

架構都是從基礎演化的，隨着業務量的增長，就會發現層級有點不夠用了，業務須要更加細分，而後就進化到模塊化的模型。

這是我理解的模塊化。

這裏很清晰能夠看到我將模塊化分爲5層模型。

模塊化模型圖

（1）應用層是生成app和初始化操做的加載

（2）模塊層，每一個模塊至關於一個業務，經過module來分隔開每一個業務的邏輯。

（3）基礎層，基礎組件的整合，提供基礎組件能力給業務層使用。

（4）組件層，經過圖片加載，網絡http,socket等基礎功能劃分爲一層。

（5）基礎庫層，更加基礎的庫類依賴，此層非必須，例如（Rxjava，EventBus等一些代碼結構優化的庫），還有本身編寫的封裝類。

這裏業務層，調試以前gradle組件化優化和組件化數據分享都有給你們介紹。

基礎庫層，這個層是能夠轉移到基礎層和組件層混合的中，這樣能夠減小層級，因此爲虛線。

這個結構適合中型app的搭建，當你在第一種組件化架構有相對的沉澱，發現業務須要從新細分重構的時候，能夠考慮這種架構方式。其要求組件獨立複用，模塊也能夠獨立複用。而其組件集合和模塊關聯就是依賴於一個Base module來完成。

還有模塊化更進一步架構方式和需求，之後有機會再給你們介紹。

三.插件化

當業務層相對獨立後，分層已經很是穩定。

國內Android App大環境（做爲用戶，用戶都貪新忘舊的，每一星期半個月就從新下載app，誰受得了。）。這種環境下，中國黑科技熱更新就變爲了常態。熱更新催生出插件化開發。·

那麼架構只能再次進化。

依然是沿用上面的5層模型。

插件化模型圖

咱們能夠看到上面的插件化模型。

（1）組件層裏面須要添加插件框架，如Small，Atlas，DroidPlugin等等，至於選型以前有推薦一系列的文章。

（2）開發模塊層，其業務分塊至關於一些大型的業務做爲獨立的插件，例如地圖，直播間，活動，第三方嵌入等。做爲單獨的研發分支（svn，git工程），這樣做爲基礎項目研發，就保有其模塊的獨立性，最大程度解耦。

（3）應用層，對應着宿主App（不知道的，就去補插件基礎去吧），一些很是基礎的業務如登陸，支付等須要帳號等數據最好集成到這裏。固然若是公司對於這些分塊必定有很好的解決能力和條件。宿主App至關於只是一個殼，包裝加載所有的插件App仍是沒問題的。

這樣的架構，適合模塊迭代，有一個小組來完成便可小工程，並且能夠脫離原來大工程的研發。可是這裏須要注意的一點，須要很是當心的設置base module裏面的模塊間通訊。舉個例子，假若用RxBus來通訊，其每次都須要添加一個新的類，那麼每次都須要更改添加到base module，那麼其架構是很是不穩定，更新也是不容許向前兼容，並且模塊多了，功能疊加會形成類爆炸。除非重構，接口的設計向前兼容，那麼舊的接口就不能做過多的修改，不能刪除和更改參數，只能增長。因此這裏請各位架構師必定要思考清楚之後的重構難度。

這裏還給出插件化運行模型。