iOS CoreBluetooth:状态保存和恢复

iOS CoreBluetooth: State Preservation and Restoration

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

在我当前的 iOS 项目中,我将 CoreBluetooth 与 swift 一起使用。该应用程序可以在后台使用 CoreBluetooth 进行通信,这基本上可以正常工作。外围设备需要与 iOS 设备建立有效连接才能按预期工作。每当连接中断时,外围设备都会停止其当前操作。当应用程序由于内存压力而关闭时也会发生这种情况。在那种情况下,外围设备不应该停止工作,所以有问题。为了解决这个问题,我按照apples core bluetooth programming guide实现了状态保存和恢复后台模式,基本上说:

  1. 使用恢复标识符初始化 CentralManager。代表=自我。
  2. 实现 willRestoreState 委托方法。 NSLog 东西
  3. 检查特殊密钥的启动选项。 NSLog 东西。

我强制 iOS 关闭应用程序,当它在后台使用这个公共项目时:BackgroundKill。当然,该应用程序不再以调试模式运行,这就是为什么我在重要位置添加了一些 NSLog 语句以在设备控制台中查找的原因。好消息:当应用程序终止时,连接不再被取消,iOS 现在按预期保持连接,因此外围设备不会停止工作。罢工!除了应用程序订阅的电池服务外,在此期间中央和外围设备之间没有通信。保持活动连接的唯一原因是防止外围设备停止工作。

现在手动重新启动应用程序时,上述 NSLog 均未显示。永远不会调用 willRestoreState 委托,并且 launchOptions 为零。在实例化 CentralManager 时,我尝试使用队列 "DISPATCH_QUEUE_CONCURRENT" 而不是 nil。没有效果。

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

感谢您的帮助。 :)

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

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