在移动互联网时代，为了运营好一个APP，消息推送是一个优质廉价的渠道。消息推送的使用场景简单来说，可以包括运营类的消息推送，如活动推广期间的推送等，还包括通知类的消息推送，如社交场景中的新消息提醒等。 对于APP来说，消息推送能够起到内容告知、提高日活，甚至召回用户的作用。那么如何接入第三方推送平台呢？本篇文章中，网易云信资深研发工程师将和大家聊聊接入各种第三方推送平台的技术方案，分享接入推送平台的一些实用经验。 如何接入第三方推送
- 推送的一般流程
推送是一种服务器主动push消息到设备端的行为，因此依赖于设备端和服务器的长连接。整体的架构和流程如下：
具体如下：
- 设备和推送服务器建立长连接
- 设备会根据某些规则生成或从推送服务器获取到一个DeviceToken，推送服务器可以根据DeviceToken定位到具体的设备
- 设备会上报DeviceToken到应用服务器（由应用自己完成）
- 应用服务器根据需要调用推送的服务端接口发起推送
- 推送服务器收到推送请求，根据请求中的DeviceToken定位到具体的设备，下发推送通知
- 设备收到推送消息，可以进行通知栏弹窗或者其他行为
- IOS
苹果官方提供了APNS推送，有很高的推送送达率。早先的APNS推送提供了一套基于TCP协议的接口，但是该接口使用方式比较复杂，稍有不慎就会导致推送失败，但调用方还误以为推送成功。 后来苹果又提供了一套新的基于HTTP2协议的接口，新接口的一个好处是可以追踪到每个推送请求是被APNS服务器拒绝了还是成功了，再也不用去猜请求到底是被苹果服务器给丢了还是接受了。
- 安卓
谷歌官方最早提供了GCM推送，后来又推出了FCM推送来代替GCM，但由于国内的环境不适合使用，因此各个手机厂商又相继推出了各自的推送，推送的原理都是类似的，都是依赖于设备和推送服务器的长连接，但是厂商推送的优势在于这样的长连接可以和自己的手机系统绑定到一起，从而可以不同应用共享同一条长连接，节省了心跳的流量消耗，并且这样的系统级长连接可以不用担心应用被杀导致的应用内长连接断连导致消息推送不可达。 目前已经推出厂商推送的包括小米、华为、魅族、OPPO等，FCM也可以算安装了谷歌服务的设备的系统级推送。 不同于IOS，安卓阵营的推送服务器接口都是HTTPS接口，并且通过SecretKey的方式来进行安全校验。 一点经验
- DeviceToken的管理
我们知道DeviceToken标识了一台具体的设备，但是推送服务本身是不知道应用本身的账号体系的，因此同一个APP，假设注销了A账号，改用B账号登录，此时DeviceToken一般来说是没有变化的，此时应用服务器需要去标识A账号的该设备属于注销状态，不然一条针对A账号的推送消息就会被B账号收到。
- 应用被卸载的情况
应用被卸载的时候（这时候登录的A账号），应用本身感知不到，此时针对A账号的该设备的推送还是会发出去，推送服务器收到推送消息，找不到对应的设备，此时没有问题，只是会消耗一些资源。假设此时设备上的应用又重新安装了，然后登录了另一个账号B，假设DeviceToken没有变化，此时针对A账号的推送将会被B账号收到。上面这种情况出现的前提条件是DeviceToken没有发生变化，测试发现华为推送存在这个问题（经过询问华为推送技术支持，2018年3月之后的设备不存在该问题），其他推送没有。为了解决这个问题，服务器必须自己管理DeviceToken-用户账号的映射关系，并在发现有DeviceToken冲突的情况下去把老的账号设置为注销状态。
- IM场景下推送时机问题
IM场景下，应用服务器有自己长连接服务，此时第三方推送服务的作用是利用第三方厂商推送的系统级长连接来提高消息推送的送达率。 首先对于IOS端，应用无法常驻后台，我们会在应用切换前后台的时候通过IM长连接发送一个标记位，服务器会在设备离线或者处于后台的情况下触发APNS推送，从而减少设备在前台情况下APNS推送的流量消耗。 而对于安卓端，服务器会在设备处于离线的情况下触发第三方推送，否则会走IM长连接下发通知，当设备处于后台但还活着的时候，会在收到消息之后主动弹窗以便提醒用户有新消息。对于安卓端还有一个场景是这样的，安卓端在后台的某个时刻进程死了，此时过来一条需要推送的消息，服务器发现设备处于离线状态，尝试调用第三方推送（可能有也可能没有）。过了一会进程自己活回来了，重新连接到了IM服务器，拿到了未读消息，此时一般的逻辑下，进程会主动弹窗告知有消息到达，造成设备端的通知栏有两条推送。为了解决这个问题，需要IM服务器在设备重连的时候下发未读消息是否需要弹窗的信息。