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

摘要： 元件化的核心問題為元件間的解耦，而解耦就不可避免的要面臨解決元件間的通訊問題，即通訊機制。按照通訊機制的維度來區分，可以大致概括為如下兩種方案：協議通訊、介面通訊。二者的基本實現原理如下。 1、協議通訊 協議通訊典型的方式就是使用scheme的方式進行通訊。這種方式可以將元件間的依...

元件化的核心問題為元件間的解耦，而解耦就不可避免的要面臨解決元件間的通訊問題，即通訊機制。按照通訊機制的維度來區分，可以大致概括為如下兩種方案：協議通訊、介面通訊。二者的基本實現原理如下。

1、協議通訊

協議通訊典型的方式就是使用scheme的方式進行通訊。這種方式可以將元件間的依賴降低至最小，甚至可以完全隔離。其核心思想為：元件間按照特定的通訊協議進行資料傳遞，框架底層通過反射的方式進行服務方法的呼叫，從而實現進行元件間的通訊。

2、介面通訊

上面我們介紹的協議通訊的設計到協議+反射，由於反射會帶來的天然問題，如：效能、混淆、程式碼可讀性、服務變更對呼叫者無感知等，所以我們更傾向於介面下沉的實現方式。

那麼什麼是介面通訊呢，介面通訊方式也就是我們前文所提的，通過介面下沉的方式進行模組間的資料通訊，我們的框架也是基於這種方式進行元件間互動的，具體做法如下：

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. 所有的元件服務的註冊都需要手動進行，增加了開發量與風險。