軟件時序設計相關的問題時序問題是最容易出問題的地方，“時”代表時間順序和時效性，一旦執行順序錯亂，或執行過慢失去時效，就會導致錯誤。

消息的串行化處理

每個任務、線程，只能按順序的處理串行的消息，然而，其他線程發送過來的消息并不是串行發送的，不同線程都是并行、異步發送消息的，這會導致線程在沒有處理完一個消息，另一個消息又回來了。如何把外部的并發消息轉換成線程的串行處理呢？

每個任務、線程都應有一個消息隊列，外部線程向消息隊列中發送數據，目標線程從消息隊列中讀取消息，這樣所有的消息被串行在消息隊列中，線程就會串行的處理每個消息，只有當一個消息處理完（函數調用返回）時，才會處理另一個消息。參考《嵌入式軟件的設計模式（上）》中的 第3.3節 “隊列模式”。

超時或消息丟失引發的問題

一個任務、線程給另一個任務、線程發送消息，等待對方的應答，有時候對方忙，發送時隊列滿發送失敗，或者接收方沒有處理回復，等待一段時間后空閑了才處理該消息并應答時，但對于發送方已經超時。發送方超時，就需要進入異常處理。這里容易出問題，它可能會引發一連串的異常處理反應，也有可能影響后續的正常消息的處理。

消息丟失是必須考慮情況，發送方不能假設接收方一定能夠收到消息，也不能假設接收方一定能夠及時的回應，必須充分考慮到消息因為傳輸的問題丟失或對方忙，沒有及時回應的情形。

消息丟失就容易產生理論上該執行的動作沒有執行，或者消息里面動態內存未釋放。或者消息處理慢導致對外設的控制延遲產生異常，曾經出現共享單車鎖里面的馬達停止消息處理不及時導致車鎖無法再次上鎖。尤其處理通信時序要求嚴格，或外設控制要及時的場景需要注意。

性能本身問題

數據處理尤其是復雜算法耗時，導致消息處理不及時，最終對外設的控制或者通信交互時序狀態延遲，產生異常。這種只能優化算法，或對時序部分單獨特殊處理，不考慮設計模式保執行效率。或者評估階段就選擇性能資源更佳的硬件方案。

異常處理不充分問題

軟件設計一般是考慮正常流程，然而實際運行中，并非是理想狀態，系統總會遇到各種異常，健壯的系統，能夠充分考慮到各種異常情況，一旦異常發生，程序也不會輕易崩潰。

超時：增加超時定時器事件以及事件處理，不能假設對方一定應答消息。

空指針：不能假設一定能夠申請到內存，要考慮到返回為NULL的情形，通過指針訪問內存對象時需要及時的檢查指針是否為空。

并發訪問：在并發執行的系統中，如果要訪問全局變量，不能假設只有一個線程訪問全局變量，需要通過鎖對全局共享資源進行加鎖，特別是要訪問全局的數據結構。

消息隊列：不能假設消息隊列始終有效，要考慮消息隊列滿或空的情形。

設計：在軟件設計時就考慮軟件的異常處理機制，功能層面就支持異常記錄、售后調試的需求，而不是把這個工作留給編程人員。