移动App的push机制分享

App与服务器的通信无非两种pull、push。后台消息的传递如果没有很强的实时性要求的话，pull还是比较实惠的。但对于实时性要求比较高的就需要用到push了。这篇文章主要分享一下push的流程、应用场景。

相比pull，push无论是在实现复杂度还是在成本上都要高很多。长连接的维持、心跳包的发送、服务器的压力、客户端的消耗、流量的控制都是需要一个个攻克的。笔者也是走在亦步亦趋的路上，分享一下自己的心得，还请多拍砖。

1、长连接流程
长连接是指在客户端和服务器维持一个不断的连接，这样服务器任何时候有消息需要发送的话都可以直接push给客户端。鉴于各个网关的特性，这个连接并不是真的不断，而是即使断了马上重连。
通常，一个长连接是这样开始的：
客户端向服务器发送一个要求keep-alive的连接请求，经过运营商的网关，到达自己的服务器，读取数据完毕后，不要关闭连接。网关为保持自己的瘦身，节省资源，会断掉一段时间内没有数据传递的连接。这个时间各地的网关不同，从1分钟到半小时都可能有。
我们为了让连接不断，就需要隔一段时间向服务器发送一个心跳包，网关看到我们传递数据了，就不会断掉我们的连接。心跳包的发送时间间隔可以动态调用适应当地的网关，达到维持长连接、节省流量、减少耗电的目的。
有这么几个因素可能会影响心跳质量。
A、用户机器休眠：我知道用户长时间不操作机器时，CPU会停掉的，如果我们的心跳时间小于机器休眠的timeout的话，机器就睡不下去了。而电，也很快就没了。
B、心跳包大小：要尽量小，那都是用户的钱。
C、动态适应算法：要在维持长连接满足业务要求的基础上尽量减少断掉重新连接的次数，要知道每次握手都是消耗很大的一件事情。
D、网关timeout：这个瓶颈主要在各地运营商的网关，没有固定的值，需要客户端自适应。

E、我们自己服务器的timeout。服务器端维持长连接不需要像客户端那么多的技巧，只需要CPU、内存、带宽这三大件。但这些也都是钱，还是以满足业务需求为准。另外，两个timeout中最小的那个就是我们维持长连接的心跳时间间隔，所以，服务器的timeout如果大于网关的timeout是完全没有意义的。

2、应用场景
任何一项技术如果脱离了实际的应用场景来讨论是没有意义的，所以在选择技术方案之前，先确定业务需求。如果只是个新闻应用，就不要为了让用户在最短的时间内得到推送而维持一个长连接。相比之下，用户更在乎流量和电量。如果是个IM应用，好友发了消息之后关小时才看到，那用户也会骂娘的。
所以，实时性高、可以让用户无视流量、甘心情愿为了用产品的这个功能而宁愿多充几次电的，push是个好选择。
当然，不要忘记加个提示，再弄个开关，让用户有知情权利和选择的空间。否则，用户可能会用卸载来抗议，那就得不偿失了。