移动推送方案的初步探索

前言

进入移动互联网时代以来，大部分厂商需要通过移动推送的方式来向用户推送各种消息和通知（比如优惠活动等），来增加和用户的粘度。本文主要针对移动推送，来总结一下自己最近的学习经验。
最早起源于Email的推送，进入到移动端领域，则主要侧重于移动客户端。而客户端来获取服务端的数据，主要有两种方式：

• 第一种是客户端 PULL（拉）方式，即每隔一段时间去服务器获取是否有数据；
  • 优点：简单；
  • 缺点：实时性较差。
    我们也可以通过提高查询频率来提高实时性，但这又会造电量、流量的消耗过高。
• 第二种是服务端 PUSH（推）方式，服务器在有数据的时候主动发给客户端，该方式基于 TCP 长连接方式实现。
  • 优点：消息实时性好；
  • 缺点：要保持 APP 客户端和服务端的长连接心跳，会带来额外的电量和流量消耗；

一句话总结

因此在整体架构设计中需要折中平衡，目前主流的推送实现方式都是基于 PUSH 的方案。

移动推送的三种方式

目前，移动推送主要有三种实现方式，其中PULL一种，PUSH两种,具体如下文：

轮询（）PULL）

客户端和服务端定期建立连接，通过异步消息队列来查询服务端是否有新的数据。但是，这种方式的最大的问题是不好控制查询的频率：

• 频率过低数据更新不及时；
• 频率过高则会加快资源的消耗（电量和流量等）。

短信推送 （SMS PUSH）

该方式借助运营商的短消息，通过短信形式来向用户推送消息，优点突出：能够最好的保证消息的实时性；但是，缺点同样不容忽视：采取该方式，会根据发送消息的条数支付相应的费用，成本较高。