对于App开发者来说，接入推送通知功能时，除了对于推送的到达率、稳定性和并发能力进行考量外，还要考虑SDK的兼容性、流量的消耗、耗电量以及SDK包的体积等因素，特别是耗电量，非常影响用户对于移动设备的正常使用，所以如何尽可能地降低耗电量呢？

Android手机有两个处理器，一个是Application Processor(AP)基于ARM处理器，主要运行Android系统；一个是BaseBand Processor(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分钟, 基本不会怎么耗电.

关于推送服务技术，想要了解更多也可以咨询极光。

极光推送官方链接：https://www.jiguang.cn/push