iOS 在从外设传入 BLE 连接时停止唤醒应用程序

我们有一个 BLE 外设，每小时连接到手机并传递一些数据。该过程的工作原理如下：

使用密钥启动后UIApplicationLaunchOptionsBluetoothCentralsKey in

1. application(didFinishLaunchingWithOptions launchOptions)应用程序使用传递给它的 ID 重新初始化 CBCentralManager。
2. 然后它会执行常规恢复周期并从 BLE 外设读取数据。
3. 向云中的服务执行 REST 请求。

假设应用程序在手机重启后至少启动一次，几天内一切正常（如果应用程序没有运行或被迫内存不足，iOS 会正确地再次启动它，假设用户没有手动强制关闭）。

然而，每隔几天，当有来自 BLE 设备的传入请求时，iOS 就会停止唤醒应用程序。如果用户重新启动应用程序，一切都会正常运行几天，然后再次停止。鉴于我们产品的性质，让我们的应用程序/外围设备以最可靠的方式协同工作至关重要。

关于为什么会发生这种情况的理论：
（经过仔细检查，他们都被解雇了）

• 用户重新启动手机并忘记重新启动应用程序。
  我们添加了正常运行时间的记录，它显示手机在应用程序启动之间没有重新启动。

• 内存警告导致应用程序被启动。
  再次添加日志记录，他们表明没有applicationDidReceiveMemoryWarning

• 连接不良会导致应用程序在上传结果时运行时间超过 10 秒，iOS 会终止它并感到不安
  我们人为地将服务器响应延迟了 15 秒来测试这一点，并且在测试过程中一切都继续正常工作。

关于正在发生的事情以及为什么 iOS 停止通知应用程序有关传入 BLE 连接的任何想法？

问题之一是我们无法弄清楚如何可靠地重现该问题，因此任何建议也将不胜感激！

谢谢你！

更新1：这是我们初始化的方式CBCentralManager:

self.centralManager = CBCentralManager(delegate: self, queue: nil, options: [
    CBCentralManagerOptionRestoreIdentifierKey : MyCentralManagerID,
    CBCentralManagerOptionShowPowerAlertKey : 0])

我看到一些建议，队列参数不应为零。鉴于我无法可靠地重现问题，我会犹豫是否要进行更改，直到我可以自信地观察其效果。

首先我想说的是，我已经使用 CoreBluetooth 很长时间了，据我所知，CoreBluetooth 状态保存和恢复根本无法可靠地工作。你可以让它“正常”工作，但你永远不会让它可靠地重新连接，除非有一天苹果修复它。

有很多错误会导致它无法正常工作，但我会给你一个我认为导致你的问题的错误：

如果事件源自您正在通信的外围配件，例如连接/断开事件和特征通知，则状态恢复只会由于蓝牙相关活动而重新启动您的应用程序。对于其他事件，最重要的是一般蓝牙状态更改事件，您的应用程序将不会重新启动并收到通知。之所以如此糟糕，是因为所有蓝牙状态更改事件都会取消所有挂起或当前的连接，这意味着挂起的连接将被删除，并且您的应用程序不会收到通知。这实际上意味着您的应用程序仍然认为连接仍处于待处理状态，而实际上并非如此。由于您的应用程序此时已终止，因此再次唤醒它的唯一方法是让用户再次手动启动它（或者为此目的“破解”其他后台模式，这也不是很可靠）。

如果用户切换飞行模式、切换蓝牙、重新启动 iOS 设备或任何其他导致状态更改的未定义原因，就会发生这种情况......

但这只是一个错误。还存在许多其他情况，例如 XPC 连接在不同时间无明显原因中断。我还注意到，挂起的连接可能会进入“limbo”模式，其中外设状态设置为“正在连接”，但实际上，除非您循环连接状态，否则它永远不会连接。

无论如何，我很遗憾地说，但如果您正在开发一个必须依赖于在后台重新连接外围设备的应用程序，那么我不建议这样做。你会感到沮丧。我可能可以写一篇关于苹果不想修复的核心蓝牙中所有错误的文章。更奇怪的是，您可以很容易地通过一个应用程序破坏设备上的全局蓝牙连接，这样在设备重新启动之前没有应用程序可以使用蓝牙。这是非常糟糕的，因为它违背了苹果自己的沙盒原则。