從上面的連線裡面找到了一些資料：

如果一開始就對Android手機的硬體架構有一定的瞭解，設計出的應用程式通常不會成為待機電池殺手，而要設計出正確的通訊機制與通訊協議也並不困難。但如果不去了解而盲目設計，可就沒準了。

首先Android手機有兩個處理器，一個叫Application Processor（AP），一個叫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進入休眠狀態。但如果不領會Android設計者的意圖而濫用Wake Lock API，為了自身程式在後臺的正常工作而長時間阻止AP進入休眠狀態，就會成為待機電池殺手。比如前段時間的某應用，比如現在仍然幹著這事的某應用。

首先，完全沒必要擔心AP休眠會導致收不到訊息推送。通訊協議棧運行於BP，一旦收到資料包，BP會將AP喚醒，喚醒的時間足夠AP執行程式碼完成對收到的資料包的處理過程。其它的如Connectivity事件觸發時AP同樣會被喚醒。那麼唯一的問題就是程式如何執行向伺服器傳送心跳包的邏輯。你顯然不能靠AP來做心跳計時。Android提供的Alarm Manager就是來解決這個問題的。Alarm應該是BP計時（或其它某個帶石英鐘的晶片，不太確定，但絕對不是AP），觸發時喚醒AP執行程式程式碼。那麼Wake Lock API有啥用呢？比如心跳包從請求到應答，比如斷線重連重新登陸這些關鍵邏輯的執行過程，就需要Wake Lock來保護。而一旦一個關鍵邏輯執行成功，就應該立即釋放掉Wake Lock了。兩次心跳請求間隔5到10分鐘，基本不會怎麼耗電。除非網路不穩定，頻繁斷線重連，那種情況辦法不多。