我知道当推送通知到达设备（并且应用程序没有打开它）时，没有办法检查（我可能是错的）。但是在我的应用程序中有一个这样的情况，必须知道通知已经到达设备 我在应用程序中有多个选项卡，其中2个具有徽章实现，具体取决于推送通知。所以基本上有两种不同类型的推送通知。
假设一种类型的通知到达设备并且用户选择不看通知。这样，特定标签的徽章计数将递增1 。但问题是，哪一个。因为当时我打开应用程序，我没有收到通知类型已到达的信息。或者确切地说，要增加哪个标签徽章计数。 简而言之，我怎么知道，通知已经到达设备（未收到）？
答案 0 :(得分：1)
您可以通过使用推送通知的后台获取模式来解决此问题。将您的特殊徽章编号存储到某种持久存储（可能是用户默认值），并在打开应用程序时使用该值。
对于后台提取，请查看以下问题： Will iOS launch my app into the background if it was force-quit by the user?
但是，请注意，用户可以选择退出后台提取。
答案 1 :(得分：1)
所以基本上，总结其他人所说的，你将有两个用户案例。但在您需要在有效载荷中指定哪个徽章必须增加之前（如@Andrew建议的那样）。 以下是用户案例：
didReceiveRemoteNotification。在这种情况下，这意味着应用程序处于后台或前台，或通过点击通知启动。您将必须实现您的逻辑来处理这种情况。只需解析通知的有效负载（在json中）并确定应增加哪个徽章。didReceiveRemoteNotification。在这种情况下，用户已杀死您的应用，或者设备已关闭，或者用户已为您的应用阻止了获取后台功能。要处理这种情况，您在应用程序和服务器上也需要更多逻辑。
您可以做的是在服务器端存储已发送的所有待处理通知。一旦用户设备上的应用程序收到 AND 解析通知（didReceiveRemoteNotification被调用），您就会向服务器发出新呼叫，要求从待处理数据库中删除该通知。最后，实施对您的服务器的调用，在您的应用启动时询问所有待处理的通知，以便在您的应用程序被杀或设备关闭的情况下，当用户再次打开应用程序时，他将收到所有通知他错过。您还可以在服务器上设置一个计时器，每隔x天/小时再次发送通知（实际上并不建议，您不希望用户删除您的应用，因为您向他发送垃圾邮件）。正如其他人所说的那样，相信您的服务器上的数字应该显示在徽章中的方式比通知本身更好。上面的逻辑用于我最近工作的类似Tinder的应用程序，以显示用户有多少匹配;）
答案 2 :(得分：1)
无法使用公共API获取此信息。
来自Local and Remote Notifications Programming Guide：
让我们回顾一下系统可能出现的情况 为应用程序提供本地通知或远程通知。
当应用未在中运行时，会发送通知 前景。在这种情况下，系统会显示通知， 显示警报，标记图标，可能播放声音，以及 也许会显示一个或多个动作按钮供用户点击。
用户点按iOS 8通知中的自定义操作按钮。在这 例如，iOS调用 应用：handleActionWithIdentifier：forRemoteNotification：completionHandler： 要么 应用：handleActionWithIdentifier：forLocalNotification：completionHandler :. 在这两种方法中，您都可以获得操作的标识符 确定用户点击的按钮。你也可以得到遥控器 或本地通知对象，以便您可以检索任何信息 你需要处理这个动作。
用户点按提醒中的默认按钮或点击（或点击） 应用程序图标如果轻触默认操作按钮（在运行的设备上） iOS），系统启动应用程序，应用程序调用其委托 application：didFinishLaunchingWithOptions：方法，传入 通知有效载荷（用于远程通知）或 本地通知对象（用于本地通知）。虽然 application：didFinishLaunchingWithOptions：不是最好的地方 处理通知，此时获取有效负载给你 在处理程序方法之前启动更新过程的机会 被称为。
对于远程通知，系统也会调用 应用：didReceiveRemoteNotification：fetchCompletionHandler： app delegate的方法。
如果在运行OS X的计算机上单击了应用程序图标，则应用程序会调用 委托的applicationDidFinishLaunching：方法中的 委托可以获取远程通知负载。如果是app图标 在点击运行iOS的设备上，该应用程序调用相同的方法，但是 不提供有关通知的信息。
如您所见，当应用程序从被杀死状态开始或未被取消停靠时，仅检查点击通知。
另一个重点是：
服务质量
Apple推送通知服务包括默认的服务质量 执行存储转发功能的（QoS）组件。如果是APN 尝试发送通知但设备处于脱机状态 通知存储一段有限的时间，并传递给 设备何时可用。最近只有一个通知 存储特定的应用程序。如果发送多个通知 设备处于脱机状态，新通知会导致先前的通知 通知被丢弃。这种行为只保留最新 通知称为合并通知。
如果设备长时间处于离线状态，则会发出任何通知 被存放，因为它被丢弃。
所以，长话短说，交付＆amp;推送通知的存在是非常令人期待的，但不能保证。此外，设备上推送通知的路径不能以编程方式控制 - 作为应用程序，您在设备上订阅APNS守护程序并且您依赖关于推送通知。
这就是为什么，如果你的应用程序有一些业务逻辑（在你的情况下，计数器更新），你不应该依赖推送通知。您应该使用更可靠/可控的机制来同步应用和后端之间的数据。通过使用REST并在我的应用程序的问题域中专用Notification实体，我几次实现了这一目标 - 用户可以通过REST API获取通知，将其标记为已读/未读，删除等。
答案 3 :(得分：0)
您可以将一些参数添加到接收到推送通知的json数据中，例如"type":1以识别通知类型。见Examples of JSON Payloads。但是，来自API的通知的加载计数更好，然后将每种类型的通知计入应用程序。
答案 4 :(得分：-1)
如果用户通过单击通知打开应用程序或应用程序已打开，则只能获取通知有效内容信息。在两种情况下didReceiveRemoteNotification都会调用。除了这些情况，您还可以在服务器上调用服务，该服务包含应用程序打开时的通知计数信息。