iOS CoreBluetooth：状态保存和恢复

本文介绍了iOS CoreBluetooth：状态保存和恢复的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

希望在这里获得一些意见。

hope to get some input here.

在我目前的iOS项目中，我使用的是带有swift的CoreBluetooth。该应用程序可以在后台使用CoreBluetooth进行通信，基本上可以正常工作。外围设备需要与iOS设备建立活动连接才能按预期工作。只要连接中断，外围设备就会停止当前操作。当应用程序因内存压力而关闭时，也会发生这种情况。在这种情况下，外围设备不应停止工作，因此存在问题。为了解决这个问题，我跟着苹果核心蓝牙编程指南实现状态保存和恢复后台模式，基本上说：

In my current iOS project I am using CoreBluetooth with swift. The app is enabled to communicate using CoreBluetooth in the background which basically works, kind of. The peripheral requires to have an active connection with the iOS device in order to work as expected. Whenever the connection breaks, the peripheral stops it current action. This also happens when the app is closed due to memory pressure. In that case the peripheral should not stop working, so there's a problem. In order to solve it, I followed apples core bluetooth programming guide to implement the state preservation and restoration background mode which basically says:

使用恢复标识符初始化CentralManager。 Delegate = self。

实现willRestoreState委托方法。 NSLog的东西

检查特殊键的launchOptions。 NSLog的东西。

我使用这个常见项目迫使iOS在后台关闭应用程序：BackgroundKill 的。当然应用程序不再以调试模式运行，这就是我在设备控制台中寻找重要点时添加一些NSLog语句的原因。好消息：当应用程序终止时，连接不再被取消，iOS现在按预期运行以保持连接，因此外围设备不会停止工作。罢工！除了应用程序订阅的电池服务之外，在此期间中央和外围设备之间没有通信。建立活动连接的唯一原因是防止外围设备停止工作。

I force iOS to close the app while it is in background using this common project: BackgroundKill. Of course the app is not running in debug mode anymore, that's why I added some NSLog statements at important points to look for in the device console. The good news: the connection is not cancelled anymore when the app is terminated, iOS is now acting as expected to keep the connection so the peripheral won't stop working. Strike! There's no communication between central and peripheral during this time except for the battery service which the app is subscribed to. The only reason to have an active connection is to prevent the peripheral from stop working.

现在手动重新启动应用程序时，没有提到的NSLogs出现。永远不会调用willRestoreState委托，并且launchOptions为nil。我在实例化CentralManager时尝试使用队列DISPATCH_QUEUE_CONCURRENT而不是nil。没有效果。

When relaunching the app manually now, none of the mentioned NSLogs shows up. The willRestoreState delegate is never called and the launchOptions are nil. I tried to use the queue "DISPATCH_QUEUE_CONCURRENT" instead of nil when instantiating the CentralManager. With no effect.

重新启动应用程序时，我应该如何使用保留的连接？为什么从不调用willRestoreState委托？我在这里错过了什么吗？为了使用状态保存和恢复，是否必须在系统后台/强制关闭时接收数据？

How am I supposed to use the preserved connection when relaunching the app? Why is the willRestoreState delegate never called? Am I missing something here? Is it mandatory to receive data while being backgrounded/force closed by system in order to use the state preservation and restoration?

感谢您的帮助。 ：）

推荐答案

最后做了一些测试并得到了结果。事实证明，当需要时，应用程序将启动到后台，这意味着只要外围设备在保留的连接上发送数据。在这种情况下，iOS通过 didFinishLaunchingWithOptions 启动应用程序，因此您有大约10秒的时间来检查启动选项并执行某些操作。所以我的问题与连接上没有数据发送有关，似乎我们现在必须更改外围设备的固件以对其进行排序。

Finally made some tests and got results. It turns out that the app is launched into background when needed, which means whenever the peripheral sends data on the preserved connection. iOS launches the app through didFinishLaunchingWithOptions in this case, so you have ~10 seconds to check your launch options and do something. So my problem was related to the fact that there was no data sent on the connection, seems we now have to change the firmware of our peripheral to sort this out.

手动重新启动应用程序时调用delegate willRestoreState 。此时，iOS不仅提供最近使用的中央设备，还提供连接外围设备列表，甚至是最近订购的服务。所以我只需要恢复我的对象，并从连接的外围设备的正确服务中获得订阅的特性再次完全正常运行。

The delegate willRestoreState is called when relaunching the app manually. At this point iOS provides not only the recently used central but also a list of connected peripherals and even the recently subscribed services. So I just had to restore my objects and get the subscribed characteristic from the right service of the connected peripheral to be fully functional again.