[Android] 元件化 & 模組化 & 外掛化演進

Cang_Wang發表於2019-03-04

Android元件化

大家好，我係蒼王。

以下是我這個系列的相關文章，有興趣可以參考一下，可以給個喜歡或者關注我的文章。

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

寫了二十多篇的簡書，到這裡已經寫了很多關於很多元件化內容的文章，但是很多對元件化，模組化，外掛化的概念還是不理解。

很多同學，都覺得如何劃分模組，如何劃分元件，如何做隔離解耦，如何做分層產生了疑慮，有些時候無從下手。

這裡還是需要給大家普及一下概念性的說明吧。

一.元件化

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

這個圖其實是我們元件化入門所接觸到的圖，這樣簡單的分明的分層。

基礎元件化圖

（1）base module整合基礎用到的元件

（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，那麼其架構是非常不穩定，更新也是不允許向前相容，而且模組多了，功能疊加會造成類爆炸。除非重構，介面的設計向前相容，那麼舊的介面就不能作過多的修改，不能刪除和更改引數，只能增加。所以這裡請各位架構師一定要思考清楚以後的重構難度。

這裡還給出外掛化執行模型。