Android的電源管理

3. 如果是auto expire的wake lock則可以忽略,不然則必須及時的把相關的wake lock釋放掉,否則會造成系統長期運行在高功耗的狀態.

4. 在驅動卸載或不再使用Wake lock時請記住及時的調用android_uninit_suspend_lock釋放資源.

系統的狀態:

USER_AWAKE, //Full on status

USER_NOTIFICATION, //Early suspended driver but CPU keep on

USER_SLEEP // CPU enter sleep mode

其狀態切換示意圖如下:

系統正常開機后進入到AWAKE狀態, Backlight會從最亮慢慢調節到用戶設定的亮度,系統screen off timer(settings->sound display-> Display settings -> Screen timeout)開始計時,在計時時間到之前,如果有任何的activity事件發生,如Touch click, keyboard pressed等事件, 則將Reset screen off timer, 系統保持在AWAKE狀態. 如果有應用程序在這段時間內申請了Full wake lock,那么系統也將保持在AWAKE狀態, 除非用戶按下power key. 在AWAKE狀態下如果電池電量低或者是用AC供電screen off timer時間到并且選中Keep screen on while pluged in選項,backlight會被強制調節到DIM的狀態.

如果Screen off timer時間到并且沒有Full wake lock或者用戶按了power key,那么系統狀態將被切換到NOTIFICATION,并且調用所有已經注冊的g_early_suspend_handlers函數, 通常會把LCD和Backlight驅動注冊成early suspend類型,如有需要也可以把別的驅動注冊成early suspend,這樣就會在第一階段被關閉. 接下來系統會判斷是否有partial wake lock acquired, 如果有則等待其釋放, 在等待的過程中如果有user activity事件發生,系統則馬上回到AWAKE狀態;如果沒有partial wake lock acquired, 則系統會馬上調用函數pm_suspend關閉其它相關的驅動, 讓CPU進入休眠狀態.

系統在Sleep狀態時如果檢測到任何一個Wakeup source, 則CPU會從Sleep狀態被喚醒,并且調用相關的驅動的resume函數,接下來馬上調用前期注冊的early suspend驅動的resume函數,最后系統狀態回到AWAKE狀態.這里有個問題就是所有注冊過early suspend的函數在進Suspend的第一階段被調用可以理解,但是在resume的時候, Linux會先調用所有驅動的resume函數,而此時再調用前期注冊的early suspend驅動的resume函數有什么意義呢?個人覺得android的這個early suspend和late resume函數應該結合Linux下面的suspend和resume一起使用,而不是單獨的使用一個隊列來進行管理.

由于本人對Android研究的時間還不長,也許其中有些地方理解不正確, 甚至是錯誤的, 請大家諒解. 如果大家發現有疑問的地方,有興趣也可以一起來討論.