已有的推送框架如何结合APNS

已有推送框架，设计时没有考虑到苹果手机后台不能收到消息的问题，现在想加入使用APNS。
关于加入APNS，我的想法是这样的：
1、推送服务器缓存维护一张映射表，记录用户id与DeviceToken的映射关系；
2、苹果客户端登录后，向推送服务器提供自己的DeviceToken；
3、推送服务器向用户推送消息时，如果用户离线，则先遍历一次映射表，如果有映射关系，则通过apns推送消息；
4、涉及到映射关系变动，比如用户在android手机重新登录，或者用户注销登录时，还需要向推送服务器发起变动通知，删除映射表的映射关系。


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

你可能还没有使用过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的回调里收到的），显示的时候不是从系统的消息机制里出来，而是直接弹出一个对话框的。你可以试一下。