因此，考虑当 APP 在后台时，针对 iOS 平台的消息不再进行重发；只有当 APP 进入前台，才重新进行重发。APP 的活动状态通过第三方推送服务的 api 可以获取到。

　　Android 平台不存在该问题。

　　由于消息重发可能会造成客户端收到重复消息，需要在客户端进行消息去重。服务端为每一条消息分配了一个唯一 id，重发时唯一 id 不变。客户端需要保存收到的每一条消息，在接收到新消息时首先根据唯一 id 判断是否已经收到了这条消息，如收到则不响应。客户端保存消息可以采用 sqlite 数据库。

　　安全和控制

　　客户端 SDK 与服务端的通信过程使用 appKey 和 appSecret 进行权限控制。appKey 是服务端为每个 app 分配的唯一标识，appSecret 是服务端为每个 app 分配的秘钥。

　　客户端 SDK 在请求服务端 HTTP 接口时，会将 appKey+appSecret 做一次签名，将签名值作为签名 sign 参数，与其他请求参数（业务参数 +appKey）一同传到服务端；服务端拿到请求参数后，也先用 appKey+appSecret 做一次签名，比较和客户端传来的 sign 参数是否一致，从而完成权限验证过程。为了能够实现灵活控制推送与否，可实现黑名单管理的功能。处于黑名单内的 app 客户端不再进行消息的推送。黑名单控制的粒度到账号级别，也可以根据实际业务需要进行分组管理。

　　在某些业务场景中，需要对消息进行过滤，分析，做出相应的处理甚至预警，借助于消息推送平台，都能方便的实现。

　　SDK 设计

　　客户端 SDK 是基于推送服务的 SDK 封装实现，对外提供统一的使用接口。SDK 的使用者不再关注具体使用了哪些第三方推送、推送服务的接入细节。实现与推送服务的充分解耦，降低开发和使用成本。

　　由于 iOS 和 Android 平台的差异性，在客户端 SDK 的封装上存在差异，下面分别介绍两个平台的 SDK 封装方式。

　　iOS 平台

　　SDK 提供启动和停止的方法；同时定义一个 protocol，包含 SDK 提供的接口。SDK 在收到消息或出现错误时将会回调 protocol 中的接口。

　　由于推送的接入涉及 AppDelegate 的生命周期方法，为避免 SDK 使用者关注这些繁琐的细节，SDK 使用 Aspects 的方式，将推送时相应的处理函数 hook 到 AppDelegate 的生命周期方法上。

　　Android 平台

　　在 Android 中使用 Receiver 组件来接收收到的消息。一个基本的配置如下所示：

　　流程如下：当推送服务的 SDK 在接收到推送过来的消息后，将发送广播，这个广播的用 intent-filter 标识，当应用中的 Receiver 代码注册了这个 intent-filter，就可以接收到广播，并进行后续处理。

　　系统管理

　　图 5：后台管理示意图

　　消息后台管理系统提供应用申请、应用服务配置、推送服务配置、消息查询与管理等功能。

　　1、应用申请

　　填写应用名、应用描述等信息后，生成该应用唯一的 appKey 和 appSecret。

　　2、应用服务配置

　　为应用选择要使用的移动端通用服务，可供选择的有推送、反馈、版本发布。

　　3、推送服务配置

　　为应用配置推送服务，可供选择个推、极光等；以及推送时使用的优先级顺序。

　　4、消息查询与管理

　　查看应用所发出的消息，包括消息所属应用、所属账号、消息的状态、最终发送成功的第三方渠道、消息的来源、发送者 ip 等信息

　　5、数据统计

　　通过分析 message 表中的各消息的状态，可统计各应用消息的发送成功率和到达率，以及哪个第三方推送的更优，方便选择。同时，提供每日、每周、每月推送消息量的统计，并提供统计图表。

　　高可用、高性能、高稳定性

　　消息推送平台通过无状态设计、统一存储、冗余部署方式保证了高可用，对应的状态数据统一存储到 MySQL、Redis 中保证各个无状态实例共享数据。

　　对于消息的接收处理我们通过纯异步、动态多线程的方式提供了推送平台的高性能。同时对于异步接收的消息我们通过 log append 的方式保证消息先落地然后再进行处理，进一步确保系统在异常过程中我们可以随时恢复消息，保证不丢失。