android裝置上解決耗電的乙個策略就是休眠，手機在鎖屏之後一段時間手機就會休眠，那個時候，無論是螢幕,cpu還是其他模組都會停止工作，這樣導致了2個問題：
1.一些通訊軟體的心跳包中斷，導致掉線
2.若採用udp連線的情況下，伺服器過來的資料報不一定實時。
android手機有兩個處理器
baseband processor（bp）。
ap是arm架構的處理處理器，用於執行linux+android體系；
bp用於執行及時操縱體系（rtos），通訊協議棧執行於bp的rtos之上。非通話時候，bp的能耗基本在5ma以下，而ap只要處於非休眠狀況，能耗至少在50ma以上，履行圖形運算時會更高。別的lcd工作時功耗在100ma左右，wifi也在100ma左右。一般手機待機時，ap、lcd、wifi均進入休眠狀況，這時android中應用法度的**也會停止執行。
android為了確保一些關鍵**的正確執行，供給了wake lock的api，使得應用有許可權經由過程**阻攔ap進入休眠狀況（ios、wp7都沒這種器材）。若是不懂得android設計者的意圖而濫用wake lock api，為了自身**在後台的正常工作而長時候阻攔ap進入休眠狀況，結果就相當嚴重了，手機的電量就犀利嘩啦的被用完了。
完全不用擔心，通訊協議棧執行於bp，一旦收到資料報，bp會將ap喚醒，喚醒的時間足夠ap完成對bp收到協議的處理，但是有一點需要大家注意的是，假如你處理協議包的時間很長的話，那麼**上wakelock，完成之後再釋放掉。
你顯然不能靠ap來做心跳計時. android提供的alarm manager就是來解決這個問題的. alarm應該是bp計時(或其它某個帶石英鐘的晶元，不太確定，但絕對不是ap), 觸發時喚醒ap執行程式**.
那麼wake lock api有啥用呢? 比如心跳包從請求到應答, 比如斷線重連重新登陸這些關鍵邏輯的執行過程, 就需要wake lock來保護. 而一旦乙個關鍵邏輯執行成功, 就應該立即釋放掉wake lock了. 兩次心跳請求間隔5到10分鐘, 基本不會怎麼耗電. 除非網路不穩定. 頻繁斷線重連, 那種情況辦法不多.
上面所說的通訊協議, 我猜應該是無線資源控制協議(radio resource control), rrc應該工作在osi參考模型中的第三層網路層, 而tcp, udp工作在第四層傳輸層, 上文說的bp, 應該就是手機中的基帶, 也有叫radio的,
google在optimizing downloads for efficient network access 中提到了乙個叫radio state machine的東西
具體的原因可能是因為底層對於tcp長連線的資料過來，會產生ap中斷來喚醒ap，但是udp不會。。。這麼做也是有道理的，因為tcp長鏈結是客戶端自身驗證過的伺服器，也就是資料**可靠。。。若udp也會喚醒，那完全可以進行udp資料報工具，這樣一來，被攻擊的手機至少耗電量將會大幅度上公升。
為什麼中斷不能休眠
1.中斷處理的時候,不應該發生程序切換,因為在中斷context中,唯一能打斷當前中斷handler的只有更高優先順序的中斷,它不會被程序打斷 這點對 於softirq,tasklet也一樣,因此這些bottom half也不能休眠 如果在中斷context中休眠,則沒有辦法喚醒它,因為所有的 wa...
為什麼中斷不能休眠
1.中斷處理的時候,不應該發生程序切換,因為在中斷context中,唯一能打斷當前中斷handler的只有更高優先順序的中斷,它不會被程序打斷 這點對 於softirq,tasklet也一樣,因此這些bottom half也不能休眠 如果在中斷context中休眠,則沒有辦法喚醒它,因為所有的 wa...
Android設定系統休眠
可以通過以下方法進行系統休眠時間的獲取，設定休眠時間，喚醒螢幕等 測試環境android5.1 設定休眠時間 param millisecond param context public static void setscreensleeptime int millisecond,context c...