反思 | 事件總線的局限性,組件化開發流程中通信機制的設計與實作

反思 系列博客是我的一種新學習方式的嘗試，該系列起源和目錄請參考 這里 ，

背景

諸如EventBus\RxBus\LiveDataBus的事件總線庫在業內正遭濫用，

誠然，事件總線看起來 小而美 ，但隨著業務復雜度上升，事件的發送和訂閱到處分布，這個優勢反而成為了負擔，因此，筆者不建議在任何量級的專案中使用事件總線庫，更多原因讀者可參考 這篇文章 ，

更合理的方案是什么呢？在量級較小的專案中，開發者應該通過 依賴注入 將Callback進行不同層級的依次傳遞，以保證 層級間的依賴關系足夠清晰，

而對于體量逐漸增大的專案而言，專案的模塊化、組件化、插件化改造被提上日程，各團隊負責不同的業務線，將業務分割成組件，并基于組件本身進行開發，于是我們有了新的訴求，即 組件與組件保證是隔離的，同層級的組件間不應該持有其它組件中類的參考，

需要注意的是，即使專案組件化，組件間也仍有通信的場景，但這并非使用事件總線的借口——對大體量的專案而言，EventBus\RxBus\LiveDataBus這種事件總線庫太局限了，其能力已完全滿足不了專案架構的需求，因此，一個適用于組件化開發的 通信組件 的需求迫在眉睫，

本文將對組件化開發流程中 通信組件 的設計理念與實作方式進行完整的敘述，這里的 通信組件 并非特指某個已有的工具庫（比如ARouter、WMRouter等），事實上，它們都是組件化開發流程的實踐之一，

本文結構如下：

一、組件間通信的基本實作

1、Android原生通信機制

對于組件間通信，最經典的場景當屬頁面跳轉，對于Android而言，Activity之間相互隔離，原生API對頁面跳轉提供了兩種實作方式：

第一種方式是常用的 顯式意圖，通過 startActivity 或 startActivityForResult，這種方案簡單且實用，但在組件化開發流程中，組件間未持有其它組件中Activity.class的參考，因此無法支持組件間的跳轉，

第二種方式則是相對冷僻的 隱式意圖，這種方式支持組件間以及跨行程通信，比如，開發者可以通過隱式意圖喚起系統的呼叫頁面：

// 喚起撥號頁面
private void call() {
    Intent intent = new Intent();
    intent.setAction(Intent.ACTION_CALL);
    intent.setData(Uri.parse("tel:" + 119));
    startActivity(intent);
}

由于代碼中不存在類依賴的關系，隱式意圖更適合組件間通信，但其缺陷也很明顯：

• 1.隱式意圖需將Activity對應的配置規則和引數以action等標簽的形式，集中宣告在Manifest中，不利于引數的管理，且擴展性不佳，進而導致團隊協作困難；
• 2.開發者對路由控制能力不強，由于整個路由跳轉行為都由系統控制，因此，當路由出現例外時，無法進行自定義補救，比如跳轉一個錯誤頁面（類似H5的404），

現在看來，原生API對組件間頁面跳轉能力的提供，確實還略有不足，但這依然不是真正的問題所在，

能真正引爆這些定時炸彈的，只有 業務需求 本身，

2、導火索

即使Google推出了Navigation架構組件，很多開發者依然對這種單Activity多Fragment的開發模式不買賬——平白無故增加專案復雜度毫無意義，

無論如何，一個簡單的計算器app也無必要引入復雜的工程架構，以及組件/插件化的開發流程，

因此，與其熱火朝天討論某個新框架流行與否，讀者更想看到它到底是解決了什么問題，

那就是業務的 爆炸性增長，

隨著微信、支付寶等一眾大型和中型應用規模逐漸擴大，即使是原生的跳轉機制也無法滿足組件化開發的需求，比如，首頁的若干個Tab對應的不同Fragment身處不同組件，這時Fragment之間的通信該如何保障？

同時，隨著業務粒度的愈發細分，甚至單個Fragment中的View都來自五湖四海（比如商品詳情頁面， 視頻預覽 和 商品評論 的控制元件分別由不同業務組件提供）; 更深入思索一下，若商品介紹一欄是由WebView提供的——涉及到H5和原生的互動，我們又該如何定義H5與原生間通信的介面？

由此可見，Activity自身的通信機制確實已經不夠用了，

3、組件間通信的基本實作

對于多元化的通信需求而言，首先最重要的是將通信協議進行統一，無論是Activity間跳轉，還是Fragment、View之間的通信，亦或是H5與原生的互動，我們都通過類似http的url的形式定義：

// 跳轉 用戶模塊 - 登錄頁面
String loginUrl = "route://com.example.route/user/activity/login"
// 跳轉 用戶模塊 - 注冊頁面
String registUrl = "route://com.example.route/user/activity/register"

// 跳轉 商品模塊 - 詳情頁面， id為商品的id
String detailUrl = "route://com.example.route/buy/activity/detail?id=xxxxx"    

定義好了之后，對于組件間頁面跳轉，可以如下操作：

Router.route(detailUrl);  // 在用戶模塊，發起商品模塊中頁面的跳轉

應用接收到這樣自定義、且支持攜帶引數的url，通信庫內部決議后統一分發，進行對應頁面的跳轉，這樣我們就實作了最基礎的通信功能，

4、降級策略與攔截器機制

接下來我們針對 隱式意圖 對 錯誤處理能力不足 這點進行深入性討論，

在組件化開發流程中，開發者通常在當前的組件的Demo上進行開發，雖然模塊自身是可運行的，但是當涉及到其它組件的通信，問題隨之而來，

和完整的工程相比，Demo上未持有其它組件中Activity的宣告，直接通過 隱式意圖 發起通信會導致系統拋出例外，

那么，我們希望當通信發生錯誤時，可以針對不同的環境提供不同的降級策略，以保證開發者和用戶的體驗，比如：

• 在Demo工程的開發流程中，當嘗試跳轉其它組件時，獲得一個「該url不在當前組件工程中」的提示；
• 在集成了所有組件的主工程中，在遇到不合法的url時，則為用戶跳轉一個通用的404頁面，

如有可能，通信庫在路由的程序中，能提供限速、屏蔽等 靈活 且 簡單 控制的可能性，那么就更好了，

因此，以ARouter為首的絕大多陣列件通信庫都提供了這種能力，實作方式也使用了非常經典的 攔截器 機制，通過 遞回 將通信事件向下分發，在需要處理的層級中進行攔截處理，

5、潑冷水時間？

本小節筆者將以ARouter為例，闡述頁面間路由庫的一些局限性，以及導致這些局限性的原因，

毫無疑問，ARouter提供了足夠強大的頁面間路由跳轉能力，它也確實攬括了業內絕大多數開發者的青睞，在開源之初，作者對其的定義就是Android平臺上的 頁面路由框架 ，

這也變相導致自身對UI層級的跳轉能力很強，但對資料通信的支持很薄弱，

什么是對資料通信的支持呢？讀者知道，除了可見的UI互動，資料的互動也非常頻繁，比如通過組件間通信，向用戶組件獲取當前用戶資訊、向訂單組件獲取某個訂單資料等等，

ARouter并不支持這些嗎？實際上并非如此，ARouter自身提供了IProvider介面實作組件間服務的管理，并提供服務的自動注冊和依賴注入，

但遺憾的是，由于ARouter自身設計原因，其初始化只針對當前行程，這也導致了其路由表的自動注冊和攔截器相關機制都是單行程的，

而在目前國內多行程、插件化的多元發展環境下，若想向其它行程的服務直接獲取資料，ARouter是無能為力的，需要開發者通過AIDL等方式來自己實作，

6、洗白

那么導致這些局限性的原因，是因為ARouter這類頁面路由庫自身設計的不足嗎，并非完全如此，從技術角度而言，為ARouter添加行程間通信的支持是可行的，

大而全的框架往往也是摻雜了各種私貨的大雜燴，看似 功能強大 ，實則 臃腫不堪 —— 筆者更喜歡類似Retrofit的設計，將網路請求的功能 收斂，并將 反序列化、回傳型別、網路請求擴展 等相關功能通過Converter、Adapter、Interceptor的方式抽象出來，交給開發者選擇性依賴后，再自行組裝，Retrofit自身則絕不多干涉一分一厘，

同樣，作為 頁面路由框架 ，ARouter目前的設計已滿足現有需要，對于行程間通信，ARouter可以在IProvider的實作中，通過宣告AIDL進行通信，最終將結果交還給ARouter去分發，這也正符合了其開源時所提倡的口號：簡單 且 夠用，

現在我們知道，對于業務量級不大，尚以 頁面跳轉 為主要通信手段的應用而言，ARouter這類 頁面路由框架 已足夠使用；但是，對于更為復雜的專案而言，組件間 資料獲取 更加頻繁，作為設計者，如何保證靈活性的同時，提供更便捷資料通信的可能呢？

二、更高維度的支持

從更高維度的視角來看，無論是UI層級的 頁面跳轉，還是業務層級的 資料獲取，都可將其抽象為一種 通信:

1、通信和通信結果的定義

對此，我們可以對通信協議進行如下的定義：

// 跳轉 用戶模塊 - 登錄頁面
String loginUrl = "route://com.example.route/user/activity/login"

// 獲取 用戶模塊 - 用戶資料
String getUserName = "route://com.example.route/user/service/getUserName"

我們可以像http請求一樣，對頁面跳轉通信的結果進行如下結構的定義：

// 跳轉頁面的回傳值
{
  "code" : "0000",      // 跳轉失敗，可以定義一個錯誤碼，比如 "4000"
  "msg"  : "success",
  "data" : null
}

而對于資料獲取的定義，則可以充分利用data欄位：

// 獲取用戶資訊
{
  "code" : "0000",
  "msg"  : "success",
  "data" : {
    "userName": "James Moriarty",
    "token": "xxxxxxx"
  }
}

這樣，無論是哪種通信，我們都將通信的結果抽象為了Result，并在代碼中進行對應的處理：

class Result {
   @NonNull String code;
   @NonNull String msg;
   @Nullable Object data;
}

// 根據不同種類的通信行為，分別處理result
Result result =  Router.route(url); // url可以是跳轉頁面，也可以是獲取資料

現在我們提供了基本的 UI通信 和 資料通信 的支持，并將Result回傳，但是目前的實作還是無法滿足所有的場景——服務間的通信并非都是同步的，

2、異步通信的支持

對于異步的通信，我們通常理解為 網路請求 ，實際上，網路請求只是 資料異步通信 的一部分，除此之外還有 資料庫操作 、 檔案的讀寫 等等，

難道只有 資料通信 才有異步的場景嗎？當然不是， UI通信 中的異步場景同樣非常多，最簡單的例子就是startActivityForResult，我們希望將登錄的行為交給通信庫，通信庫異步跳轉登錄頁面，登錄成功后，回傳如下定義的登錄結果：

{
  "code" : "0000",    // 登錄成功，也可對登錄失敗、取消定義不同code
  "msg"  : "success",
  "data" : {          // 回傳用戶登錄資訊
    "userName": "James Moriarty",
  }
}

在我們的組件中，就可以針對異步行為進行如下通信：

Callback<Result> callback =  Router.routeAsync(loginUrl);
// 執行異步通信
callback.excute(result -> {
    // 登錄頁面登錄結果（或網路請求結果）回傳后，進行處理
});

這樣，無論是網路請求，還是異步UI登錄，我們都將通信的結果，抽象為一個回呼函式，將具體的實作內置在通信庫中，其它組件的開發者無需關注實作的細節：

對于UI通信而言，如何實作成這樣的API? 舉例來說，我們可以將Activity的onActivityResult()委托給一個不可見的Fragment處理，感興趣的讀者可參考Glide或者ViewModel的原始碼，

3、多行程的支持

本小節部分內容節選自 @Spiny 的 這篇文章，

目前，因為本身是JVM級別的單例模式，因此我們Router并不支持跨行程通信，

上文我們也同樣提到了，想進行跨行程通信也很簡單，只需要在接收到需要跨行程通信的url時，自己實作跨行程的呼叫即可，

既然現在我們的Router已經脫離了類似ARouter這種 頁面路由框架 的范疇，將UI和業務都在更高維度進行了抽象，那么，能否提供針對Router本身提供更強大的支持呢，比如跨行程通信？

其實解決的方法也并不復雜，原來的路由系統還可以繼續使用，我們可以把整套架構想象成互聯網，現在多個行程有多個Router，我們只需要把多個Router連接到一起，那么整個路由系統還是可以正常運行的，所以我們把原有的Router稱之為本地路由LocalRouter，

現在，我們需要提供一個IPS、DNS供應商，那就創建一個行程，該行程的作用就是注冊路由，鏈接路由，轉發報文，我們稱之為廣域路由WideRouter，

我們先來看下路由連接架構圖：

如圖所示，豎直方向上，每一列，代表一個行程，通過虛線隔開，分別有 Process WideRouter、Process Main、Process A、···、Process N 這些行程，淺黃色的代表 WideRouter，深黃色 的代表 WideRouter 的守護 Service，淺藍色 的代表每個行程的 LocalRouter，深藍色 的代表每個 LocalRouter 的守護 Service，

WideRouter 通過 AIDL 與每個行程 LocalRouter 的守護 Service 系結到一起，每個 LocalRouter 也是通過 AIDL 與 WideRouter 的守護 Service 系結到一起，這樣，就達到了所有路由都是雙向互連的目的，

除了AIDL之外，市場上的通信庫還有各種各樣跨行程通信的實作方案，例如BroadcastReceiver、Socket、ContentProvider、Binder等等，有興趣的讀者可以查看文末的參考鏈接，分別對比它們不同的實作方式，

三、更多元化的設計

目前，我們已經完成了組件間通信機制核心功能的實作，接下來我們針對其它部分的功能，針對不同開源框架中的不同實作方式，進行簡單的討論，

1、組件的自動注冊

不同的組件各自向外暴露不同的功能，我們需要將url和對應的邏輯進行系結，以保證Router能夠在接收到對應通信的url時，作出對應的回應，這個流程我們稱之為組件的注冊，

舉例來說，在完整的專案工程中，我們對所有組件的url進行注冊；而在組件自身的demo中，我們對demo自身所需要的組件進行注冊，

那么，對于高度組件化的專案而言，組件的粒度切分的非常細，這時在代碼中手動對組件一一注冊成為了一個苦力活，因此，是否有必要設計一個技術方案，保證在應用啟動時，通信庫能夠對應用依賴的所有組件進行自動注冊呢？

1.1 不實作自動注冊的理由

首先我們先討論，通信庫不實作自動注冊的理由，

不提供自動注冊是一種偷懶嗎？筆者認為不完全是，手動注冊的好處在于，首先，開發者對注冊的組件總是已知的——這最簡單且直接地提供了組件動態化可插拔的能力，且不易出錯，

其次，手動注冊的方式，能夠更靈活對應用的啟動性能優化進行保障，并非所有組件都需要在應用啟動時進行立即注冊，當組件很多時，組件的注冊成本是否會影響App啟動的速度？這些問題都是需要去考量的，

1.2 APT實作自動注冊

而對于自動注冊，最大的問題在于如何找到所有組件中url的映射關系，然后對其自動注冊處理，而如果在運行期處理則有可能會大量地運用 反射，因此這種方案并非首選，

對此，以ARouter為代表的通信庫使用到了 注解處理器（AnnotationProcessor），通過在編譯期對專案進行掃描處理，決議注解，找出所有組件中對應的映射關系，然后存入并生成對應的映射檔案類；在運行時，對這些組件的映射檔案類進行一一注冊，從而完成整個專案的自動注冊，

表面來看，注解處理器 已經滿足了我們的需求，實際上還有一個隱藏的問題，那就是編譯時注解的特性只在原始碼編譯時生效，并不能針對aar檔案中的注解進行掃描，因此，我們還需要保證APP在啟動時能找到所有的映射檔案類，否則注冊根本無從談起，

ARouter曾經的實作方案是第一次啟動對所有dex檔案進行讀取，遍歷每個entry查找指定包內的所有類名，然后反射獲取指定的類物件，統一進行注冊，雖然初次效率并不是非常高，但最后會進行本地快取，以保證之后啟動注冊的效率，

1.3 編譯期位元組碼修改注冊

有沒有更高效的注冊方式呢？

CC 組件通信庫提供了另外一種 編譯期修改位元組碼 的實作方案，大致思路是：在編譯時，掃描所有類，將符合條件的類收集起來，并通過修改位元組碼生成注冊代碼到指定的管理類中，從而實作編譯時自動注冊的功能，不用再關心專案中有哪些組件類了，不會增加新的class，不需要反射，運行時直接呼叫組件的構造方法，

對這種方案感興趣的讀者可以參考這篇文章.

由此可見，即使是組件的注冊流程，各個庫的維護者都做出了各種各樣的實踐，而只有明白了每種方案的設計理念，才能對庫本身的適用場景有更清晰的認知，

2、依賴注入，從Square到Google？

ARouter在頁面的跳轉上提供了一個不同于其它通信庫的功能，那就是能夠將發起頁面跳轉時傳入的引數，通過依賴注入的方式自動注入到對應的Activity中，

這篇文章中闡述了該功能是如何實作的，很有趣的是，在該功能最初的實作方案中，是運行期通過反射拿到ActivityThread實體，最終在Activity實體化的時候，通過反射把Intent預先存好的引數值寫入到需要自動裝配的欄位中實作的，

這種方案的缺點很明顯，除了反射帶來的性能影響外，甚至可能導致用戶的代碼出現NPE，因此這種實作方式后來被新的方案所代替，

新的方案依然是我們的老朋友AnnotationProcessor，在編譯期間，其為Activity生成一個對應的注入輔助類，運行時通過輔助類對Activity中的欄位進行賦值，

這也是Square最初推出的依賴注入庫dagger，被Google后來居上的dagger2代替的原因，

還有另外一個問題，為什么其它通信庫沒有像ARouter一樣提供這樣一個依賴注入的功能呢，是因為做不到嗎？

并非如此，在其它通信庫中，我們將頁面的跳轉進行了更高維度的抽象，因此，如果設計一個新的功能，這個功能也更應該是針對 通信 整體的概念而服務，而非部分場景，

小結

本文針對組件化開發流程中核心的 通信機制 進行了系統性的描述，

對于組件化而言，其目的在于在 業務模塊間的解耦，而事件總線除了能給開發者帶來開發上暫時的便利，以及 貌似解耦 的假象之外，更多埋下了組件間依賴關系 混亂的種子，并非長久之計——更合理的方案是針對性引入適合自身專案、且更全面的組件間通信庫，

篇幅所限，很多優秀的開源專案中的功能和設計未能一一闡述，有興趣的讀者可以從下文的鏈接中進行選擇性的參考，

參考 & 感謝

細心的讀者能夠發現，關于 參考&感謝 一節，筆者著墨越來越多，原因無他，筆者 從不認為 一篇文章就能夠講一個知識體系講解的面面俱到，本文亦如是，

因此，讀者應該有選擇性查看其它優質內容的權利，甚至是為其增加一些簡潔的介紹（因為標題大多都很相似），而不是文章末尾甩一堆https開頭的鏈接不知所云，

這也是對這些內容創作者的尊重，如果你喜歡本文，也同樣希望你能夠喜歡下面這些文章，

1、開源最佳實踐：Android平臺頁面路由框架ARouter @劉志龍

對于ARouter的創作流程和設計理念，沒有比作者本人更有發言權的了，這篇文章從理論到實踐都講解的非常清晰、流暢且自然，對于想要深入學習ARouter的讀者不要錯過，

2、Android架構思考：模塊化、多行程 @Spiny

相比較ARouter, ModularizationArchitecture 這個通信庫及其作者似乎更低調，但從文章中可以得知，作者本人對組件化的理解非常深入，尤其是將行程間通信機制的實作，比喻為互聯網，非常易于理解，因此直接將部分原文放在了 多行程的支持 一節，再次感謝！

3、Android組件化之(路由 vs 組件總線) @luckybilly

這篇文章是CC的作者的原創文章，針對 路由 和 組件總線 進行了深入的對比，非常深入，推薦，

4、多個維度對比一些有代表性的開源android組件化開發方案 @luckybilly

5、一種更高效的組件自動注冊方案(android組件化開發)

luckybilly的另兩篇好文，前者針對市面上一眾主流的通信庫進行了不同角度的對比，后者針對組件自動注冊的不同實作進行了深入的對比，強烈推薦！

6、WMRouter：美團外賣Android開源路由框架

美團開源的WMRouter介紹文章，有興趣的讀者可作為引申閱讀，

關于我

Hello，我是 卻把清梅嗅 ，如果您覺得文章對您有價值，歡迎 ??，也歡迎關注我的 博客 或者 GitHub，

如果您覺得文章還差了那么點東西，也請通過 關注 督促我寫出更好的文章——萬一哪天我進步了呢？

• 我的Android學習體系
• 關于文章糾錯
• 關于知識付費
• 關于《反思》系列