Android的電源管理

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

4. 在驅(qū)動卸載或不再使用Wake lock時請記住及時的調(diào)用android_uninit_suspend_lock釋放資源.

系統(tǒng)的狀態(tài):

USER_AWAKE, //Full on status

USER_NOTIFICATION, //Early suspended driver but CPU keep on

USER_SLEEP // CPU enter sleep mode

其狀態(tài)切換示意圖如下:

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

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

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

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