這是我的車載車牌辨識軟體執行畫面！之前的辨識頻率大概是20Hz出頭，近一兩年我的辨識核心效能越來越好，辨識速度變快了，所以辨識頻率已經常常可以達到30Hz了！在街上開車邊跑邊辨識時的車速約時速四五十公里，攝影機畫面中出現的車牌幾乎都是一閃即逝，辨識速度永遠都是嫌不夠快的！所以我的這種軟體設計時是無辨識速度上限的！電腦能跑多快就讓它盡情奔馳！

但是近來有客戶說程式執行約半小時後不時會有忽然閃退的狀況？這可是一件大事！通常上街尋車一次都要跑數小時，這種狀況是一定會讓使用者困擾，也大傷我的產品形象的！所以我花了不少時間研究測試事故發生的原因，一開始是以為辨識核心內有BUG，因為近期確實新增了不少新程式，但是仔細體檢程式碼，也反覆長時間隨機測試都沒有發現任何BUG。

於是將注意力放在系統執行壓力的狀況，我的這種動態程式必須高頻率的拷貝螢幕取得單張影像做辨識，這是一個必須經過作業系統的硬體動作，寫程式偶爾拷貝一兩張影像是絕對不會出錯的！但是長時間每秒拷貝數十次連續數十分鐘甚至數小時呢？我的經驗就是會容易出現隨機的錯誤！這跟程式邏輯無關的！如果程式錯誤每次執行都會錯的！

所以我的消極的處理是發現這種錯誤時程式會加以忽略，少一兩張影像不辨識不會影響每秒數十張的資料流太大的，但是讓程式因此整個當掉當然就不行了！一般來說，大約數分鐘或數十分鐘總會出現這種隨機錯誤的！我的LOG檔案也都會記錄事發時間，但通常不會嚴重到讓程式當掉或閃退！

但只是如此處理，似乎還是無法完全釋放系統在記憶體或其他資源方面的壓力！所以當機之前LOG紀錄上會顯示螢幕腦拷貝錯誤的頻率會慢慢增加，最後會連續密集發生，即使只是忽略錯誤也無法釋放系統累積的壓力，程式最終就不堪壓力而崩潰閃退了！

所以處理方式大概就是每次發現不穩定時要讓程式休眠一個短時間，大約數十毫秒吧？讓作業系統來得及處理額外的壓力，或是直接寫程式釋放已經不需使用的記憶體等等。甚至如果主迴圈真的卡死了，還必須有內部程式機制讓軟體不必經過使用者手動操作就能自行重新啟動！

這次的問題也就是我的壓力釋放機制已經跟不上辨識速度的增加頻率，應該算是甜蜜的負擔吧？當然就是多做測試調整！讓迴圈保持不要累積太大壓力，目前狀況已經不會當機了！待會尖峰時刻我會用路口監視器的即時畫面作壓力測試，如果過關這次的維護修理工作就算完成了！