文章主題

在我們的日常編程中，對消息隊列的需求非常常見，使用一個簡潔、高效的消息隊列編程模型，對于代碼邏輯的清晰性，對于事件處理的高效率來說，是非常重要的。這篇文章就來看看 ZWave 中是通過什么機制為我們提供了一個便捷的消息隊列處理機制。



    內容導航

• 消息隊列是什么

• 我自己寫的消息隊列

• ZWave 消息隊列的結構

• ZWave 消息隊列的使用（初始化、存儲消息、取出消息）

  消息隊列是什么
  

  消息隊列最主要特點是：存儲消息，先進先出。

  比如在典型的生產者-消費者編程模型中，先創建一個消息隊列，最大容量是 100。

  當生產者產生一條消息時，如果消息隊列未滿，就放進消息隊列的尾部。

  消費者定期去檢查消息隊列中是否有消息，如果有，則取出最前面的那條消息進行處理，直到把隊列中的所有消息都處理完。

  當然，如果鏈表來創建一個動態的消息隊列也是可以的，這樣就可以構成一個無容量限制的隊列，這個模型有點復雜，咱們暫且不討論它。

我自己寫的消息隊列  


在我自己的開發過程中，經常需要使用消息隊列來保存多條消息，每一條消息都存儲長度不等的字符串，于是就自己寫了一個最簡單的消息隊列實現模板，當然對于項目來說也是最合適的，因為是量體裁衣嘛。

一共2個文件(.h, .c)，每次項目中需要用到時，就把這2個文件拷貝過來，再簡單修改一下（保存的每條消息滿足應用的需求），就直接用上了。簡單、粗暴、有效、好用，每次都能很塊就解決我的問題。

這里簡單截個圖，如果需要，我可以免費分享！

使用起來也比較簡單，只需要3個步驟。

ZWave 消息隊列的結構  


ZWave SDK 的每一個 Sample 中已經給我們提供了一個很好的消息隊列編程模型，不過它還嵌入了一個 task 任務管理的機制，后面我會簡單畫一下 task 的處理邏輯，但是不會深入探究。

先來看一下 ZWave 提供的消息隊列的結構。

請注意：這是消息隊列的結構，而這個隊列中存儲的每一條消息是存儲在一個數組緩沖區中，通過 array 指針進行引用。因此，在消息隊列初始化的時候，必須提供一個數組，并把數組的地址賦值給 array 指針。

關于這個數組，從代碼中可以看到 QElementType 其實就是一個無符號字節，因此，這個消息隊列僅僅能存儲最最簡單的消息，即：一個字節的數值。可以看一下 SwitchOnOff.c 中所存儲的消息，都是 EVENT_APP 這個枚舉類型的值。


    ZWave 消息隊列的使用

1.消息隊列的初始化

在應用程序初始化的時候，ZWave 實例程序為我們已經創建好一個消息隊列了，流程如下。

可以看到，一共有 2 個消息隊列：eventQueue 和 jobQueue，這兩個隊列的實現機制都是一樣的，只不過是把不同類型的消息放在不同的隊列而已，因此，只要分析其中一個 eventQueue 就可以了。

初始化完成之后，存儲消息的數組是空的，消息隊列的有效消息個數是 0。

2.存儲消息到消息隊列

就是把一條新消息放入消息隊列的數組中，然后更新消息隊列的一些狀態參數，比如：有效消息長度，存儲的這條消息位置等等。

函數調用流程如下。

3.從消息隊列中獲取消息

這個也很好理解，就是通過消息隊列的結構檢查一下是否有消息等待處理。如果是的話，就取出消息，并更新消息隊列的一些狀態參數。

函數調用流程如下。

ZWave 文檔中已經說明，協議層會定期調用應用層的函數 ApplicationPoll( ) ，這也是 ZWave 推薦的方式讓應用層執行自己的邏輯，但是應用層不能在這個函數中執行太長時間。

在這個函數中，我們可以直接去消息隊列中取出一個消息。但是如果這么做的話，就浪費了 ZWave 為我們提供的 Task 機制，因此這里調用了 TaskApplicationPoll( )，然后我們應用層的事件處理函數 AppStateManager( ) 就老老實實的待著，等待別人把事件消息準備好、喂過來。

其實，這也是一種分層編程思想，如下。

** 總結 **

現在再回頭看一下 ZWave 的消息隊列處理機制，思路非常清晰，而且擴充性非常強。

后面我希望自己可以抽一點時間，把這里的代碼抽取出來，寫一個通用的、能夠處理一些復雜消息的消息隊列機制，讓開發過程變得更加愉悅！