Android休眠对心跳中断带来的影响

Android设备上解决耗电的一个策略就是休眠，手机在锁屏之后一段时间手机就会休眠，那个时候，无论是屏幕,CPU还是其他模块都会停止工作，这样导致了2个问题：

1.一些通讯软件的心跳包中断，导致掉线

2.若采用UDP连接的情况下，服务器过来的数据包不一定实时。

我们来讲讲如何解决以上的两个问题。

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进入休眠状况（iOS、WP7都没这种器材）。若是不懂得Android设计者的意图而滥用Wake Lock API，为了自身代码在后台的正常工作而长时候阻拦AP进入休眠状况，结果就相当严重了，手机的电量就犀利哗啦的被用完了。

如果AP休眠了，手机不是接收不到消息了吗？

完全不用担心，通信协议栈运行于BP，一旦收到数据包，BP会将AP唤醒，唤醒的时间足够AP完成对BP收到协议的处理，但是有一点需要大家注意的是，假如你处理协议包的时间很长的话，那么请加上wakelock，完成之后再释放掉。

如果AP休眠了，程序如何执行向服务器发送心跳包的逻辑

你显然不能靠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唤醒，但是UDP数据包并不会唤醒。

具体的原因可能是因为底层对于TCP长连接的数据过来，会产生AP中断来唤醒AP，但是UDP不会。。。这么做也是有道理的，因为TCP长链接是客户端自身验证过的服务器，也就是数据来源可靠。。。若UDP也会唤醒，那完全可以进行UDP数据包工具，这样一来，被攻击的手机至少耗电量将会大幅度上升。