个推推送的技术原理

传统互联网上数据交互一般有poll和push两种方式。poll典型使用场景是浏览网页，是用户主动发起请求，向服务器获取数据；push刚好相反，通过服务器直接发送数据给客户端，用户被动接受消息，类似于更加及时的短信。Push的使用场景有以下两特点：时间不确定性、时效性，如发送团购信息，发送电子消费账单等。

个推为第三方应用提供了跨手机平台一致的、稳定可靠的消息推送服务，实现服务端到客户端的消息主动推送。第三方应用可以实现针对单一目标地址的推送，也可以实现群发消息推送，还可以通过指定tag进行定向群组推送。个推除了为第三方提供基本的透明消息传输，还提供了一些消息展示方式，实现在客户端的通知提示、弹框操作等，帮助客户快速实现更为定制化的消息推送服务。

个推目前支持Android、iOS手机平台。

技术原理

首先我们来看一下组成一个推送系统的几个要素

1.个推SDK：

以jar的方式出现，集成于第三方客户端，解析第三方下行的数据，并把结果透传给第三方客户端；也可以上行第三方定制的客户端信息。

2.个推服务器：

一侧负责维护与成千上万的个推SDK的长时连接，另一侧与第三方服务器对接，将第三方定制数据下行推送至个推SDK。

3.第三方服务器：

数据推送的发起者，通过对接个推服务器，将数据发送至第三方客户端。

4.第三方客户端：

第三方集成个推SDK的客户端，推送数据正真的接收者和展现者。

以上是个推推送系统中的四个不同角色，看起来比较抽象，可以通过以下图片来加强理解：

说明：

AppID：应用ID，第三方在个推系统注册帐号并创建生成的唯一的应用标识。

ClientID：用于标识客户端身份，由第三方客户端获取并保存到第三方服务端。

UID：一般为第三方系统帐号体系中的用户标识。第三方服务端一般需要保存UID和ClientID的映射关系，进行消息推送时，通过UID查找到相应的ClientID，便可进行定向推送了。

我们用一个更加形象的方式来描述一下这个系统：淘宝购物相信很多人都体验过，就拿它举个例子。

淘宝卖家——第三方服务器

淘宝买家——第三方客户端

快递公司（比如顺风）——个推服务器

集淘宝买家中的地址管理、快递查收、包裹检验等一系列工作的集合——个推SDK（这个有点不形象，但是大概理解意思就好）。

假设淘宝买家下了一单，首先需要填写寄件地址（假设不用默认的），这个相当于个推SDK根据客户端的信息，建立了一条通道（快递配送地址）。

当买家付款成功后，卖家需要发货（第三方服务端要推送数据），当然先叫快递公司拿件（把推送数据发送给个推服务器），快递公司根据包裹上的地址（第三方客户端的身份信息，就是上面所说的ClientID）将包裹（数据）寄送到买家（第三方客户端），买家收货后，先验收一下货物是否有损坏（数据是否符合定制要求），获取到包裹内容（获得服务端推送的数据），并签单验收（个推SDK反馈数据发送成功）。

与上面的例子相对应，我们再描述一遍整个推送过程的技术流程：

1.第三方客户端集成个推SDK。

2.第三方客户端启动的时候，调用SDK接口，启动推送服务，SDK后台运行并维护和个推服务端的长连接，实现SDK注册和登录。

3.第三方服务端调用个推服务器的接口，将要发送的数据通过个推服务器发送到指定身份的个推SDK当中。

4.个推SDK解析定制数据，并且把第三方服务器透传的数据发送给第三方客户端，第三方客户端根据服务器的数据做出相应的动作或者展现。