推送技术的实现通常会使用服务端向客户端推送消息的方式。也就是说客户端通过用户名、Key等ID注册到服务端后，在服务端就可以将消息向所有活动的客户端发送。
实际上，在很多移动操作系统中，官方都为其提供了推送方案，例如，Google的云推送、IOS、Windows Phone7/8也都提供了类似的推送方案。不过这些推送方案的服务器都在国外，有一些推送服务（如Google的云推送）在国内由于某些原因不太稳定，所以国内近几年涌现出了很多专门为国人打造的推送服务。
本文将从各种流行移动操作系统入手介绍推送技术的各种实现方式。当然，我们的主要目的是讨论Android的推送技术。
一、iOS的推送技术
Apple为IOS提供了很完美的推送方案，其基本原理是Apple提供了自己的推送服务器，叫APNS（Apple Push Notification Service，苹果推送通知服务器）。而客户端设备（IPhone、IPad等）直接与APNS建立长连接。不过向客户端设备发送的消息并不是由APNS产生的，而是在需要发送消息的用户自己提供的服务器（称为Provider）中产生的，然后Provider将消息传送给APNS，最后由APNS将消息传送给客户端设备。也就是说，消息最开始由Provider产生，然后Provider将消息传送给APNS，最后再由APNS传送给客户端设备。消息传递的过程如图1所示。
图1
在发送消息到客户端设备接收到消息的过程中，始终伴随这一个令牌的传送（device token）。要想使用APNS提供消息服务，应用程序需要先向IOS注册需要提供的一个必要的信息就是与当前设备有关的device token，IOS在接收到devicetoken后，会向APNS查询这个device token是否在APNS上注册了（所有的IOS设备在第一次使用时都需要向苹果服务器注册一个账号，否则无法从AppleStore下载应用，当然更无法使用推送服务了），如果已经注册，APNS会直接向应用程序返回这个devicetoken。应用程序获得这个devicetoken后，表示APNS已经允许向自己推送消息了，接着还需要将该device token发送给推送服务器（Provider）。到这里应用程序已经成功将自己注册到APNS中了。现在就可以通过Provider产生要推送的消息，然后Provider会将消息发送给APNS服务器，最后APNS服务器会直接向应用程序发送消息。这个过程比较复杂，不过看一下图2的描述就会对这一过程更加了解了。每一个流程描述前面的数字表示发送的时间先后顺序。
图2
二、Windows Phone的推送技术
微软为Window Phone提供的推送方案与IOS类似，也需要自己准备推送服务器（可以称为Cloud Service）。只是表示设备的ID变成了Uri。在Window Phone中有一个Push Client Service（PCS）。所有需要推送服务的应用程序都需要与Push Client Service通信。下面是Window Phone推送的基本步骤，读者可以与图3对照来看这一过程。
第1步：应用程序会向Push Client Service请求一个Push Notification URI（①）。
第2步：如果当前Window Phone设备已经在微软服务器注册了，Push Client Service会从MPNS（Microsoft Push Notification Service ，微软推送通知服务）获取Push Notification URI，并返回给应用程序，表示推送服务可用（②和③）。
第3步：应用程序需要将Push Notification URI发送给自己的推送服务器（Cloud Service）（④）。
第4步：如果需要推送消息，Cloud Service会将消息发送到MPNS，然后MPNS会将消息发送给Push Client Service，最后由Push Client Service将消息传送给应用程序（⑤、⑥和③）。
图3
三、Android的推送方案
Android的推送方案就比较多了，也比较乱。例如，有Google官方提供的C2DM（Android Cloud to Device Messaging）；第三方的推送服务（如极光推送）；还有通过各种协议实现的推送服务端程序（如AndroidPN），用户通过这些服务端程序可以搭建自己的推送服务器。这些推送技术会在本节后面的部分详细介绍，本节先来介绍一下Android中经常使用的各种推送技术。当然，这些推送技术也能用于其它的移动设备，但由于Android的官方推送服务（C2DM）在国内使用上有一些问题，所以基于Android的第三方推送服务较其它系统多，因此这里主要针对Android来介绍。
通常推送技术会使用如下两种方式实现。
1. 轮询（Pull）方式
2. 持久连接方式（服务端Push方式）
轮询方式就是客户端以一定的时间间隔不断查询服务端是否有新的消息。这种方式必须自己实现与服务器之间的通信机制，例如消息队列等。而且还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。所以大多数推送服务都不会使用轮询方式。
持久连接方式也就是Push方式，对于客户端来说，是一种被动的方式，而主动权在服务端，当有消息时，服务端会向所有注册到推送服务器的客户端推送消息。这种推送方式的好处是可以保证实时性，而且客户端实现简单。当然，也会有不足，例如，如果大量的客户端与服务端保持长连接时，会消耗服务器的资源。不过在未推送消息时，这些长连接就成了空闲连接，通常这种连接主要消耗的是内存资源。例如，200万用户可能会消耗数十GB的内存。因此搭建这种推送机制时要使用性能好的服务器。
持久连接的实现有很多方式，例如，可以使用XMPP作为通信协议。XMPP的主要优势是协议成熟、强大，可扩展性强。XMPP更多地用于IM系统中，后面要介绍的AndroidPN也是用了XMPP协议。
XMPP也有明显的缺点，例如，协议很复杂，如果吃透XMPP协议可能需要很长时间，还有就是由于XMPP是基于XML的，从而造成了数据冗余、这样会造成移动设备费流量、耗电等弊病。
除了XMPP，还可以使用MQTT协议，这种协议的主要优势是简洁、小巧、可扩展性强，从而带来了省流量、省电等优点，而且有C++版的服务端组件rsmb。缺点是协议不够成熟，而且实现较复杂，而且rsmb不开源，部署硬件的成本较高。
尽管C2DM服务在国内可能不太稳定或有一些地区不可用，但还是有必要介绍一下C2DM的原理。不过对于在国内使用的应用最好使用第三方的推送服务，或自己假设推送服务器。
C2DM和IOS的APNS以及Window Phone的MPNS大同小异。还需要自己准备一台推送服务器，并通过如下步骤实现消息的推送。
第1步：移动设备上的C2DM服务需要与Google官方的C2DM服务器交互，验证当前设备是否在C2DM服务器上注册了，如果已经注册，C2DM服务器会返回一个注册ID给客户端的C2DM服务。（①和②）
第2步：客户端的C2DM服务会与自己的推送服务器交互，将账号和C2DM服务器返回的注册ID传给推送服务器。（③）
第3步：如果要推送消息，推送服务器会将注册ID和要推送的消息先发送到C2DM服务器，然后C2DM服务器会直接将消息推送给客户端（手机、平板电脑的设备）（④和⑤）。
读者可以对照图4来理解这3个步骤。
图4
除了使用官方的推送方案外，现在国内涌现出多个第三方的推送方案，例如，极光推送（JPush）、百度推送等。读者也可以用一下，这些同时通常是免费的（可能推送多媒体数据需要收费）。
