資料整理：
android常見的事件總線庫
EventBus in GitHub
最新版本3.0.0
AndroidEventBus
最新版本1.0.4
otto
最新版本 1.3.8
相關(guān)博客
事件總線源碼分析
這篇文章從訂閱/發(fā)布模型入手剃盾，介紹了EventBus和Otto兩個事件總線框架束昵，并從源碼角度解析了EventBus（源碼非最新）
Android事件總線 ( AndroidEventBus ) 開源庫發(fā)布
任玉剛的博客垂睬，從android跨組間通信入手，介紹了自己的開源庫AndroidEventBus署辉，分析了greenrobot的EventBus的不足，并提出自己的改進(jìn)方式。
otto 源碼分析
Square公司的otto同樣基于發(fā)布-訂閱模式, 通過注解的形式將具體的方法作為訂閱者和發(fā)布者剑辫。
上面三篇博客分別主要介紹了目前android中三個最主要的事件總線庫，這里我借用一張表格來簡要展示下各種的優(yōu)缺點(diǎn)（表格轉(zhuǎn)自任玉剛渠欺，也就是AndroidEventBus的作者）：
| 名稱 | 訂閱函數(shù)是否可執(zhí)行在其他線程 | 特點(diǎn) |
|---|---|---|
| greenrobot的EventBus | 是 | 使用name pattern模式妹蔽，效率高，但使用不方便挠将。 |
| square的otto | 否 | 使用注解胳岂，使用方便，但效率比不了EventBus舔稀。 |
| AndroidEventBus | 否 | 使用注解乳丰，使用方便，但效率比不上EventBus内贮。訂閱函數(shù)支持tag(類似廣播接收器的Action)使得事件的投遞更加準(zhǔn)確产园，能適應(yīng)更多使用場景汞斧。 |
事件總線存在的優(yōu)點(diǎn)想必大家都很清楚了，android自帶的廣播機(jī)制對于組件間的通信而言什燕，使用非常繁瑣粘勒，通信組件彼此之間的訂閱和發(fā)布的耦合也比較嚴(yán)重，更重要的是對于事件的定義屎即，廣播機(jī)制局限于序列化的類（通過Intent傳遞）庙睡，不夠靈活。
這里談到的事件總線庫剑勾，其實(shí)本質(zhì)都是基于“事件總線框架”埃撵，這套框架采用的是“發(fā)布/訂閱”模型。事件類 事件總線 發(fā)布者 訂閱者 這四個核心角色是這一框架的基礎(chǔ)虽另，說白了暂刘，事件總線通過不同的調(diào)度策略，在已維護(hù)的“事件-發(fā)布者-訂閱者”的集合中捂刺，將事件從發(fā)布者傳遞到訂閱者當(dāng)中谣拣。使用簡單是因?yàn)椋l(fā)布者和訂閱者的注冊族展，都由事件總線統(tǒng)籌管理森缠。訂閱函數(shù)由事件總線通過注解或者反射的方式自動維護(hù)和調(diào)用。 otto和AndroidEventBus采用的是注解仪缸，EventBus則是規(guī)定方法名基礎(chǔ)上采用反射贵涵。
從調(diào)度策略角度，EventBus定義了四種ThreadMode恰画，通過訂閱方法的名稱來實(shí)現(xiàn)宾茂。otto的event bus模式事件調(diào)度的重要規(guī)則是事件調(diào)度僅在發(fā)送線程域中進(jìn)行，通過線程控制策略ThreadEnforcer類實(shí)現(xiàn)不同的線程控制拴还。同樣的跨晴，AndroidEventBus同樣定義了三種ThreadMode，與 greenrobot的EventBus定義的區(qū)別也僅是片林，前者采用注解端盆，后者采用方法名標(biāo)記。
