之前，我簡單介紹了Android中的事件驅動程式設計，並給出了事件驅動的HelloWorld應用程式碼。
現在我們可能面對另一個問題：我們如何正確地使用事件驅動開發，同時不陷入混亂？這篇文章，我將提供一個基於事件驅動規劃應用程式的建議性架構，但也能用於建立更通用型別的應用。
這個架構我已經用了一段時間，並做了一些改動。使用事件和MVP模式確保了嚮應用新增特性非常簡單。同時縮減了重構和重寫之間的週期，所以寫出的軟體有效期更長，質量更高。
第一個術語：MVP
MVP代表模型、檢視、表示器（Model View Presenter），是個程式設計範型，定義了一個軟體系統中需要實現的三種基本實體：
模型：要渲染什麼
檢視：怎麼渲染
表示器：處理模型和檢視間的通訊。表示器用模型中的內容來更新檢視，抽象檢視之下的複雜度。
MVP（以及其他程式設計範型）更像一個概念而不是概念堅實的框架，所以基本上沒有嚴格的規則。Android並沒有實現一個純MVP模式，但是包含一些元素：
- 使用者介面（檢視）定義在XML檔案中。
- 我們通過inflate檢視，然後更新這些檢視來擴充套件類（Activity，Fragment）。
在所有MVP模型的元件中，表示器在Android中沒有直接的表示。但它是個重要的元件：想象下我們需要從web service獲取資料而不是資料庫。如果我們遵守MVP方法，這一點是微不足道的。
事件驅動支撐的架構
下面的架構目標在於讓基於事件驅動的應用實現更簡單。同時還有其他優勢，比如高模組化、易於測試。
我們將建立自己的Application例項。該例項將容納一個EventBus Registry，這個類包含事件匯流排訂閱者的完整列表（稍後再細說）。我們的Application將會註冊所有的訂閱者，然後在終止時登出。
EventBusRegistry
該類基本上是包含事件匯流排所有訂閱者的註冊器。我將自己的訂閱者命名為PluginController，因為你可以隨意插拔而不影響應用的工作（當然，如果不插入它們，就無法監聽事件）。我覺得這種命名可能會誤導讀者，所以本文中我命名為Subscriber。
EventBus Registry保留了EventBus（是個靜態類）的一個引用，這樣它才可以註冊訂閱者。
訂閱者（Subscriber）
訂閱者將是唯一可以監聽事件的類。這些類可以包含一個或多個onEnter()方法。訂閱者接到一個事件就會執行動作。簡單例子：你可以定義一個接到“PerformCallEvent”時執行呼叫的訂閱者。
訂閱者也可以在事件到來時，傳送事件到EventBus。
表示器（Presenter）
表示器執行動作。檢視會分配優先順序，它們一個接一個地執行。它們也可以傳送事件到EventBus。
此架構使用單個Activity。肯定有贊成或反對的聲音，但是由於我們使用不同的Fragment表示螢幕，使用單個Activity會讓事情更簡單（記住，作為一個開發者，你的主要目標是少編碼）。
我把示例專案上傳到了GitHub，這個專案包含一個登陸頁面，會觸發事件執行登陸和載入後續的片段。專案架構如下：
EventBus Registry有很多基礎類，Activity和Subscriber（你可能想根據專案需求增加一個Fragment類）。Application，EventBus和EventBus Registry可以根據專案進行定製（因此加上了ED字首，Event-Driven）。
擴充套件該應用來新增新特性的話，基本上每個特性都需要新事件、訂閱者、表示器和檢視。遵守這個模式可以保證應用是可伸縮的，程式碼是解耦的，因此容易測試和理解。