推送方案

下面是小编为大家整理的推送方案,供大家参考。

　

　推送简介：

　要获取服务器上不定时更新的信息， 一般来说有两种方法：

　第一种是客户端使用 Pull（拉）的方式， 就是隔一段时间就去服务器上获取一下信息， 看是否有更新的信息出现。

　第二种就是服务器使用 Push（推送）

　的方式， 当服务器端有新信息了， 则把最新的信息 Push 到客户端上。

　这样， 客户端就能自动的接收到消息。

　Pull 和 Push 的区别：

　虽然 Pull 和 Push 两种方式都能实现获取服务器端更新信息的功能， 但是明显来说 Push方式比 Pull 方式更优越。

　因为 Pull 方式更费客户端的网络流量， 更主要的是费电量， 还需要我们的程序不停地去监测服务端的变化。

　几种常见的解决方案实现原理：

　1 ）轮询(Pull)方式：

　应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达，你必须自己实现与服务器之间的通信， 例如消息排队等。

　而且你还要考虑轮询的频率， 如果太慢可能导致某些消息的延迟， 如果太快， 则会大量消耗网络带宽和电池。

　2）

　SMS(Push)方式：

　在 Android 平台上， 你可以通过拦截 SMS 消息并且解析消息内容来了解服务器的意图， 并获取其显示内容进行处理。

　这是一个不错的想法， 我就见过采用这个方案的应用程序。

　这个方案的好处是， 可以实现完全的实时操作。

　但是问题是这个方案的成本相对比较高， 我们需要向移动公司缴纳相应的费用。

　我们目前很难找到免费的短消息发送网关来实现这种方案。

　3）

　持久连接(Push)方式：

　这个方案可以解决由轮询带来的性能问题， 但是还是会消耗手机的电池。

　I OS 平台的推送服务之所以工作的很好， 是因为每一台手机仅仅保持一个与服务器之间的连接， 事实上 C2DM 也是这么工作的。

　不过刚才也讲了， 这个方案存在着很多的不足之处， 就是我们很难在手机上实现一个可靠的服务， 目前也无法与 I OS 平台的推送功能相比。

　Android 操作系统允许在低内存情况下杀死系统服务， 所以我们的推送通知服务很有可能就被操作系统 Kill 掉了。

　轮询(Pull)方式和 SMS(Push)方式这两个方案也存在明显的不足。

　至于持久连接(Push)方案也有不足， 不过我们可以通过良好的设计来弥补， 以便于让该方案可以有效的工作。

　毕竟， 我们要知道 GMail， GTalk 以及 GoogleVoice 都可以实现实时更新的。

　采用第三方推送平台极光推送。

推荐访问:推送方案 推送 方案