核心蓝牙 - 在后台执行长期操作

Question

这是来自官方文档中的 iOS 应用程序的核心蓝牙后台处理部分：

在后台执行长期操作

某些应用可能需要使用 Core Bluetooth 框架来执行 后台的长期操作。例如，假设您是 为 iOS 设备开发一个家庭安全应用程序，以进行通信 带门锁（配备蓝牙低功耗技术）。这 app和锁交互，当用户使用时自动锁门 离开家并在用户返回时解锁门——同时 应用程序在后台。当用户离开家时，iOS 设备 最终可能会超出锁定范围，导致连接 到锁丢失。此时，应用程序可以简单地调用 connectPeripheral:options: CBCentralManager 类的方法，以及 因为连接请求不会超时，iOS 设备会 用户回家后重新连接。

好的，我们有一个应用程序可以适当地锁定/解锁门...正如所指出的，当应用程序处于后台时（很可能处于暂停模式），这可以工作。现在，让我们继续（引用文档）：

现在假设用户离开家几天。如果应用程序 当用户离开时被系统终止，应用程序将不会 当用户回家时能够重新连接到锁，并且 用户可能无法解锁门。对于这样的应用程序，它是 能够继续使用 Core Bluetooth 执行的关键 长期操作，例如监控活动和未决连接。

所以，如果用户离开家几天，应用程序已经被 iOS 终止，我们将不得不执行状态保存和恢复，以便 iOS 在检测到连接请求时重新启动应用程序，并让应用程序来解锁门。相关引述：

在上述家庭安全应用的情况下，系统 将监控连接请求，并重新启动应用程序以 处理 centralManager:didConnectPeripheral: 委托回调时 用户回到家，连接请求完成。

这都是有道理的，但再次注意这部分：

现在假设用户离开家几天。如果应用程序 被系统终止当用户离开时，应用将无法在用户回家时重新连接到锁，并且 用户可能无法解锁门。对于这样的应用程序，它 对于能够继续使用 Core Bluetooth 执行 长期行动...

这是否意味着，如果应用程序在用户离家时的某个时刻被用户强行杀死，这是否也能正常工作？意思是当用户回到家时，无论如何门都会解锁，还是必须手动重新启动应用程序才能解锁？

我之所以这么问，是因为重新启动已终止的应用程序是如何工作的。用户杀掉应用和iOS杀掉支持后台执行的应用是不一样的：

支持后台执行的应用程序可能会被系统重新启动 处理传入事件。如果应用程序因任何原因被终止 除了用户强制退出之外，系统会启动应用程序 当以下事件之一发生时...

Source

再一次，如果用户离开了几天并且他通过双击主页按钮并向上拖动关闭了应用程序，他是否能够在不手动重新启动应用程序的情况下进入他的家？

Answer 1

没有。如果应用程序被用户强行杀死，那么它将不会再次被唤醒。它会被唤醒的唯一情况是应用程序被 iOS 本身终止，当应用程序有一段时间没有成为前台时，这种情况迟早会发生。如果设备重新启动，它也不会重新启动。

话虽如此，根据我使用 Core Bluetooth 的经验，我得出的结论是，状态保存太不可靠了。我相信您尝试实现的用例效果不够好，这具有讽刺意味，因为这正是 Apple 宣传其文档的用例。

例如，您会遇到以下问题：

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

如果用户切换飞行模式、切换蓝牙、重启 iOS 设备或任何其他未定义的原因（许多原因会导致状态更改），就会发生这种情况……如果“ ...用户离开家几天。”。

我和其他人已多次报告此“问题”，但 Apple 似乎出于某种原因不想修复它。

除此之外，还存在许多其他问题，例如 XPC 连接在不同时间无故中断。我还注意到挂起的连接可以进入“边缘”模式，其中外围状态设置为正在连接，但实际上它永远不会连接，除非您循环连接状态。等等等等……

/A