轉自?http://blog.csdn.net/d_clock/article/details/42968039

前段時間，在公司做項目的時候發現原有項目中的代碼在Service中使用handler不斷發送Message到Looper處理MessageQueue中來維持IM功能的“心跳”，心里瞬間覺得這個地方的代碼很不靠譜，主要原因分為兩個：

1.handler的生命周期和Service不一致，如果Service某個時刻被系統回收內存殺死了，邏輯上handler應該就會停止心跳包的發送，但是此時實際代碼運用中handler依舊可以源源不斷的發送消息，而且由于handler持有了外部銷毀的Service的引用，造成Service即使被殺但是內存不被回收的內存泄漏問題也是比較嚴重的；

2.Android官方的API文檔建議我們，如果要執行定時任務的話，可以使用AlarmManager來定期執行任務，減少喚醒系統時鐘的次數，從而減少電量的消耗；

針對以上問題，做了一下小小了解，因為項目開發中我對于AlarmManager的使用已經相當熟悉，但是對系統喚醒鎖的概念還是不是很理解，之前甚至天真的認為，只要鎖了屏，系統鎖就不會被喚醒，亮屏的時候，系統喚醒鎖才重新喚醒。可是想想又不太對，系統在鎖屏的時候，如果我們設置了鬧鐘提醒的功能，時間到了之后，鬧鐘就會響起來，這恰恰說明了鎖屏的時候系統鎖仍舊被喚醒工作，估計系統提供AlarmManager給開發者使用，只是為了讓系統喚醒鎖的次數交給統一的管理者管理，這樣可以降低鎖頻繁被喚醒的幾率，從而達到節能的目的，對此我也對AlarmManager和系統時鐘的概念做了以下一些小小的總結：

Android手機有兩個處理器，一個叫ApplicationProcessor（AP），一個叫BasebandProcessor（BP）。AP是ARM架構的處理器，用于運行Linux+Android系統；BP用于運行實時操作系統（RTOS），通訊協議棧運行于BP的RTOS之上。非通話時間，BP的能耗基本上在5mA左右，而AP只要處于非休眠狀態，能耗至少在50mA以上，執行圖形運算時會更高。另外LCD工作時功耗在100mA左右，WIFI也在100mA左右。一般手機待機時，AP、LCD、WIFI均進入休眠狀態，這時Android中應用程序的代碼也會停止執行。Android為了確保應用程序中關鍵代碼的正確執行，提供了WakeLock的API，使得應用程序有權限通過代碼阻止AP進入休眠狀態。但如果不領會Android設計者的意圖而濫用Wake Lock API，為了自身程序在后臺的正常工作而長時間阻止AP進入休眠狀態，就會成為待機電池殺手。

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

總結

以上是生活随笔為你收集整理的AlarmManager机制和系统唤醒锁的总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。