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

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

在后台执行长期操作

Some apps may need to use the Core Bluetooth framework to perform long-term actions in the background. As an example, imagine you are developing a home security app for an iOS device that communicates with a door lock (equipped with Bluetooth low energy technology). The app and the lock interact to automatically lock the door when the user leaves home and unlock the door when the user returns—all while the app is in the background. When the user leaves home, the iOS device may eventually become out of range of the lock, causing the connection to the lock to be lost. At this point, the app can simply call the connectPeripheralptions: method of the CBCentralManager class, and because connection requests do not time out, the iOS device will reconnect when the user returns home.

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

Now imagine that the user is away from home for a few days. If the app is terminated by the system while the user is away, the app will not be able to reconnect to the lock when the user returns home, and the user may not be able to unlock the door. For apps like these, it is critical to be able to continue using Core Bluetooth to perform long-term actions, such as monitoring active and pending connections.

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

In the case of the home security app described above, the system would monitor the connection request, and re-relaunch the app to handle the centralManager:didConnectPeripheral: delegate callback when the user returned home and the connection request completed.

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

Now imagine that the user is away from home for a few days. If the app is terminated by the system while the user is away, the app will not be able to reconnect to the lock when the user returns home, and the user may not be able to unlock the door. For apps like these, it is critical to be able to continue using Core Bluetooth to perform long-term actions...

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

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

Apps that support background execution may be relaunched by the system to handle incoming events. If an app is terminated for any reason other than the user force quitting it, the system launches the app when one of the following events happens...

Source

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

---

Best Answer-推荐答案

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

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

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

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

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

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

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

/A

关于ios - 核心蓝牙 - 在后台执行长期操作，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40761722/