前言
　　近研究Android推送的实现， 研究了两天一夜， 有了一点收获， 写下来既为了分享， 也为了吐槽. 需要说明的是有些东西偏底层硬件和通信行业， 我对这些一窍不通， 只能说说自己的理解.
　　为什么要研究Android推送技术? 主要还是毕业设计要做一个即时通信app， 我是不喜欢做什么社交app的， 也象牙塔里的人想得出来， 说实话有这功夫还不如钻研一个小技术点， 把一个点研究透彻， 比搞个大而全， 还无用的东西好得多， 不过谁叫咱们是普通人， 没得选呢.
　　Android推送服务的几种实现方式
　　现实生活中， 推送服务像订杂志一样， 只要留下你的地址， 杂志能如期送到你手里， 可以认为每个人都有的一个地址， 但在目前的网络上， 这是办不到的， 因为不是每个人都有一个的地址， 服务器想要给我们推送一条消息， 必须知道我们的地址， 但服务器不知道我们在哪.
　　说到推送服务， 我所知道的实现方案有如下几种:
　　轮询
　　客户端定期询问服务器有没有新的消息， 这样服务器不用管客户端的地址是什么， 客户端来问， 直接告诉它行.
　　这种方案简单， 对于一些不追求实时性的客户端来说， 很适合， 只需要把时间间隔设定成几个小时取一次， 能很方便的解决问题.
　　但对于即时通讯产品来说， 这种方案完全不能用. 假设即时通讯软件在网络畅通的情况下发送的消息要求对方10s内能收到， 如果用轮询， 那么客户端要每隔5s连一次服务器， 如果在移动端， 手机的电量和流量很快会被消耗殆尽.
　　SMS通知
　　这种方案在移动端是有可能的， 让客户端拦截手机短信， 服务器在有新消息时给用户的手机号发一条特殊的短信， 客户端拦截短信后发现是正常短信放行， 如果是特殊短信连接服务器取消息.
　　运营商不会配合， 用户也不会放心， 这方案普通公司玩不起.
　　长连接
　　这大概是目前情况下佳的方案了， 客户端主动和服务器建立TCP长连接之后， 客户端定期向服务器发送心跳包， 有消息的时候， 服务器直接通过这个已经建立好的TCP连接通知客户端.
　　XMPP， MQTT等不算推送技术
　　在网上搜索资料的时候， 经常看见XMPP协议实现的Android推送和MQTT协议实现的Android推送， 我个人觉得这两种说法都怪怪的， XMPP和MQTT二者都是协议， 尽管我不清楚严格来讲这俩协议工作在哪一层， 但是是在传输层之上的， 姑且认为他俩在TCP/IP五层模型的应用层吧， 闭口不提传输层的实现， 而是扯应用层， 这种说法真是令我费解， 所以我个人认为XMPP， MQTT等等不算推送技术.
　　关于这个XMPP， 我想很多人都是参考Openfire和Smack那套东西， 我一年前尝试用aSmack和Openfire做IM， 不过那个时候什么都不懂， 做的东西很烂， 懂的是Openfire这东西相当老了， 我看有一些开源的推送解决方案都是在这套东西的基础上改的， 想想这工作量， 挺可怕的.
　　细说TCP长连接与心跳
　　长连接方案乍一听怪怪的， 什么是长连接? 定时发送心跳， 这和轮询有什么区别? 心跳是干什么的? 同样是定期和服务器沟通， 为什么长连接比轮询更加? 手机休眠了TCP连接不会断掉吗?
　　这是我在刚开始研究推送技术的时候的问题， 虽然有些还是没有很准确的答案， 但了解的大概可以分享一下， 有什么错误欢迎指出.
　　什么是长连接
　　先说短连接， 短连接是通讯双方有数据交互时建立一个连接， 数据发送完成后，则断开此连接.


　　persistent connection

　　长连接是大家建立连接之后， 不主动断开. 双方互相发送数据， 发完了也不主动断开连接， 之后有需要发送的数据继续通过这个连接发送.
　　TCP连接在默认的情况下是所谓的长连接， 也是说连接双方都不主动关闭连接， 这个连接应该一直存在.
　　但是网络中的情况是复杂的， 这个连接可能会被切断. 比如客户端到服务器的链路因为故障断了， 或者服务器宕机了， 或者是你家网线被人剪了， 这些都是一些莫名其妙的导致连接被切断的因素， 还有几种比较特殊的:
　　NAT超时
　　因为IPv4地址不足， 或者我们想通过无线路由器上网， 我们的设备可能会处在一个NAT设备的后面， 生活中常见的NAT设备是家用路由器.
　　NAT设备会在IP封包通过设备时修改源/目的IP地址. 对于家用路由器来说， 使用的是网络地址端口转换(NAPT)， 它不仅改IP， 还修改TCP和UDP协议的端口号， 这样能让内网中的设备共用同一个外网IP. 举个例子， NAPT维护一个类似下表的NAT表
　　       内网地址                 外网地址
　　192.168.0.2:5566 120.132.92.21:9200
　　192.168.0.3:7788 120.132.92.21:9201
　　192.168.0.3:8888 120.132.92.21:9202
　　NAT设备会根据NAT表对出去和进来的数据做修改， 比如将192.168.0.3:8888发出去的封包改成120.132.92.21:9202， 外部认为他们是在和120.132.92.21:9202通信. 同时NAT设备会将120.132.92.21:9202收到的封包的IP和端口改成192.168.0.3:8888， 再发给内网的主机， 这样内部和外部能双向通信了， 但如果其中192.168.0.3:8888 == 120.132.92.21:9202这一映射因为某些原因被NAT设备淘汰了， 那么外部设备无法直接与192.168.0.3:8888通信了.
　　我们的设备经常是处在NAT设备的后面， 比如在大学里的校园网， 查一下自己分配到的IP， 其实是内网IP， 表明我们在NAT设备后面， 如果我们在寝室再接个路由器， 那么我们发出的数据包会多经过一次NAT.
　　国内移动无线网络运营商在链路上一段时间内没有数据通讯后， 会淘汰NAT表中的对应项， 造成链路中断.
　　网络状态切换
　　手机网络和WIFI网络切换， 网络断开和连上等情况， 也会使长连接断开. 这里原因可能比较多， 但结果无非是IP变了， 或者被系统通知连接断了.
　　DHCP的租期
　　目前测试发现安卓系统对DHCP的处理有Bug， DHCP租期到了不会主动续约并且会继续使用过期IP， 这个问题会造成TCP长连接偶然的断连.
　　引自Android微信智能心跳方案
　　心跳包的作用
　　网上很多文章介绍长连接的时候都说:
　　因为是长连接， 所以需要定期发送心跳包.
　　心跳包是用来通知服务器客户端当前状态.
　　提出这些说法的人其实自己也是一知半解. 这些说法其实都对， 但是没有答到点上. 好像别人问: “你为什么要去食堂”? 这人回答: “检查自己还能不能找到食堂”. 这个答案说不上错了， 但是其实这人是去食堂吃饭的， 证明自己认得路只是个附赠品.
　　明确一点， TCP长连接本质上不需要心跳包来维持， 大家可以试一试， 让两台电脑连上同一个wifi， 然后让其中一台做服务器， 另一台用一个普通的没有设置KeepAlive的Socket连上服务器， 只要两台电脑别断网， 路由器也别断电， DHCP正常续租， 这么放着， 过几个小时再用其中一台电脑通过之前建立的TCP连接给另一台发消息， 另一台肯定能收到.