首先我來解釋一下什麼是事件匯流排模式。提到事件匯流排模式你可能很陌生，不知道是什麼，那麼我們換個說法，軟體設計模式中有一種叫做觀察者模式，其實事件匯流排模式就是對觀察者模式的一種實現，它是一種集中式事件處理機制，允許不同的元件之間進行彼此通訊而又不需要相互依賴，達到一種解耦的目的，他就是對觀察者模式的一種拓展。如果你對觀察者模式不太熟悉的話，建議自己找找資料理解一下。接下來我通過android裡面的機制來講解一下事件匯流排模式。
在android開發中，經常會涉及activity,fragment，service等不同元件或者模組之間的訊息傳遞。使用傳統的方法實現，往往**不夠優雅，而且不同元件和模組之間的耦合嚴重。隨著模組的增多、**邏輯的不斷新增和修改，整個**的架構就會顯得越來越混亂。activity中的不同的fragment之間需要進行通訊，傳統的做法是 將activity作為中介，fragment a通過getactivity()獲取宿主的activity例項進而可以拿到fragment b的例項，從而向fragment b傳送訊息或者獲取資料。好一點的做法是在fragment中編寫介面，讓宿主activity實現該介面，從而在activity中實現不同fragment之間的資料通訊。或者多個activity頁面跳轉和資料回傳的問題，例如activity a跳轉到activity b，接著跳轉到activityc，在c中執行一系列操作之後，需要傳遞資料或者事件給activity a，傳統的做法是進行介面**，這樣不僅增加邏輯複雜性，而且增大頁面間的耦合。
發布者publisher：發布某種事件的物件。
事件event：乙個簡單的pojo物件。只包含資料，不對資料進行處理。
事件匯流排eventbus： 負責訂閱者，事件等資訊的儲存，同時處理事件的流動和分發，通過匯流排，訂閱者和發布者是解耦的，互相不知道對方的存在。
訂閱者subscriber： 訂閱某種型別事件的物件。通常會有乙個**函式用於對接收到的事件進行處理，訂閱者可以訂閱事件，也可以去掉訂閱的事件。訂閱者可以引入優先順序的概念，優先順序高的訂閱者可以優先接收到該事件，並可以決定是否繼續傳遞事件給低優先順序的訂閱者。
eventbus一共提供了4種執行緒模型threadmodel，分別是postthread, mainthread, backgroundthread, async。
postthread --------------預設實現，執行發生在發布事件的同乙個執行緒；
mainthread --------------執行在ui主線程上；
backgroundthread、async---兩個都是通過executors.newcachedthreadpool()執行緒池來執行的。
eventbus作為android開發中的常用框架，擁有著許多優點：
排程靈活：不依賴於context，使用時無需像廣播一樣關注context的注入與傳遞。父類對於通知的監聽和處理可以繼承給子類。這對於簡化**至關重要。通知的優先順序，能夠保證subscriber關注最重要的通知；粘滯事件能夠保證通知不會因subscriber的不在場而忽略。 可繼承，優先順序，粘滯是eventbus比之於廣播，觀察者等方式最大的優點，他們使得建立結構良好組織緊密的通知系統成為可能。
使用簡單：eventbus的subscriber註冊非常簡單，呼叫eventbus物件的register方法即可，如果不想建立eventbus還可以直接呼叫靜態方法eventbus.getdefault()獲取預設例項，subscriber接收到通知之後的操作放在onevent方法裡就行了。成為publisher的過程更簡單，只需要呼叫合適的eventbus(自己建立或者是預設的)的post方法即可。
快速且輕量：觀察者這種設計模式應該屬於程式設計師的基本功，由於觀察者的實現比較簡單，因此效能上是三者中最好的，但是觀察者難以控制通知的優先度，特別是一開始沒有考慮優先度中途更高需求又加入優先度。另外觀察者模式要求觀察者在事件發生時在場才能收到通知，這就是的觀察者有可能遺漏事件。客觀來說，這並不能算觀察者的缺點，因為其他的方式往往也是這樣，更加嚴謹的說法是觀察者沒有eventbus優先順序、粘滯事件的優點。但有乙個缺點是觀察者獨有的，那就是觀察者可能會造成介面的膨脹，特別是當程式要求大量形式各異的通知，而程式設計師沒有做出良好的抽象時，**中會包含大量的介面。
軟體架構模式的種類
在做軟體架構設計時,根據不同的抽象層次可分為三種不同層次的模式 架構模式 architectural pattern 設計模式 design pattern 模式 coding pattern 架構模式是乙個系統的高層次策略，涉及到大尺度的元件以及整體性質和力學。架構模式的好壞可以影響到總體布局和框...
軟體框架 架構 模式之我見
軟體框架 架構 模式之我見 軟體框架 軟體框架就是software frameworks，它定義了軟體系統在某個平台上為完成某項功能所提供普遍操作 以及這些普遍操作的內在實現過程。換一種說法，軟體框架提供了若干操作介面，這些操作介面可以完成特定的功能，這些操作介面的實現對我們來說是不可見的，我們只需...
軟體架構模式的種類
在做軟體架構設計時,根據不同的抽象層次可分為三種不同層次的模式 架構模式 architectural pattern 設計模式 design pattern 模式 coding pattern 架構模式是乙個系統的高層次策略，涉及到大尺度的元件以及整體性質和力學。架構模式的好壞可以影響到總體布局和框...