外围设备需要特殊ACK时的CoreBluetooth和状态保存与恢复

Question

我正在使用蓝牙外围设备，在与蓝牙外围设备连接之后，它会来回发送ACK，然后它才能实际将所需的数据发送给我。

流程如下：

1. 发现外围设备
2. 连接到外围设备
3. 发现服务和特征
4. 收听有关特定特征的更新
5. 外围设备向该特征发送特殊消息
6. 然后，该应用将ACK发送到外围设备
7. 外围设备向我发送应用程序所需的数据

我已经在状态保存和恢复centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any])的协议方法中实现了所需的逻辑

问题1：

当应用程序处于后台并且iOS决定接管蓝牙通信（出于资源原因）时，iOS将如何执行步骤5、6和7？

因为如果不能，那么外围设备将无法发送应用程序在步骤7中所需的数据。

问题2：

在文档中，我读到iOS可能会启动您的应用几秒钟。在这种情况下，将执行我的根ViewController的viewDidLoad方法吗？那就是我实例化CBCentralManager

的地方

---

我发现了许多在线资源：

Core Bluetooth Background Processing for iOS Apps

Zero to BLE on iOS – Part Three

Answer 1

Paulw11的以下两条评论帮助我了解发生了什么：

  

不，那不会发生。如果您有待处理的发现，待处理的“连接”或者您对某个特征有有效的通知，则iOS将重新启动您的应用程序，以便它可以处理发现，连接或通知。 iOS无法代表您执行此操作；它不知道你想做什么。 – Paulw11

---

  

如果要在后台执行操作，则将蓝牙对象连接到视图控制器是一个坏主意。我建议您由应用程序代表Paulw11拥有一个单例或对象

---

首先，我有一个错误的假设：当我的应用程序处于后台并且iOS必须终止它时，iOS会尝试代表我的应用程序处理所有蓝牙通信。现实情况是，iOS在有限的时间内以后台模式启动该应用程序，以便您可以运行恢复代码。

最后，在ViewController的viewDidLoad中包含逻辑是错误的。我创建了一个BluetoothManager类，并在我的application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool的{​​{1}}方法中实例化了它