产品小姐姐：我们的产品形态导致我们有很多操作类的用户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 放在自定义的用户数据中，什么花样就都可以玩了
代码：只贴关键部分
发送正常逻辑时：
发送撤回逻辑时：
文档：苹果官方文档
