原文鏈接：https://medium.com/google-developer-experts/event-driven-programming-for-android-part-i-f5ea4a3c4eab
雖然在Android開發(fā)具有某些事件驅(qū)動(dòng)的特性，但它還遠(yuǎn)不是純粹的事件驅(qū)動(dòng)架構(gòu)。這算是好事還是壞事呢？正如在軟件開發(fā)領(lǐng)域中任何事情一樣，想回答它并不容易：這取決于具體情況。
首先我們來給事件驅(qū)動(dòng)編程下一個(gè)定義。事件驅(qū)動(dòng)編程是一種編程范式，程序的執(zhí)行流程是由動(dòng)作（actions，例如用戶交互，其他線程發(fā)送的消息等等）觸發(fā)的事件（event）決定的。在這個(gè)意義上，Android是部分事件驅(qū)動(dòng)：我們都知道的onClick監(jiān)聽器或者Activity的生命周期，都是應(yīng)用中由動(dòng)作觸發(fā)的事件。我為什么說它不是純粹的事件驅(qū)動(dòng)系統(tǒng)呢？默認(rèn)情況下，每個(gè)事件被綁定在特定的controller上面，因此很難在其他地方使用該事件（例如onClick事件是定義為View服務(wù)的，因此它的使用范圍很有限）。
等一下，你在討論的是一個(gè)全新的編程范式，使用這個(gè)新框架或者方法總會(huì)帶來成本的，那么它能帶來什么好處呢？答案是肯定的，為了說明它，我將首先說一說傳統(tǒng)Android開發(fā)存在的一些限制。
很多情況下我們工程代碼會(huì)很容易演變成下圖所示的結(jié)構(gòu)：
Activities可以和Fragments通信，F(xiàn)ragments可以給其他的Fragments和Services發(fā)送消息。各個(gè)組件之間耦合嚴(yán)重，修改代碼的時(shí)間代價(jià)昂貴。這經(jīng)常導(dǎo)致產(chǎn)生樣板代碼，例如需要在不同層之間傳播實(shí)現(xiàn)了回調(diào)函數(shù)的接口，你應(yīng)該知道我想表達(dá)的意思。由于代碼量的增加，可維護(hù)性和良好的軟件工程實(shí)踐隨之降低。
那么事件驅(qū)動(dòng)編程如何使用呢？下面讓我們來看看另一種系統(tǒng)架構(gòu)設(shè)計(jì)：
概念上講，上面的系統(tǒng)具有一個(gè)Event Bus，不同的實(shí)體訂閱這個(gè)Event Bus，要么發(fā)送事件，要么監(jiān)聽事件－分別作為生產(chǎn)者或者消費(fèi)者。任何訂閱者可以在不知道業(yè)務(wù)邏輯的情況下執(zhí)行動(dòng)作。想象一下，想象某種具體的可能性：一個(gè)Fragment可以在不知道任何操作背后業(yè)務(wù)邏輯的情況下，只需要收到一個(gè)事件，就可以重新執(zhí)行渲染并更新屏幕顯示。想象一下代碼解耦并得到一個(gè)簡(jiǎn)潔的，劃分良好的架構(gòu)的可能性。
Android支持這種編程范式嗎？好吧，部分支持。就如上面提到的，Android SDK本身提供了一個(gè)簡(jiǎn)化的事件處理技術(shù)，但我們想要更多的支持。在這里有一些名字我想提一下：
EventBus，出自greenrobot。這個(gè)函數(shù)庫(kù)專為Android而優(yōu)化過，并具有某些高級(jí)特性例如線程傳遞和訂閱者優(yōu)先級(jí)。
Otto，出自Square。起初是從Guava fork過來的，后面經(jīng)過發(fā)展，已經(jīng)在Android平臺(tái)上進(jìn)行了完善。
兩個(gè)函數(shù)庫(kù)都試用過，我更喜歡EventBus。Greenrobot聲稱EventBus在性能上比Otto更好，并提供了很多額外的特性。
下一篇文章將講解在EventBus中如何實(shí)現(xiàn)基本的功能。
