android - 在服务器上管理 APNS 和 FCM token

Question

我一直在试图弄清楚如何在我正在编写的设备注册和推送通知服务器上管理 APNS token 。

问题的症结在于通过卸载和应用程序更新唯一地识别设备。甚至供应商的标识符也可以随着安装或更新而改变。似乎苹果和谷歌并不真的希望你能够做到这一点。

似乎有一些解决方法，例如在 iOS 设备上使用钥匙串(keychain)和在 Android 上使用内部存储，但据我了解，这些方法中至少有一种需要用户许可，这可能会拒绝一些用户。我想尊重用户的隐私并与他们建立信任。

这是我到目前为止提出的逻辑:

存储将由 application Id 唯一标识的推送 token , platform , user Id和 device Id (应用程序在本地存储中存储的唯一值) - 我们将此唯一标识符称为 APUD Id

我们将拥有本质上是一个 upsert 端点(尽管我通常讨厌 upsert 或任何通用端点 - 似乎这可能是一个很好的异常(exception)情况)，它更新 token 或其他设备数据并确定是否有一个现有的匹配 APUD Id - 如果是，则更新该行，否则创建一个新行

当向特定用户的设备发送推送通知时，找到所有尚未软删除的匹配条目(当涉及多个服务实例时，硬删除可能更容易避免并发错误，但这是 OT - 理想情况下，我们正在持久化这些数据至少在一段时间内用于支持和调试目的)。由于我们无法唯一标识设备，因此这些通知应使用适当的折叠 ID(应允许设备唯一标识通知)以防止用户接收重复通知。

如果 Apple 或 Google 响应指示 token 已过期/未注册，则软删除该条目。

问题:

第4步可靠吗？有一个更好的方法吗？有没有办法通过 cron 作业主动管理过期的 token ？这会导致大量很少过期的代币堆积吗？

通常有更好甚至规范的方法来解决这个问题吗？

Answer 1

逻辑看起来不错。它与我在一些答案中建议的方法相似(如果不相同)。

Is step 4 reliable? Is there a better way to do this? Is there some way to pro-actively manage expired tokens through a cron job? Will this just result in a massive build-up of tokens that rarely expire?

它是可靠的，它应该防止 token 的积累并防止不必要的推送请求。

Is there generally a better or even canonical way to approach this?

除此之外，我还没有找到更好的方法来处理 FCM token 。

根据您拥有(或可能很快拥有)的任何其他规范，只需确保(尽可能:

每个用户的 token 映射是准确的(通过每个平台的 onTokenRefresh() )

过期的 token 被删除(或在需要时存档，例如调试)