Android事件驅動編程－基於EventBus（一）

雖然在Android開發具有某些事件驅動的特性，但它還遠不是純粹的事件驅動架構。這算是好事還是壞事呢？正如在軟件開發領域中任何事情一樣，想回答它並不容易：這取決於具體情況。

首先我們來給事件驅動編程下一個定義。事件驅動編程是一種編程范式，程序的執行流程是由動作（actions，例如用戶交互，其他線程發送的消息等等）觸發的事件（event）決定的。在這個意義上，Android是部分事件驅動：我們都知道的onClick監聽器或者Activity的生命周期，都是應用中由動作觸發的事件。我為什麼說它不是純粹的事件驅動系統呢？默認情況下，每個事件被綁定在特定的controller上面，因此很難在其他地方使用該事件（例如onClick事件是定義為View服務的，因此它的使用范圍很有限）。

等一下，你在討論的是一個全新的編程范式，使用這個新框架或者方法總會帶來成本的，那麼它能帶來什麼好處呢？答案是肯定的，為了說明它，我將首先說一說傳統Android開發存在的一些限制。

很多情況下我們工程代碼會很容易演變成下圖所示的結構：

Activities可以和Fragments通信，Fragments可以給其他的Fragments和Services發送消息。各個組件之間耦合嚴重，修改代碼的時間代價昂貴。這經常導致產生樣板代碼，例如需要在不同層之間傳播實現了回調函數的接口，你應該知道我想表達的意思。由於代碼量的增加，可維護性和良好的軟件工程實踐隨之降低。<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4KPHA+xMfDtMrCvP7H/bavseCzzMjnus7KudPDxNijv8/Cw+bIw87Sw8fAtL+0v7TB7dK71tbPtc2zvNy5ucnovMajujwvcD4KPHA+PGltZyBhbHQ9"這裡寫圖片描述" src="/uploadfile/Collfiles/20150227/2015022709082234.png" title="\" />

概念上講，上面的系統具有一個Event Bus，不同的實體訂閱這個Event Bus，要麼發送事件，要麼監聽事件－分別作為生產者或者消費者。任何訂閱者可以在不知道業務邏輯的情況下執行動作。想象一下，想象某種具體的可能性：一個Fragment可以在不知道任何操作背後業務邏輯的情況下，只需要收到一個事件，就可以重新執行渲染並更新屏幕顯示。想象一下代碼解耦並得到一個簡潔的，劃分良好的架構的可能性。

Android支持這種編程范式嗎？好吧，部分支持。就如上面提到的，Android SDK本身提供了一個簡化的事件處理技術，但我們想要更多的支持。在這裡有一些名字我想提一下：

EventBus，出自greenrobot。這個函數庫專為Android而優化過，並具有某些高級特性例如線程傳遞和訂閱者優先級。

Otto，出自Square。起初是從Guava fork過來的，後面經過發展，已經在Android平台上進行了完善。

兩個函數庫都試用過，我更喜歡EventBus。Greenrobot聲稱EventBus在性能上比Otto更好，並提供了很多額外的特性。