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

消息的串行化處理

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

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

超時或消息丟失引發(fā)的問題

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

消息丟失是必須考慮情況，發(fā)送方不能假設接收方一定能夠收到消息，也不能假設接收方一定能夠及時的回應，必須充分考慮到消息因為傳輸?shù)膯栴}丟失或對方忙，沒有及時回應的情形。

消息丟失就容易產(chǎn)生理論上該執(zhí)行的動作沒有執(zhí)行，或者消息里面動態(tài)內存未釋放?；蛘呦⑻幚砺龑е聦ν庠O的控制延遲產(chǎn)生異常，曾經(jīng)出現(xiàn)共享單車鎖里面的馬達停止消息處理不及時導致車鎖無法再次上鎖。尤其處理通信時序要求嚴格，或外設控制要及時的場景需要注意。

性能本身問題

數(shù)據(jù)處理尤其是復雜算法耗時，導致消息處理不及時，最終對外設的控制或者通信交互時序狀態(tài)延遲，產(chǎn)生異常。這種只能優(yōu)化算法，或對時序部分單獨特殊處理，不考慮設計模式保執(zhí)行效率?；蛘咴u估階段就選擇性能資源更佳的硬件方案。

異常處理不充分問題

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

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

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

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

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

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