組件間通信機制：
1.本地廣播:
本地廣播特點：（觀察者模式的運用）
比全局廣播更快，出自於Android.support，（底層實現是handler）；
僅限APP內傳播，安全性，保密性，效率遠高於全局廣播；
不支持靜態註冊；
缺陷：無法干涉傳輸途中的任何步驟。
也存在比本地廣播更加高效的通信方式：事件總線。
2.EventBus：
替代Intent，Handler，Broadcast，在Fragment,Activity,Service,Thread之間傳遞消息。
特點：開銷小，代碼優雅，解耦,。可以動態設置事件處理線程和優先級。
特別注意：onDestory中必須調用取消訂閱，強引用。內存泄漏後各種靈異事件，足以讓你找不到北，別問我咋知道的，說多了都是淚。
但是EventBus也有缺點：類似策略模式，每個事件都必須自定義一個事件類，造成事件類過多，無形中加大了維護成本。
EventBus3.0與EventBus2.x用法類似，3.0開啓索引系統後，速度遠快於2.x。
2.x運行時註解，反射耗費效率，低端手機中頻繁反射，影響性能。
3.0採用編譯時註解，Java文件編譯時，變成.class文件時，完成註解。
並且3.0還池化了對象，建立對象池，減少了反覆創建對象的開銷。
3.RxBus：
RxJava響應式編程的運用，不牽涉反射，效率更高。比監聽者模式的EventBus2.x更高效，線程調度和鏈式操作比EventBus優秀。
如果項目中引入RxJava可以考慮使用RxBus，如未引入，EventBus3.0將是更好的選擇。
4.組件化事件總線的考量：
信息容器模板需要放在一個公共位置，例如Base Module，但是通信就會依賴BaseModule，這種設計顯然不合理。違背了模塊獨立，通用的原則。每次增加其他模塊 都要修改BaseModule，耦合性太強，就算刪除模塊，可以不改BaseModule但是無用代碼 ，會使之臃腫不堪。這是目前組件化通信遇到的瓶頸問題。
兩種比較適合現階段組件化的通信方式：
4.1 ModuleBus：
ModuleBus能傳遞一些基礎類型的數據，不會影響Base模塊的架構，但是自定義的事件信息模板仍需要添加到BaseModule中才能讓其他功能模塊索引。使用方法類似EventBus。
4.2組件化架構的ModularizationArchitecture庫。
每個功能模塊中需要使用註解建立Action事件，每個Action完成一個動作，invoke只是方法名爲反射，並未用到反射，而是使用接口方式調用。參數是通過HashMap<String,String>傳遞的，無法傳遞對象。
以上兩種方法都能解決組件化中註冊事件到BaseModule的冗餘問題。
缺點在於：
- 無法像EventBus擁有類名索引，也無法傳遞自定義實體類到其他模塊，這樣無代碼提示，無法引導正確編寫代碼；
- 只能傳遞基礎數據類型和數據結構，無法傳遞class類型對象。
任何一個工具都不可能是完美的。