那为什么要有心跳包呢? 其实主要是为了防止上面提到的NAT超时， 既然一些NAT设备判断是否淘汰NAT映射的依据是一定时间没有数据， 那么客户端主动发一个数据.
　　当然， 如果仅仅是为了防止NAT超时， 可以让服务器来发送心跳包给客户端， 不过这样做有个弊病是， 万一连接断了， 服务器再也联系不上客户端了. 所以心跳包必须由客户端发送， 客户端发现连接断了， 还可以尝试重连服务器.
　　所以心跳包的主要作用是防止NAT超时， 其次是探测连接是否断开.
　　链路断开， 没有写操作的TCP连接是感知不到的， 除非这个时候发送数据给服务器， 造成写超时， 否则TCP连接不会知道断开了. 主动kill掉一方的进程， 另一方会关闭TCP连接， 是系统代进程给服务器发的FIN. TCP连接是这样， 只有明确的收到对方发来的关闭连接的消息(收到RST也会关闭， 大家都懂)， 或者自己意识到发生了写超时， 否则它认为连接还存在.
　　心跳包的时间间隔
　　既然心跳包的主要作用是防止NAT超时， 那么这个间隔大有文章了.
　　发送心跳包势必要先唤醒设备， 然后才能发送， 如果唤醒设备过于频繁， 或者直接导致设备无法休眠， 会大量消耗电量， 而且移动网络下进行网络通信， 比在wifi下耗电得多. 所以这个心跳包的时间间隔应该尽量的长， 理想的情况是根本没有NAT超时， 比如刚才我说的两台在同一个wifi下的电脑， 完全不需要心跳包. 这也是网上常说的长连接， 慢心跳.
　　现实是残酷的， 根据网上的一些说法， 中移动2/3G下， NAT超时时间为5分钟， 中国电信3G则大于28分钟， 理想的情况下， 客户端应当以略小于NAT超时时间的间隔来发送心跳包.
　　wifi下， NAT超时时间都会比较长， 据说宽带的网关一般没有空闲释放机制， GCM有些时候在wifi下的心跳比在移动网络下的心跳要快， 可能是因为wifi下联网通信耗费的电量比移动网络下小.
　　关于如何让心跳间隔逼近NAT超时的间隔， 同时自动适应NAT超时间隔的变化， 可以参看Android微信智能心跳方案.
　　心跳包和轮询的区别
　　心跳包和轮询看起来类似， 都是客户端主动联系服务器， 但是区别很大.
　　轮询是为了获取数据， 而心跳是为了保活TCP连接.
　　轮询得越频繁， 获取数据越及时， 心跳的频繁与否和数据是否及时没有直接关系
　　轮询比心跳能耗更高， 因为一次轮询需要经过TCP三次握手， 四次挥手， 单次心跳不需要建立和拆除TCP连接.
　　TCP唤醒Android
　　这部分内容我只知道结论， 不知道具体的知识
　　大家有没有想过， 手机的短信功能和微信的功能差不多， 为什么微信会比短信耗电这么多? 当然不是因为短信一条0.1元. 手机短信是通过什么获取推送的呢?
　　下面这段出处不明的话也许可以给大家启示
　　首先Android手机有两个处理器， 一个叫Application Processor(AP)， 一个叫Baseband Processor(BP). AP是ARM架构的处理器，用于运行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分钟， 基本不会怎么耗电. 除非网络不稳定. 频繁断线重连， 那种情况办法不多.
　　上面所说的通信协议， 我猜应该是无线资源控制协议(Radio Resource Control)， RRC应该工作在OSI参考模型中的第三层网络层， 而TCP， UDP工作在第四层传输层， 上文说的BP， 应该是手机中的基带， 也有叫Radio的， 我有点搞不清楚Radio怎么翻译. Google在Optimizing Downloads for Efficient Network Access中提到了一个叫Radio State Machine的东西， 我翻译成无线电波状态机， 也不知道正确的翻译是什么.
　　移动网络下， 每一个TCP连接底层都应该是有RRC连接， 而RRC连接会唤醒基带， 基带会唤醒CPU处理TCP数据， 这是我个人的理解.
　　至于wifi下如何工作， 我暂时没有找到资料.
　　上面说了这么多， 其实意思是TCP数据包能唤醒手机. 至于UDP， 我不确定.
　　而推送中重要的部分是让手机尽量休眠， 只有在服务器需要它处理数据时才唤醒它， 这正好符合我们的要求.