从后台远程推送通知手动递增时，应用程序的徽章编号卡在 1

Question

我正在 iOS 应用程序中实现推送通知。

在从服务器content-available = 1 发送的 PNs 中设置有效负载，以便应用在推送通知从服务器到达时接收用户和后台通知：

aps =     {
    alert = "Hello!";
    "content-available" = 1;
    sound = default;
};

这就是我处理后台通知的方式：

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
    if ([UIApplication sharedApplication].applicationState == UIApplicationStateBackground) {
        NSInteger currentBadgeNumber = [UIApplication sharedApplication].applicationIconBadgeNumber;

        [UIApplication sharedApplication].applicationIconBadgeNumber = currentBadgeNumber + 1;

        completionHandler(UIBackgroundFetchResultNewData);

        return;
    }

    ...
}

写完这篇文章后，我希望每次推送通知到达时我的应用程序的徽章编号都增加 1（假设我的应用程序在后台）。

这种简单的方法在我的 2 台设备上非常适合我：装有 iOS 7.1 的 iPhone 4 和装有 iOS 8.1.2 的 iPhone 6，但它不适用于我们的一位测试人员。我们进行了广泛的测试并验证了它对他不起作用 - 我们的应用程序在他设备上的标记第一次增加到 1 然后冻结 - 从那时起它始终保持为 1。他是这样描述这个问题的：

我唯一一次看到应用程序的徽章正确增加是在重新启动设备并登录之后，这将使我们的应用程序成为当时为数不多的后台运行应用程序之一。因为我的设备上运行了许多应用程序，其中许多还使用后台处理（FB、NextDoor、WhatsApp），我的理论是，我们的应用程序获得后台周期的频率越来越少，设备处于活动状态的时间越长，这就是我们错过的原因有机会在后台被调用并增加徽章编号。

在采用这种简单的方法从后台推送通知中手动增加徽章编号之前，我们还考虑了在服务器端跟踪徽章编号并通过badge 参数发送其明确编号（因为一些 SO 主题建议这样做），但对于为简单起见，我们决定尝试更简单的方法并实施我上面描述的非常简单的策略。

所以问题是：

1) 对于我实施这种简单策略可能会为我们的测试人员产生不稳定结果的任何见解？

2) 如果答案 1 是否定的，我们是否应该 100% 考虑在服务器端实施来跟踪徽章编号，以便为我们提供稳定的结果？

附：目前，我正在添加额外的日志记录字符串以向我们的测试人员发布新的测试版本，以了解此问题是否与 application:didReceiveRemoteNotification:fetchCompletionHandler 相关，这可能不会在每次推送通知到达时都被调用。

Answer 1

自从我提出这个问题以来，当我们尝试使用 content-available=1 在客户端进行控制时，我们仍然没有获得稳定的结果来控制应用程序的徽章。

这就是我们将这个责任转移到服务器端的原因：现在我们在服务器上跟踪了许多未读通知，以便服务器通过badge 参数在aps 有效负载中发送这个数字。这为我们带来了应用程序徽章正确增量所需的稳定性。

现在我强烈建议大家对应用程序的徽章进行服务器端管理！！事实证明，这种服务器端实现相当简单，您可以完全控制此功能。

Answer 2

尝试先设置为 1，然后设置为 0。有时它在我的应用中解决了这个问题。

    [[UIApplication sharedApplication] setApplicationIconBadgeNumber:1];
    [[UIApplication sharedApplication] setApplicationIconBadgeNumber:0];