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

Question

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

使用密钥UIApplicationLaunchOptionsBluetoothCentralsKey启动时

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])

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

Answer 1

我想首先说我已经使用 CoreBluetooth 很长时间了，从我注意到 CoreBluetooth State Preservation and Restoration 根本不可靠地工作。 你可以让它“正常”工作，但除非苹果有一天修复它，否则你永远不会让它可靠地重新连接。

有很多错误会导致此功能无法正常工作，但我会给您一个我认为会导致您出现问题的错误：

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

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

但这只是一个错误。 还存在许多其他问题，例如 XPC 连接在不同时间无缘无故中断。 我还注意到挂起的连接可以进入“limbo”模式，其中外围状态设置为连接，但实际上它永远不会连接，除非你循环连接状态。

总之，我感到非常难过，说出来，但如果你正在开发必须依赖于周边在后台被重新连接的应用程序，然后我不建议这样做。 你会很沮丧。 我可能会写一篇关于 Apple 不想修复的 Core Bluetooth 中的所有错误的文章。 更奇怪的是，您可以通过一个应用程序轻松破坏设备上的全局蓝牙连接，因此在设备重新启动之前，任何应用程序都无法使用蓝牙。 这非常糟糕，因为它违背了 Apple 自己的沙盒原则。