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

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

 

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

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

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

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

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

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

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

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

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

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