核心蓝牙 - 应用程序终止并在后台启动后,startScanningForPeripherals 在后台不工作

Core Bluetooth - startScanningForPeripherals not working in background after app terminated and started in background

我有一个自定义的 BLE 外围设备,当有人进入建筑物时,它会将 LED 变为绿色,并在他们离开建筑物时关闭 LED。 iOS 应用程序使用地理围栏区域在人员进出建筑物时向应用程序发送通知。 locationManger didDetermineState 在区域更改时被调用,BadgeHandler class 被调用以更新徽章。一切在前台和后台都运行良好,直到 iOS 终止应用程序。

当应用程序在后台被 iOS 终止,随后收到地理围栏区域通知时,startScanningForPeripherals 不起作用。

徽章(外设)耗尽 2 块手表电池,为了尽量减少电池消耗,我们连接到外设(徽章)只是为了更新 LED,然后断开与外设的连接 .

这在前台和后台都工作得很好,直到 iOS 在后台终止应用程序。当应用程序在地理围栏区域更改 startScanningForPeripherals 的后台启动备份时,调用后不会产生任何委托通知。

我有一个委托方法:willRestoreState 这没有接到电话。它没有被调用的原因是当应用程序在后台被 iOS 终止时,它没有扫描设备或连接到设备。以下是事件的顺序以及我如何调用这些方法:

  1. 应用 运行 并置于后台
  2. 应用程序收到地理围栏通知并连接到徽章(外围设备)更新 LED 并断开与徽章(外围设备)的连接。按要求工作。
  3. 一段时间后,iOS 终止应用程序
  4. 收到地理围栏区域通知
  5. 应用自动重启,(注意:应用还在后台) didFinishLaunchingWithOptions 被调用,我启动了 centralManager:

let cmQueue = DispatchQueue( label: "com.serial-queue") centralManager = CBCentralManager(delegate:self, queue: cmQueue, options: [CBCentralManagerOptionRestoreIdentifierKey:"com.TrueAccess.BLEConnect.CentralManager",CBCentralManagerOptionShowPowerAlertKey:true,CBCentralManagerScanOptionAllowDuplicatesKey:true])

  1. 委托方法:centralManagerDidUpdateState 被调用:

else if central.state == .poweredOn{ startScanningForPeripherals(central) }

  1. 然后使用它正在寻找的服务 ID 调用开始扫描,这样扫描就可以在后台进行。

if central.state == .poweredOn { let serviceUUID:[CBUUID] = [CBUUID(string: "ID Number here")] central.scanForPeripherals(withServices: serviceUUID, options: [CBCentralManagerScanOptionAllowDuplicatesKey : true])

此后没有收到委托方法,即: didDiscover didConnect didFailToConnect

非常感谢任何帮助。

问题更新。 我在 8 年的 iOS 编程中向 Apple 提交了我的第一个技术解决方案问题。这是他们的回应。我会保持更新。

Although there are many ways that an app can go wrong and not be able to scan or connect in the background, it is important to check first, if the lights are on.

That is, is the peripheral advertising properly at the time your app starts scanning in the background?

Following the specifications for the advertising interval and the advertising data becomes crucial when an app is scanning in the background. What might work in the foreground, even if out of spec, would start having problems when the app is in the background, or in terminated state.

The advertising interval of your peripheral affects the time to discovery and connect performance. To have a high probability of being discovered by an Apple product you should first use the recommended advertising interval of 20 ms for at least 30 seconds. If it is not discovered within the initial 30 seconds, you can switch to using one of the following longer intervals to increase chances of discovery: 152.5 ms, 211.25 ms, 318.75 ms, 417.5 ms, 546.25 ms, 760 ms, 852.5 ms, 1022.5 ms, 1285 ms

Also, it is important that the service UUID you are scanning for is contained in the first advertising packet (ADV_IND) to ensure successful discovery of the peripheral under all conditions.

So, please check these advertising requirements, and if those are OK, then we can see if there is something wrong in the app.

您是否在 info.plist 中添加了正确的权限?

<key>NSBluetoothPeripheralUsageDescription</key>
<string>BLE required</string>

<key>UIBackgroundModes</key>
<array>
    <string>bluetooth-central</string>
    <string>bluetooth-peripheral</string>
    <string>location</string>
</array>

此致

正如 Apple 技术支持所提到的,我们确定我们正在扫描的服务 UUID 不包含在外围设备的第一个广告数据包中。

一旦我们用这个修复程序更新了外围设备的固件,在应用程序被 iOS 终止后在后台扫描效果很好。