本文總結(jié)下狀態(tài)機編程的優(yōu)點。

提高CPU使用效率

話說我只要見到滿篇都是delay_ms()的程序就會頭疼，動輒十幾個ms幾十個ms的軟件延時是對CPU資源的巨大浪費，寶貴的CPU時間都浪費在了NOP指令上。那種為了等待一個管腳電平跳變或者一個串口數(shù)據(jù)，讓整個程序都不動的情況也讓我非常糾結(jié)，如果事件一直不發(fā)生電平跳變，你要等到世界末日么？關于CPU的理解。

如果應用狀態(tài)機編程思想，程序只需要用全局變量記錄下工作狀態(tài)，就可以轉(zhuǎn)頭去干別的工作了，當然忙完那些活兒之后要再看看工作狀態(tài)有沒有變化。只要目標事件(定時未到、電平?jīng)]跳變、串口數(shù)據(jù)沒收完)還沒發(fā)生，工作狀態(tài)就不會改變，程序就一直重復著“查詢—干別的—查詢—干別的”這樣的循環(huán)，這樣CPU就閑不下來了。

這種處理方法的實質(zhì)就是在程序等待事件的過程中間隔性地插入一些有意義的工作，好讓CPU不是一直無謂地等待。

邏輯完備性

邏輯完備性是狀態(tài)機編程最大的優(yōu)點。

不知道大家有沒有用C語言寫過計算器的小程序，我很早以前寫過，寫出來一測試，那個慘不忍睹啊！當我規(guī)規(guī)矩矩的輸入算式的時候，程序可以得到正確的計算結(jié)果，但要是故意輸入數(shù)字和運算符號的隨意組合，程序總是得出莫名其妙的結(jié)果。

后來我試著思維模擬一下程序的工作過程，正確的算式思路清晰，流程順暢，可要碰上了不規(guī)矩的式子，走著走著我就暈菜了，那么多的標志位，那么多的變量，變來變?nèi)?，最后直接分析不下去了?/p>

很久之后我認識了狀態(tài)機，才恍然明白，當時的程序是有邏輯漏洞的。如果把這個計算器程序當做是一個反應式系統(tǒng)，那么一個數(shù)字或者運算符就可以看做一個事件，一個算式就是一組事件組合。對于一個邏輯完備的反應式系統(tǒng)，不管什么樣的事件組合，系統(tǒng)都能正確處理事件，而且系統(tǒng)自身的工作狀態(tài)也一直處在可知可控的狀態(tài)中。反過來，如果一個系統(tǒng)的邏輯功能不完備，在某些特定事件組合的驅(qū)動下，系統(tǒng)就會進入一個不可知不可控的狀態(tài)，與設計者的意圖相悖。

狀態(tài)機就能解決邏輯完備性的問題。

狀態(tài)機是一種以系統(tǒng)狀態(tài)為中心，以事件為變量的設計方法，它專注于各個狀態(tài)的特點以及狀態(tài)之間相互轉(zhuǎn)換的關系。狀態(tài)的轉(zhuǎn)換恰恰是事件引起的，那么在研究某個具體狀態(tài)的時候，我們自然而然地會考慮任何一個事件對這個狀態(tài)有什么樣的影響。這樣，每一個狀態(tài)中發(fā)生的每一個事件都會在我們的考慮之中，也就不會留下邏輯漏洞。

這樣說也許大家會覺得太空洞，實踐出真知，某天如果你真的要設計一個邏輯復雜的程序，會覺得狀態(tài)機真香！

程序結(jié)構清晰

用狀態(tài)機寫出來的程序的結(jié)構是非常清晰的。

程序員最痛苦的事兒莫過于讀別人寫的代碼。關于文檔、注釋的重要性以及如何去寫。

如果代碼不是很規(guī)范，而且手里還沒有流程圖，讀代碼會讓人暈了又暈，只有順著程序一遍又一遍的看，很多遍之后才能隱約地明白程序大體的工作過程。有流程圖會好一點，但是如果程序比較大，流程圖也不會畫得多詳細，很多細節(jié)上的過程還是要從代碼中理解。

相比之下，用狀態(tài)機寫的程序要好很多，拿一張標準的UML狀態(tài)轉(zhuǎn)換圖，再配上一些簡明的文字說明，程序中的各個要素一覽無余。程序中有哪些狀態(tài)，會發(fā)生哪些事件，狀態(tài)機如何響應，響應之后跳轉(zhuǎn)到哪個狀態(tài)，這些都十分明朗，甚至許多動作細節(jié)都能從狀態(tài)轉(zhuǎn)換圖中找到?？梢院敛豢鋸埖恼f，有了UML狀態(tài)轉(zhuǎn)換圖，程序流程圖寫都不用寫。

審核編輯：陳陳