你可能还没有使用过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）映射关系是否存在漏洞：
这样的混合推送我们以前产品里做过，你的思路没什么太大问题，动手开工就是了。

你如果是做IM的话，就不能按推送的思路来做。

iOS这端，只有当APP被iOS杀掉时才需要用APNS（系统有回调，可以在回调里通知服务端已离线。或者当服务端检测到客户端离线后自动切换到APNS都可以。），否则消息提醒确实是会重复。

引用：dingshixing@163 发表于 2016-05-20 15:03
这样没什么问题，我就是这样做的！不过ios系统中，app开启的话，推送消息是不会提示的吧！

APP处于前台活着的时候推送APNs推送同样可以收到（是在app的回调里收到的），显示的时候不是从系统的消息机制里出来，而是直接弹出一个对话框的。你可以试一下。