原文地址：http://blog.csdn.net/a774057695/article/details/47024887
本文系作者原创，转载请附加原文地址，谢谢。
概述：
实现“推送”可以有多种方式，但是有这样一点是毋庸置疑的：移动端和服务器建立了联系，数据从服务器发往移动端。
而且这种联系应当是移动端主导的，若由提供者主导，唯一能想到的方法就是使用SMS。那么我们可以看一下实现“推送”方法了。
推送三大方法：
SMS服务
轮询法
长时间连接法
注：这是编者对“推送”方法的命名，在网络中看到的资料会和此处有或多或少的区别，但这种命名体现了方法的特点
1. SMS服务：
a) 实现方法概述：
服务器向注册手机（或者说注册用户绑定的手机账号）发送彩信，手机收到彩信后会被蓝海彤翔公司的应用所创建的service截获，并解析得到信息，并产生任务栏通知，以及适当的提示，如：震动、短铃声、呼吸灯等等
b) 优点：省电，这纯粹就是对用户的优点。然而对公司而言就没有优点。
c) 缺点：烧钱！烧钱！烧钱！大量的彩信业务费用，对面的移动公司才会考虑这种方式。
d) 总结：可忽略的方法。
2. 轮询法：
a) 实现方法概述：
移动端程序建立长时间service（级别较高，在内存不足进行清理时不被优先清理），该service会定时或者每隔一定时间就向服务器发起连接并“询问”（典型的http通信）是否有推送消息，如果有，则下载，断开连接并处理……，没有则断开该次连接。
b) 优点：相对SMS而言，公司的开销会小很多，原理和实现难度亦较低。
c) 缺点：于用户而言，消耗流量，对公司的服务器也有一定的压力
d) 总结：可接受的方法，但并不优秀，亦可以形象的称为“pull”
3. 长时间连接法
a) 实现方法概述：
移动端程序建立长时间service，该service与服务器建立长时间的TCP/IP连接，此时就不能使用http通信了，需要使用socket通信，服务器真正的将消息推送给移动端……
b) 优点：相对轮询法更节省流量
c) 缺点：实现难度相对较高，依赖稳定的网络环境，耗电，服务器压力
d) 总结：iOS的推送（APNs）和google的推送均以该思路为主，iOS在底层为应用提供了这种服务，管理做得很好，google的服务器……中国人都懂的，所以国内一些大公司推出了这类服务。
小结：
从上面的分析来看，长时间连接法是最为优秀的，轮询法是较容易实现的，SMS服务是不值得考虑的。
值得考虑的是：长时间连接法如何应对网络状况不佳的情况，如下事项应对考虑：
1. 如何界定网络情况不佳
2. 断开连接后是否永远尝试立即重连
3. 断开连接后是否进行试探性连接，一定时间内进入休眠状态，一段时间后再执行唤醒
继而引发出如下思考：
1. Socket通信时及时的，如果移动端在网络连接中断情况下未能接收到信息，是否不应当错过该信息
2. 若不应当错过，应当采用何种处理方法实现消息“滞留”网络中
3. 若不应当错过，移动端如何获取这些信息
以下是我对这些问题的一些看法，但是还未进行验证
界定网络情况不佳：
我们要检测的不是网速，而是连接是否稳定，所以当连接断开时，进行重连同时执行方法，该方法实现计时，在规定的计时内连接断开次数达到阈值，则界定网络状况不佳。
我们需要注意的是：阈值与计时适配、重连次数不应当过多。
断开连接后是否永远立即尝试重连：
结合上一条内容，我们可以进行立即重连，但不应当永远处于一种连接尝试中。那样的设计显得无聊、不优雅，这也是第一条思考的铺垫。
断开连接后是否进行试探性连接，一定时间内进入休眠状态，一段时间后再执行唤醒
这正是我想推荐的做法，推送信息只是一件锦上添花的事情，我们没有必要急切的让用户第一时间就收到信息。这种试探性连接便是界定网络状况的过程，然而此时设计的界定方法离优雅还差的很远，应当得到优化。
Socket通信时及时的，如果移动端在网络连接中断情况下未能接收到信息，是否不应当错过该信息
虽然是锦上添花，我们还是不希望该条信息被错过的，哪怕是收到的晚了一点。但也不应当接受过早时候的消息了，一般而言1-2d为佳。
若不应当错过，应当采用何种处理方法实现消息“滞留”网络中
这里的滞留不是真正的滞留，结合上一条，我们可以在服务器端将这一段时间内的消息进行唯一性标识（例如md5码），并将其一同发送，不过这样造成的流量开销会变大，可以考虑这样的格式：[总数]+[本条的md5码]+[本条时间点]+[本条内容]，移动端接收到之后分析总数（最好使用存储方式，不要过分依靠变量，并不保险）若有遗漏，请求发送这些md5码然后比对找出遗漏的，再请求重新发送。
移动端在接收到push信息时应当更新数据，考虑到补充发送的，我们应适当修改格式：[是否为补充发送]+[总数]+[本条md5码]+[本条时间点]+[本条内容]
补充发送的数据：只添加本条记录，总数不起作用，注意本条时间点是服务商发送该推送消息的时间点，不是收到或者补发的时间点。
非补充：更新本条数据，删除过期数据，比对总数！
如何接受已经涵盖在上一条中。
具体实现尚未进行，其实现将会在之后的文章中进行剖析。
转载请附地址：http://blog.csdn.net/a774057695/article/details/47024887 谢谢！