推送流程

整个推送过程涉及以下4个主体：

主体	说明
PNS	推送服务器（Push Notification Server），即本系统
Sender	集成了推送服务的第三方应用服务器，发起推送的主体
Receiver	移动设备推送后台服务，接收发送到该设备的所有消息，并广播给所有App
App	集成了推送服务的客户端应用，接收推送消息的主体

设备注册流程

1. App启动时判断系统中是否已有Receiver在运行，已存在则跳到3，否则继续
2. App启动一个独立的Receiver后台服务进程，以便实现推送功能
3. Receiver判断是否该设备已向PNS注册过，已注册则跳到步骤6，否则继续
4. Receiver向PNS提交appkey（由App提供）并申请注册该移动设备，参见【平台接口定义/设备注册接口】

   这里是为设备进行注册，而非为当前App注册，设备注册后可为设备上的所有App提供推送服务

   如果设备上已经有其它App注册了该设备，则当前App不再进行注册，而是直接使用已注册到的账号

   问题：如何有效地保存账号信息？即使发起注册的App被删除后，仍旧能保证账号信息可用

5. PNS验证了appkey的合法性后自动分配一个新的账号及随机密码返回给Receiver

   自动分配账号信息可能导致一个设备被分配多个账号，比如刷ROM等操作导致账号信息的丢失从而进行了重新注册

   如果定期清理僵尸账号，如何保证长久时间未联网的设备再次联网时（账号已被清理）所有App还能正确获取到推送消息？

   可以考虑在每次进行设备注册之后发一次系统级的通知，让所有使用了推送服务的App重新走一次下面的Token申请流程

6. Receiver使用PNS分配的账号登录PNS，登录成功后告知App

推送Token获取流程

1. App检查是否已申请过推送Token，已申请则跳到4，否则继续
2. App向PNS发送appkey、账号和密码并申请获取推送Token，参见【平台接口定义/获取推送Token接口】
3. PNS验证合法性后随机分配一个Token返回给App

   Token是为App而非设备服务的，设备上的每个使用推送服务的App都会被分配一个不同的Token

   PNS需要维护账号、appkey与Token之间的关系，即一个账号对应多个Token，每个Token对应一个appkey

4. App将分配的Token告知Sender

   该环节由App和Sender自己处理，Sender保存下Token以便日后发送推送用

推送流程

1. Sender提取出推送Token并连同appkey、推送信息一起发送到PNS，参见【平台接口定义/消息推送接口】
2. PNS验证appkey和Token的合法性并提取出相对应的Receiver账号
3. PNS通过Receiver账号将消息连同token信息推送到对应的Receiver
4. Receiver在系统内广播接收到的token和消息内容
5. 所有集成了推送服务的App被唤醒并检查该消息是否发给自己的（对比token）。若不是，则执行完检查后退出；若是则处理推送内容