儘管Android開發中包含一些事件驅動的特性，但是離純事件驅動架構還很遠。這是好是壞？就像軟體開發中的所有問題一樣，這個答案也不簡單：看情況。
首先，我們來定義一下事件驅動開發。這個程式設計範型中，執行流由動作觸發的事件決定（比如互動，其他執行緒的訊息等）。這個意義上，Android是部分事件驅動的：我們可以認為onClick監聽器或Activity生命週期（它們是事件）可以觸發應用中的動作。為什麼不說它是一個純事件驅動系統呢？預設情況下，每個事件都繫結到一個特定的控制器，除此之外很難進行其他操作（比如，為檢視定義的onClick，作用域是有限的）。
等會，你在說一個新的程式設計範型。採用框架或方法學總會有成本，它能帶來好處嗎？是的，我想展示給大家一些傳統Android開發的限制。
很多情形下，容易造成下圖所示的結構：
Activity可以跟Fragment通訊，Fragment可以向Fragment和Service傳送訊息。元件之間耦合緊密，對其進行更改代價會很高（*）。這樣一來，修改往往會涉及到樣板程式碼、實現了在不同層之間回撥和通訊的函式功能的介面……你應該知道我要說什麼了。隨著程式碼量的增長，可維護性和軟體工程的規範性都在下降。
如何在這裡應用事件驅動程式設計？下面是值得提倡的一種系統：
概念上，這個系統包含一個事件匯流排（event bus）。不同的實體訂閱事件匯流排，派發或監聽事件 — 它們分別是生產者和消費者。任何訂閱者都可以在不瞭解內部邏輯的情況下執行一個動作。考慮一下特殊的情況。：Fragment重複渲染並更新螢幕可以忽略操作背後的邏輯，只要知道事件發生了就行了。想像一下通過這種系統降低程式碼耦合性，使架構簡潔、分離的可能性。
Android支援這個範型嗎？部分支援。上文提到過，SDK原生提供了一個事件處理技巧的子集，但是我們希望能走的更遠。這裡有一些我想提到的概念：
- greenrobot的EventBus。這個庫為Android進行優化過，包含一些高階特性，比如分發執行緒和訂閱者優先順序。
- Square的Otto。它原來是Guava的一個分支，它不斷演化並且為Android平臺進行了改進。
試過之後，對於Otto，我更喜歡EventBus。Greenrobot宣告EventBus效能比對手更好，提供了很多附加特性。
下一篇文章將會探索如何在EventBus中實現基本功能。
（*）當表達“用時很多”時，我故意使用“代價很高/expensive”這個詞。經濟學中的術語通常更有效。