Android元件化實踐2——經典元件化項目架構

京東的采用aab( Android App bundles)之後的架構圖

安居客項目架構演化

參考：https://zhuanlan.zhihu.com/p/25420181

安居客在業務上完成了三網合并（新房、二手房、好租和商業地産多個平台的合并），備援代碼充斥項目的各個角落，于是梳理了整個項目的結構。同時開發了自己的UI元件庫UIComponent、基礎工具庫CommonUtils、基于第三方地圖封裝的MapSDK、即時聊天子產品ChatLibrary等等。

安居客有是三個業務團隊：安居客使用者app、經紀人app、集客家app。為了提供更多的、職能單一、性能更優的功能提供給不同團隊使用，采用了元件化的方式，将這些元件分為：基礎元件和業務元件。

最終在采用mvp群組件化之後的安居客app整體設計：

餓了嗎項目項目架構演化

餓了麼移動對于元件有兩種定義：公有元件和業務元件。

對于公有元件，餓了麼移動采取了版本化的管理方式。

對于業務的元件化，我們采取了業務子產品注冊機制來達到解耦合的目的。每個業務子產品對外提供相應的業務接口，同時在系統啟動的時候向Excalibur系統注冊自己子產品的Scheme（Excalibur是餓了麼移動用來儲存Scheme與子產品之間映射的系統，同時能根據Scheme進行Class反射傳回），從Excalibur系統中擷取相關執行個體，并調用相應接口來實作調用，進而實作了業務子產品之間的解耦目的。

根據80%的使用者通路20%頁面這一80/20原則，保證這20%通路最頻繁的頁面的穩定性就是保證了80%的APP的穩定性。是以，餓了麼移動對于部分通路最頻繁的子產品進行了React-Native備份。當這部分頁面出現問題時，APP可以通過伺服器的配置，自動切換成React-Native的備份頁面。而與此同時開發人員開發一個小而精的Hot Patch來修複出現的問題。當Hot Patch完成修補後，再切換回Native APP的原生功能。

架構更新為：

微信Android架構

參考：https://blog.csdn.net/seu_calvin/article/details/77149750

最初的微信架構：

但是由于代碼膨脹，基礎工程出現了中心化問題，導緻許多業務存儲類被附着在一個核心類上于是元件結構出現了問題：

膨脹的來源很多來自業務相關代碼。因為不同子產品有共用的資料結構類，不得不把類進行下沉，這就造成了基礎工程的臃腫。同時還伴有子產品邊界破壞、基礎工程中心化，都是代碼持續劣化的幫兇。

解決方案是

• 改變通信方式：EventBus需要知道确切的baen格式，是以采用協定通信的方式，繞開讓不同的功能耦合不必要的對象。
• 重新設計子產品
• 限制代碼邊界：消滅代碼經常下沉的“三不管區域”——基礎工程。這意味着原來的子產品要把之前下沉的代碼重新認領回去。然後再遍以上進行隔離(沒弄過，不知道流程)。

最後的架構：

反思：

目前Android端App整體架設計上，主要有幾個分支：

• App“大前端”化
• 插件化/應用沙盒（可以參考如atlas、small、DroidPlugin、DynamicApk等等方案）

不難發現讓子產品最終具備動态性是它們最核心的能力。

插件化/應用沙盒：好處是它具備很強的隔離性，有些方案可以徹底隔離代碼和資源，邊界限制性極強，效果很好。此外，多數方案也都具備動态更新能力、更新檔能力，動态性基本成為标配。但是沙盒隔離容易導緻代碼複用困難和互相調用麻煩，對于開發除了造成開發效率減慢，同時也會因為複用不了功能，進而造成代碼臃腫。是以，沒有絕對的好架構，隻有合适自己項目的架構！

我的正在實踐施工的項目位址：

https://github.com/huhanghao/MvpModuleFramework