云服务 推送相关的一些整理

limkurn · 2016年07月26日 · 最后由 Winter_is_coming 回复于 2019年04月24日 · 3317 次阅读

推送相关

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,只能保证用户推送到用户最近登陆的设备。

后记

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

不好意思 在测试 @beyondouyuan #a 🍭

最近使用推送,发现 Mob 的 MobPush 推送挺不错的,免费的,还有智能标签推送,小公司其实可以考虑 Mobpush,遇到问题还可以通过 Mob 的官网 QQ 联系他们的技术支持。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号