一種低侵入性的組件化方案 之 傳統組件化方案的問題

github開源地址 github.com/beyondxia/m…

傳統組件化方案介紹

    組件化的核心問題爲組件間的解耦，而解耦就不可避免的要面臨解決組件間的通訊問題，即通訊機制。按照通訊機制的維度來區分，能夠大體歸納爲以下兩種方案：協議通訊、接口通訊。兩者的基本實現原理以下。

一、協議通訊

    協議通訊典型的方式就是使用scheme的方式進行通訊。這種方式能夠將組件間的依賴下降至最小，甚至能夠徹底隔離。其核心思想爲：組件間按照特定的通訊協議進行數據傳遞，框架底層經過反射的方式進行服務方法的調用，從而實現進行組件間的通訊。

二、接口通訊

    上面咱們介紹的協議通訊的設計到協議+反射，因爲反射會帶來的自然問題，如：性能、混淆、代碼可讀性、服務變動對調用者無感知等，因此咱們更傾向於接口下沉的實現方式。

    那麼什麼是接口通訊呢，接口通訊方式也就是咱們前文所提的，經過接口下沉的方式進行模塊間的數據通訊，咱們的框架也是基於這種方式進行組件間交互的，具體作法以下：

1. 組件須要向外提供一個或多箇中間接口文件以暴露本身的服務，接口中包含本組件需向外暴露的具體方法。

public interface ITrainTicketService {
    String SERVICE_NAME = FFServiceConstants.SERVICE_TRAIN_TICKET;
    TrainTicketNavigator navigator();
    void registerJSHandlers(IBridgeFragment fragment);
    int getTicketCount();
}
複製代碼

2. 爲了不組件間的直接耦合依賴，因此的暴露接口和一些共享的類須要下沉至業務之下的服務層。宿主項目需提供一個這樣的公共目錄或者公共模塊用於存放被暴露服務的相關的類文件。

3. 註冊服務：調用框架提供的註冊服務方法，將本組件的實現類註冊進框架中，以供其餘組件調用。
4. 服務調用：經過調用框架提供的特定方法，獲得被調用組件中間接口的實例，此接口即包含被調用組件暴露的全部服務方法，因此調用此接口的實例便可實現對被調用組件的服務的調用。

傳統組件化優缺點分析

協議通訊的不足在上文中已簡單說明，這裏主要分析一下接口通訊機制的優缺點。 優勢：

1. 組件服務的變動對調用者有感知。若組件提供的服務有升級或者變動，則調用者在編譯器便可感知，避免將問題帶到運行期暴露。
2. 服務的調用不依賴反射，因此相比於組件總線的通訊機制，不存在性能、混淆、可讀性上的問題。 不足：
3. 須要提供一個公共的目錄或者公共模塊用做爲服務層，全部接口文件和中間共享的文件都須要手動拷貝至服務層。
4. 組件若須要提供服務，除了自己的實現類，還須要提供一個或多箇中間接口文件，增長了開發量和組件集成的複雜度以及維護成本。
5. 與接口相關的一些中間類（特別是model）也須要同步移動至公共目錄。
6. 因爲服務實現類與服務接口存在依賴關係，因此業務方須要實現暴露的接口，並要實現具體須要暴露的業務功能。。
7. 全部的組件服務的註冊都須要手動進行，增長了開發量與風險。

針對這幾個問題，咱們的modules框架給出了相應的解決方案，具體見下一篇

上一篇：一種低侵入性的組件化方案 之 組件化須要考慮的幾個問題

下一篇：一種簡單的低侵入性的組件化方案