为了让我们向用户发送iOS通知，会发生以下流程：用户安装我们的应用程序，向APNS注册，并将注册令牌发送到我们的服务器，以便稍后用于发送通知。
对于用户安装我们的应用程序的每个设备，重复上述过程;我们希望他们在所有设备上收到通知。
除此之外，当用户卸载我们的应用程序并在同一设备上重新安装时，将重复此过程。
每次重复这个过程，我们都会获得一个新的，独特的注册令牌。这一切都很好，但是，我们注意到，只有在最近卸载我们的应用程序时，设备令牌在重新安装并生成新令牌后仍然有效。我们的理解是，设备可以存在单个唯一令牌。
令牌信任的这一阶段的形式确保只有APN生成它稍后才会尊重的令牌，并且它可以确保设备传递给它的令牌与之前为该特定设备配置的令牌相同。 - 仅适用于该设备。
当重新安装并发送到我们的后端后生成新令牌时，我们有两个指向同一设备的设备令牌，因此我们会向该设备发送多个通知。我们是否误解了文档？如果是这样，处理重新安装方案的典型方法是什么？
谢谢！
答案 0 :(得分：9)
我们刚刚在这里做了一个测试。在我们的iOS 8.4.1测试设备上重新安装我们的应用程序后，我们收到了相同的令牌，而在iOS 9.1上，我们总是在重新安装后收到一个新令牌。如果APNS使旧设备令牌无效，这不会是一个问题，但据我所知，它不会。结果是我们向用户发送重复通知到同一设备。可能需要一些时间才能使旧令牌无效？
我们决定对此进行服务器端修复，并从我们的数据库中删除一个用户的重复令牌。这不是一个好的和永久的解决方案，但对我们来说是一个短期的解决方案，因为我们的用户通常只在一台设备上使用该应用程序。
答案 1 :(得分：1)
是的，我看到一个设备具有相同的应用程序（我的应用程序），在其短暂的生命周期内已经发布了不同的APNS，其中许多仍然能够接收推送通知（来自生产APNS服务器）。
简单的解决方法是让我们的后端APNS发送服务仅仅接受最后收到的APNS令牌。这是可行的，假设有另一个主键，每个iOS设备都是唯一的。好吧，由于UUID不再可用，我们必须依赖Apple供应商ID。 Apple供应商ID存在的问题是该值也会随着时间的推移而发生变化，因此请务必考虑到这一点。
我们目前只向具有我们唯一成员/用户ID的设备发送推送通知。一旦用户登录我们的应用程序，我们的应用程序就会知道这一点。因此，我们可以使用我们的成员/用户ID，但是如果成员/用户有多个设备，这意味着如果我们使用最后一个APNS令牌值作为获胜者，那么同一个成员不能让多个iOS设备接收推送通知（想想iPad和iPhone，这些日子很常见）。
因此，正如所说的那样，当高层管理人员想要向没有唯一成员/用户实际登录的设备发送推送通知时，存在流被越过的风险。
答案 2 :(得分：1)
我们遇到了同样的问题，我们为1台设备找到了2个有效的设备令牌。 但是，当我们尝试验证“卸载并重新安装会生成新的设备令牌，并且以前的设备令牌仍然有效”时，我们得到了相反的结果。 即，生成了新设备令牌，但前一设备令牌无效。 我在2016年3月9日和2016年3月3日验证了这一点。
不确定Apple是否已修复此部分
的错误。a）从现在开始卸载并重新安装应用程序时，旧的deviceToken将变为无效。 （没有新问题）
b）当前有效的设备令牌将继续有效。 （旧问题无法修复，设备仍将从每个有效设备令牌接收多个通知）
看起来我们必须使用“identifierForVendor”来区分一个独特的设备：如果我们看到2个deviceTokens共享相同的identifierForVendor，则清理我们的注册表（并保留最新的deviceToken）。
答案 3 :(得分：0)
“每次重复这个过程，我们都会获得一个新的，独特的注册令牌”。
你确定吗？ 100％肯定？
根据我的经验，如果您卸载应用程序，然后重新安装它，然后99.99％的时间您将获得相同的设备令牌。如果您每次卸载并重新安装应用程序时都会获得一个新的唯一设备令牌，那么这是我多年来从未见过的和多个应用程序。因此可能会发生一些奇怪的事情。
有些情况下会生成新的设备令牌，但很少见，您确定在卸载/重新安装之间没有做其他事情吗？
P.S。生产构建和发布构建有一个不同的设备令牌，从您的观察中消除这个因素 - 即确保您没有做像安装prod构建，然后卸载它并重新安装开发构建，反之亦然。即使您这样做，唯一开发令牌的总数仍然只有两个（尽管每个环境只有一个有效）。