请选择 进入手机版 | 继续访问电脑版

默认
发表评论 6
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
已有的推送框架如何结合APNS
已有推送框架,设计时没有考虑到苹果手机后台不能收到消息的问题,现在想加入使用APNS。
关于加入APNS,我的想法是这样的:
1、推送服务器缓存维护一张映射表,记录用户id与DeviceToken的映射关系;
2、苹果客户端登录后,向推送服务器提供自己的DeviceToken;
3、推送服务器向用户推送消息时,如果用户离线,则先遍历一次映射表,如果有映射关系,则通过apns推送消息;
4、涉及到映射关系变动,比如用户在android手机重新登录,或者用户注销登录时,还需要向推送服务器发起变动通知,删除映射表的映射关系。


以上是我的一点想法,想请教一下大大@JackJiang
1、每条消息都遍历映射表,总感觉资源消耗大,有没有其他更优美的方式?
2、映射关系变动是否还存在漏洞?

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:从0到1的快速裂变:详解快的打车架构设计及技术实践下一篇:扫盲贴:认识MQTT通信协议
推荐方案
评论 6
你可能还没有使用过APNS,好在APNS用起来比想象的要简单多了。

1)关于APNS推送的deviceID问题获取问题:
iOS系统是这样定义的:同一个app在同一台机器上它的deviceToken是不变的,你的APP在ios上登陆时,每次把deviceID带上来就好了,服务端保取即可。

2)APNS机制里的用户离线问题:
其实开发者不用处理APNS的离线问题的,只管有消息,就往这个DeviceID推送就行了,APNS自已会在用户上线后推给它的手机的。这也是APNS相比Andriod推送最爽的地方。APNS只要知道DeviceToken就行了,其它的开发者就不用考虑了,只管推。

3)关于id与DeviceToken的遍历性能问题:
其实,推送系统最大也是唯的的压力在于大量用户心跳包。而消息推送本身,并不会成为瓶颈:一是推送并不会像IM聊天隔一会推一次,可能一周才推一次(多了用户肯定会烦啊),二是推送的内容延迟一点用户根本就不知道,因为他压根就不清楚你啥时候推出来的。
如果真的担心遍历性能的话,在db和应用之间加一层Memcache或redis缓存机制就行了,大的应用都这么玩,不过个人觉得没太大必要,因为我个人认为推送消息本身并不存在啥的压力,慢就慢一点呗,1分钟推完跟10分钟甚至1个小时推完对用户来说没啥区别(除非你把推送当聊天玩)。

4)映射关系是否存在漏洞:
这样的混合推送我们以前产品里做过,你的思路没什么太大问题,动手开工就是了。

签名: 周六又是个加班的日常
引用:JackJiang 发表于 2016-05-17 12:28
你可能还没有使用过APNS,好在APNS用起来比想象的要简单多了。

1)关于APNS推送的deviceID问题获取问题 ...

谢谢。其实我做的不是推送,是IM来的,是我没表达清楚。我们前期只做android,所以对苹果没考虑到,现在要加上去。

按您的意思,不管用户是否在线,直接推过去,这样体验是不是不好?用户正在使用app,本来消息到app就有显示了,还多了一个apns的消息提示。

签名: 该会员没有填写今日想说内容.
你如果是做IM的话,就不能按推送的思路来做。

iOS这端,只有当APP被iOS杀掉时才需要用APNS(系统有回调,可以在回调里通知服务端已离线。或者当服务端检测到客户端离线后自动切换到APNS都可以。),否则消息提醒确实是会重复。
签名: 周六又是个加班的日常
引用:JackJiang 发表于 2016-05-17 13:21
你如果是做IM的话,就不能按推送的思路来做。

iOS这端,只有当APP被iOS杀掉时才需要用APNS(系统有回调 ...

明白了,谢谢
签名: 该会员没有填写今日想说内容.
这样没什么问题,我就是这样做的!不过ios系统中,app开启的话,推送消息是不会提示的吧!
引用:dingshixing@163 发表于 2016-05-20 15:03
这样没什么问题,我就是这样做的!不过ios系统中,app开启的话,推送消息是不会提示的吧!

APP处于前台活着的时候推送APNs推送同样可以收到(是在app的回调里收到的),显示的时候不是从系统的消息机制里出来,而是直接弹出一个对话框的。你可以试一下。
签名: 周六又是个加班的日常
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部