推送相关

blog： https://limkurn.gitbooks.io/limkurn-blog/content/%E7%AC%AC%E4%B9%9D%E7%AB%A0-push.html

前言

在现在主要负责的项目中，推送刚开始使用的是极光推送，不过后面在 app 版本 3.2 左右换到了友盟，同时根据客户端的策略封装一些 api。但是本身没有做什么深究。最近又兼顾着做一个公司的小项目，正好做到推送这块。所以查阅一些资料 blog 整理了下，权当抛砖引玉。

推送平台选择

如果是小公司，貌似没有人想着自己去搭一个推送平台，主要还是用第三方平台。我们主要的项目原来使用极光，不过在我接手项目的时候，这个推送基本上是废的（没有用起来）。后面处于客户端的偏好，以及一些统计方面的需求换到友盟。昨天还接受到甲方需求，看到竞品在使用个推，可能会对接个推。我搜了下 ruby china 上有帖子讨论的，给选择推送平台有一些建议，帮助你去除一些不靠谱的平台。

一些需要知道

ios 推送实现

苹果自身承担了更多，拥有 APNS 服务以及其特殊的后台机制，在实现 ios 端推送的时候，可以自己去看文档封转 api，也可以直接使用第三方封好 (因为集成了第三方 sdk，我们项目是这样的).大致原理图：

(引用自：http://blog.csdn.net/dongdongdongjl/article/details/8452211 可以看看)

android 推送实现

对于 android 的推送，google 也有一个类似于 APNS 的 GCM（google cloud messaging）.但是在国内大家也就懂了。所以就要对安卓特殊处理了。对于安卓推送的实现机制和解决方案可以看看这篇 blog，虽然是 2012 年的貌似并没有过时，其中归纳了常见解决方案的实现原理：

• SMS(Push) 方式

• 轮询 (Pull) 方式

• 持久连接 (Push) 方式

sms 和轮询很容易被 kill 掉，国内推送产品大致的做法是在后台保持一个心跳服务不断维持 Client 与 Server 的 TCP 长连接来实现实时推送，看了下个推的实现原理介绍就是使用的长连接。如果自己实现的话考虑的因素貌似比较多，例如如何保持不被回收，还要打点好一些软件加入白名单中（上次 keep 的全能神大人说有个白名单没处理好，缓存的视频文件就被删除了，虽然与推送无关，但还是得考虑）。还有一个各个 app 用的策略不一样，你开一个，我开一个服务，就会掉电比较厉害，如果体贴用户的话，考虑方案的时候也要考虑下这个。知乎上有个关于关于安卓推送的回答最高票的那个（虽然票不多）蛮有意思可以看看。

关于 device token（安卓以友盟为例）

ios device token

iOS 的 device token 原理可以看看上面一节 ios 推送实现的第二个图，或者查看官方文档，有详细的图文介绍

android device token

安卓使用友盟的时候 使用的是友盟自己的机制（友盟 id 和阿里巴巴集团统一的设备标识库的 id）结合起来 生成友盟对用户的唯一标识（但是没有一种算法能一定保证唯一 只能尽可能保证唯一）,然后：SDK 在初始化的时候向服务器端发起注册请求，由服务器端生成之后颁发给客户端的。

什么时候 device token 改变

• 这是一个很需要注意的东西 后面推送依赖 device token 的时候，自己保存的用户的 device token 要保证有效，如果改变了要及时更新。ios 的我看到小荣的 blog 以及他在帖子中参考的这个这个问题有一些很有用的信息，大致总结：1. 抹除了设备数据 2. 重装应用，3. 时间太长 token 过期 这几种情况 token 发生改变；

• 同样安卓的友盟官方自己给了详细的解释 一般是 设备重载 或者 另一种是没有 SD 卡 设备 id 改变。如果依赖 device token 我能想到的是在登陆和注册的时候带上设备信息以及 device token 信息 server 端保存或者更新用户的设备信息以及保持 device token 是最新有效的。即使重装 app 的时候用户登陆也可以刷新 token 和设备信息便于推送。

两种推送策略（友盟）

我目前之见到过两种策略，如果有什么更好的策略，期望分享下

依赖 device token

依赖 device token 的方案数据库保存用户的设备信息（ios 或 android）还有版本信息 app 以及最新的 device token，这样后面建立任务直接使用保存的 token，按照设备平台调用对应的第三方平台 api。这样的话还可以分平台 分组 分 app 版本分组去推。但是 app 不是设计为单点登陆的话，是否推送到多个设备需要根据业务和需求做对应的支持。如果是单点登陆的话，推送应该可以很好运作了。

依赖 alias 以及 alias type（不确定是不是友盟独有 其他第三方平台文档没看过）

依赖 alias 和 alias type 的方案就比较偷懒，比较适用于只需要 推单个用户 而且保存多设备推送到达的情况 以及全局推，由于没有维护 device token 等设备 版本信息。分组啊 分平台 分版本推送的需求就不能满足，短板还是很明显的。自己的产品就不要采用这种方式了。关于 alias 可以看看这个回答，虽然是百度里的

device token + (alias + alias type)

将两者结合起来的方案 应该比较合适 能支持的功能更多，但是如果在分组推送等用 device token 要保证多设备都要受到推送的话，还是需要在保存用户 device token 的时候 还是需要想想额外的方案来做支持。只保持最新的 device token，只能保证用户推送到用户最近登陆的设备。

后记

经验有限，如果有更多，更好的方案和经验分享的，希望不吝分享。