這兩天又接到一個Bug:大家都抱怨待機喚醒的速度太慢。首先我們假定應用程序沒有這么大的功力來影響系統，主要從驅動方面入手。當然主要是要找出是哪個模塊在待機和喚醒時比較慢，有以前編譯PM模塊的經驗這個問題變得很簡單：在PM調用SetDevicePower設置各驅動的電源狀態時計算一下實際花了多少時間。經統計發現NLED和AUDIO驅動都比較慢，花費300ms以上，而且AUDIO驅動在進D3和D4狀態時都各花了300ms。
經過與模塊的維護者討論發現AUDIO驅動在待機時會先暫停Media player，并等待300ms以確保Media player停止。而且比較致命的是它在進D3和D4時都做了這個事情，這個很好解決，先去掉延時，由此造成的問題用其它方法解決。
而NLED驅動因為進D4狀態時LED可能還在閃爍，所以要給負責閃爍的線程一個信號，然后等待線程停止，以保證待機時LED是不亮的。因為負責閃爍的線程有好幾次Sleep，所以進D4時使用了Sleep 300ms來保證進入D4狀態時負責閃爍的線程已經停止。而這嚴重影響了系統的待機時間。現在將Sleep改成有限時間的WaitForSingleObject，這樣進入D4時直接設置事件，就可以激活線程，從而不需要花費太多的時間來等待線程停止。
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
