前段時間，接手一個項目，剛開始看了下代碼框架，一點時間片的思想都沒有，有點類似於操作系統樣的，一個事件一個while，這樣導致看到代碼裏面的喂狗處很頻繁，而且代碼重複率很高，整個代碼的耦合度非常之高，改動一處，可能就會影響另一個地方。由於它始終不是一個操作系統調度，而是靠由一堆事件標誌來進行切換，最終還是前後臺輪詢框架，由於接手時，需要增加WIFI功能框架，最開始我想使用時間片調度框架嵌入到裏面，應該是沒什麼問題的，後來發現，隨着功能需求的增加，從而導致這個框架已經不能很好的適用，一方面是越來越冗餘（主要是運行的WIFI運行狀態機加入多條事件後，邏輯變得混亂不清），另一方面，我所用的時間片框架竟然會影響原來的框架（主要是放在中斷裏面的任務調度器），沒辦法，項目變得愈來愈緊急，而測試組一方面提出新的要求，一方面又測試出新的BUG（當然原來的代碼就有許多邏輯BUG），最後我就按照之前在一個事件中構建的一個框架，發現它很兼容或者很適合這種代碼框架，於是我就重整了代碼，摒棄原來寫得框架代碼，也是沒辦法，經過幾番測試後，發現運行良好，且代碼的維護性大大提升，代碼間的耦合也降低了不少，隨後就正式應用新的代碼發佈中，終於項目接近了尾聲，完美的結束。
最近，發現原先的代碼框架很好，但寫法還是有點繁冗，故思之爲之改進，改完後下載測試良好。現貼如下：
其實博客原先也寫了這篇，當時也是最開始記錄了思想，裏面也包含了一點錯誤，遂在此重新寫之。
這份阻塞式框架我覺得應用場合還是比較少，我個人在裸機情況下，還是更熱衷於開放式的時間片調度框架，其代碼耦合度較低。
另外我覺得在接收別人的代碼時，我覺得還是最好先了解一下別人的框架，以及構建一個能夠兼容別人代碼的框架是很重要，要不然的話，爲了填代碼而填代碼，補BUG而補BUG，那將是個非常頭疼的事情。一旦解決框架問題，問題也隨之解決。
