REventBus背景

在實際的項目開發中，經常會遇到業務與業務，組件與組件，業務與組件之間的通信，舉個例子：當有煙霧傳感器檢測到煙霧超標時，需要打開排氣扇排氣，同時顯示煙霧濃度顯示到顯示器中，供管理人員檢視。處理這樣的邏輯有幾種策略。如下：

1. 排氣扇任務和顯示器任務，不斷的查詢煙霧濃度，各自處理檢測煙霧濃度是否超標。
2. 煙霧模塊提供注冊監聽接口，排氣扇任務和顯示器任務分別注冊監聽，當濃度超標時，告知監聽任務。

以上兩種策略都存在很大的問題，問題分析：

1. 第一種策略，每一個任務都需要不斷檢查判斷，這會導致資源的浪費，而且代碼也會有很多重復的。
2. 第二種策略，雖然解決了第一種策略的的問題，但是如果場景中存在不止一個傳感器時，那么所需要注冊的監聽接口將隨之增加。而且監聽接口是跟具體的業務綁定的。

綜上所述：為了能夠解決上面的問題，REventBus組件應運而生。

REventBus工作流程圖解

Publisher使用publish發出ige一個事件，Subscriber在其回調函數中接收事件。

REventBus依賴組件

為了提供更好的組件化，風火輪科技 和《Rice嵌入式開發技術分享》公眾號聯合推出R組件集，REventbus組件就是R組件集的其中一員，組件與組件之后存在依賴關系.

REventBus組件同樣依賴一些組件，如下：

1. RPlatform組件：平臺適配層，為了能讓R組件能夠在不同RTOS或Linux中運行，針對不同平臺做的適配層。
2. RThread_pool組件： 一個跨平臺，易移植，接口簡單的線程池組件。

REventBus的使用

• REventBus整體包含5部分：Subscribe，Publish，Event，EventCb，Broker。
• Subscribe --訂閱者訂閱自己需要監聽的事件接口。
• Publish --發布者發布事件，它支持同步發送和異步發送。
• Event --訂閱者監聽的事件，只有存在訂閱事件，才會有與之對應的發布事件。
• EventCb --事件產生的回調接口，訂閱者注冊，發布者發布對應事件之后產生回調。
• Broker --事件代理，管理事件注冊，注銷，監聽。

REventBus接口說明

• REventBus初始化接口
• 使用RThread_pool組件創建一個線程池
• 創建互斥量，解決共享資源問題。
• 初始化broker鏈表，用于事件代理。

pf_err_t reb_init(void);

• REventBus去初始化接口
• 線程池注銷，互斥量傷處，

pf_err_t reb_deinit(void);

• REventBus訂閱事件接口: pf_err_t reb_subscribe(const char *event, reb_handler_cb handler)

• REventBus訂閱事件接口: pf_err_t reb_unsbscribe(const char *event, reb_handler_cb handler)

• REventBus同步發布事件接口：pf_err_t reb_publish(const char *event, void *payload, uint16_t lenght)

• REventBus異步發布事件接口：pf_err_t reb_async_publish(const char *event, reb_priority priority, void *payload, uint16_t lenght)