AlarmManager机制和系统唤醒锁的总结

转自 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分钟，基本不会怎么耗电。除非网络不稳定，频繁断线重连，那种情况办法不多。