APNs介绍
APNs是Apple开发的一种设备消息推送服务(Apple Push Notification service),自iOS 5开始作为统一的分发服务引入到Apple生态系统。APNs是一套鲁棒而安全的推送服务,因而被微信借鉴使用,并加以改造,成为微信推送的根基。
APNs主要结构如下:
Provider是App应用的提供端,APNs则作为中转的驿站和验证的服务器存在。其他Provider与Client App都是多端存在的(Mutil)。
提供端需要推送的数据有两个部分组成:
- Device Token
- Payload
Token很容易理解,就是验证双份身份时需要携带的认证讯息;而Payload则是需要推送的主要信息了,它又包括:
- 展示给用户的信息
- 给App展示的icon徽标(俗称小红点)数量信息
- 在设备端发出的声音
当然其中只有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非常细微,这可以让一些服务供应商在可能的条件下尽可能『多态』的实现他们的通知分发功能,而这些细微的设计又是对用户端隐藏的,保证了整体的一致性要求。