APNs与微信推送

发表于

APNs介绍

APNs是Apple开发的一种设备消息推送服务(Apple Push Notification service)，自iOS 5开始作为统一的分发服务引入到Apple生态系统。APNs是一套鲁棒而安全的推送服务，因而被微信借鉴使用，并加以改造，成为微信推送的根基。

APNs主要结构如下：

Provider是App应用的提供端，APNs则作为中转的驿站和验证的服务器存在。其他Provider与Client App都是多端存在的(Mutil)。

提供端需要推送的数据有两个部分组成：

  1. Device Token
  2. Payload

Token很容易理解，就是验证双份身份时需要携带的认证讯息；而Payload则是需要推送的主要信息了，它又包括：

  1. 展示给用户的信息
  2. 给App展示的icon徽标(俗称小红点)数量信息
  3. 在设备端发出的声音

当然其中只有1是必需的。

APNs与微信

程可以这里通过APNs分析与微信的对比展示消息推送在微信中的一些使用。

1. 基本流程

APNs推送的基本流程可以参考Apple官方文档，这里借助官网的图来说明一下：

1) Provider -> APNs

应用后台把推送内容发给APNs，这里是通过Device Token来标识不同的接收设备的，需要Client App从APNs申请，并预先注册到后台。如下图：

2) Device -> APNs

用户设备联网后，会保持跟苹果APNs服务器的连接，所有推送都通过这个连接发送到用户设备，系统再根据设置弹出提醒。如下图：

3) Device -> Client App

如果Client App在运行，会收到通知；否则可以点击通知来激活Client App。

这里我们看到，从Device到server使用的是SSL连接，而从Provider到server则使用的是TSL连接，这里其实是很巧妙的设计，SSL是标准化的，再加上Apple本身的密钥协议，保证了只有Apple设备可以认证到APNs服务器，防止了一系列的入侵可能，而TSL则是SSL的前身，虽然非标准化，但差异已经与SSL非常细微，这可以让一些服务供应商在可能的条件下尽可能『多态』的实现他们的通知分发功能，而这些细微的设计又是对用户端隐藏的，保证了整体的一致性要求。