這兩天又接到一個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元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
