产品小姐姐：我们的产品形态导致我们有很多操作类的用户Notification, 但是我想吧过期的用户没有点击的push给撤销掉，来提升用户体验，这个...能不能做？

看在小姐姐漂亮的份上 这个活我接了。

开弄。。。。。

这事总的来说流程很简单，ps: 其实 每个Notification 都是一条消息，那么就必然是有消息ID的。

问题的关键就是 NotificationId的传递

    一. 服务端 查阅 APNS的官方文档，查到在服务端发起请求时可以在heder中增加一些字段，

        1. apns-id，这个其实就是消息的ID，如果不传会默认生成。此字段采用UUID的规则，如果不是apns会生成新的替换不合规的

        2.apns-collapse-id ，这个字段管的是消息折叠（分组），客户端收到相同apns-collapse-id时 会将前面一个替换掉。适合的场景 比如：关注类通知，设置成相同的apns-collapse-id，则客户端针对"xx关注了你" 即使收到了10W条也会只显示一条，提升用户体验

    二. IOS客户端 在收到Notification时直接调用API拿到notificationId, 这里这个id就跟上面两个服务端传的ID有关系了， 上面的apns-id 和 apns-collapse-id 这两个是二选一，就是说 如果设置了 apns-collapse-id 则客户端取到的notificationId就是apns-collapse-id，如果没设置apns-collapse-id 则是apns-id的值。

正常流程：

服务端调用apns API发送一个通知Notification,客户端收到后展示push, 用户点击Notification 打开app，对应Notification 消失。

想撤销（隐藏）Notification时：

服务端调用apns API发送一个撤销通知Notification（透传方式），将上一步的apns-id或者apns-collapse-id带过去,客户端收到后拿到notificationId 调用删除方法（removeDeliveredNotifications(notificationId)）吧Notification删掉消失，但是吧 通过透传的方式 我们还要做别的任务。为了后面的扩展性，可选择 将 apns-id或者apns-collapse-id 放在自定义的用户数据中，什么花样就都可以玩了

代码：只贴关键部分

发送正常逻辑时：

发送撤回逻辑时：

文档：苹果官方文档