iOS系统卸载应用或断网后VOIP token未失效相关技术问题咨询

你遇到的200响应问题是APNs和FCM的标准设计，和业务逻辑无关：

• APNs返回的200状态仅表示苹果服务器成功接收了你的推送请求、并将推送加入下发队列，不会实时校验目标设备的网络状态、也不会校验对应应用是否仍在设备上安装。只有当token格式错误、和推送证书绑定的bundle ID不匹配这类请求本身有问题的场景，才会在接口响应中返回非200错误。
• FCM静默通知的200返回逻辑同理，仅代表FCM服务器收到请求，不会同步返回终端侧的送达结果。

方案1：实时呼叫可达性校验（优先级最高，可直接解决当前业务需求） #

后端每次收到主叫的呼叫请求、向被叫发起VOIP推送的同时，启动一个3~5秒的超时计时器：

• 被叫端在PushKit的didReceiveIncomingPushWithPayload回调中第一时间向后端发送呼叫接收回执
• 若后端在超时时间内收到回执，正常走呼叫流程；如果超时未收到，直接判定被叫不可达，给主叫返回无法接收呼叫的提示

注意：该方案可以覆盖卸载、断网、系统限制VOIP推送等所有被叫无法接收推送的场景，是目前VOIP应用的通用实现方案。另外iOS要求VOIP推送必须触发CallKit呼起，否则会被系统封禁VOIP推送权限，回执逻辑要放在回调最开始的位置，避免被其他逻辑阻塞导致未触发CallKit。

方案2：定期清理无效token #

• 终端侧每次冷启动应用时，主动将当前最新的VOIP token、FCM token上报给后端，更新对应用户的token和最后活跃时间
• 后端标记超过30天无活跃上报、也无呼叫接收回执的用户token为无效，后续呼叫该类用户直接返回不可达，无需发起推送

方案3：对接平台侧的反馈接口清理无效token #

• 对接苹果官方的APNs Feedback Service，按天定时拉取苹果返回的已确认卸载应用的无效token列表，批量标记后端对应token为失效
• 同步对接FCM的无效token反馈接口，拉取FCM返回的无效token，和VOIP token的失效状态做联动，进一步减少无效推送

内容的提问来源于stack exchange，提问作者Hetali Adhia