iOS应用程序中的UNNotifications问题
我当时正在开发用于导航和跟踪解决方案的中等规模的iOS。 该应用程序是使用SWIFT 4中的XCode 9针对通用设备开发的。
问题背景：
该应用程序在收到一些远程通知后突然表现异常怪异。 由于此应用程序属于跟踪和导航类别，因此严重依赖于后台更新。 为此，我们使用MQTT，Firebase和APNS来进行通信，如果任何通信机制失败，应用程序将立即以零时间转移到其他更新机制。 当我们的项目进入回归测试阶段时，我们的另一种信息更新机制报告失败。
具有挑战性的解决方案：
经过大量的研发和深入研究该问题，我们认为该问题与远程通知没有直接联系。 苹果在iOS 10 SDK中的UNUserNotificationCenter中进行了一些更改。 Apple确实将远程通知和本地通知合并在一个框架“ UNUserNotificationCenter ”中。 因此，当应用程序运行时，它会处理“远程”通知，我们通过将消息通过本地通知委派给用户来通知用户。 通过广泛使用本地通知，iPhone SDK可以静默停止处理远程和本地通知。
在这一点上，我们的工程师具有多个方面来检测应用程序的故障并引起对实际问题的困惑，并将工程师转移到其他方面，例如后台任务处理，多线程，Web服务问题等。 但是实际的原因是是其文档中所写的违反Apple开发准则的行为 ：
“可以安排通知请求，以通过时间和位置通知用户。 有关更多信息，请参见UNNotificationTrigger。 调用-addNotificationRequest：将使用相同的标识符替换现有的通知请求。 标识符为现有交付通知的通知请求将为新的通知请求发出警报，并在触发时替换现有交付通知。 应用程序可以在任何时候调度的待处理通知请求的数量受到系统的限制 。”
实际上，这种趋向于权衡的业务逻辑实现是我们最不优先考虑的。 因此，我们必须发明一种不会破坏客户业务的新解决方案。
实施：
通常，我们处理远程通知并将其传输到本地通知以在设备上显示。
//创建远程通知请求
let request = UNNotificationRequest（标识符：requestIdentifier，内容：内容，触发器：触发器）
//将远程通知发布到UNUserNotificationCenter框架
UNUserNotificationCenter.current（）。add（request，withCompletionHandler：{（错误）在
logsManager.error（“显示本地通知错误”，错误为“任意”）
}）
}
由于苹果在UNUserNotificationCeneter框架中发生更改， 因此如果我们每分钟调用2-3次以上， 则会多次调用本地通知发布问题。 没有记录实际的脱粒保持力。
APNS提供两种类型的远程通知。
- 推送通知–用作警报，并显示在通知中心。
- 静音推送-用于多语言支持。
这是APNS有效负载的示例json：
{
“ aps”：{
“ alert”：“ ”，
“可用内容”：1
}，
“数据”：{
“令牌”：“ 00001109-429”，
“ type”：“ notificationType”，
：
}
}
内容可用值定义通知的类型。 通过将值更改为“ 0”，iOS可以处理通知并在通知中心显示警报。 服务器端的这一微小更改可以解决整个问题，而不是使用通过处理来处理远程通知的旧协议，而是委派设备使用本地通知来呈现警报并打扰现有的应用程序代码，而是解决了整个问题。
该解决方案的魅力十足，可以根据业务需求进行折衷。