关于ios：核心蓝牙-应用终止并在后台启动后，startScanningForPeripherals在后台无法运行

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

我有一个定制的BLE外设，当一个人进入建筑物时，该LED会变绿，而当他们离开建筑物时，该LED会熄灭。当人员进入建筑物并离开建筑物时，iOS应用程序将使用Geofence区域将通知发送给应用程序。 locationManger didDetermineState在区域更改时被调用，并且BadgeHandler类被调用以更新徽章。在iOS终止应用程序之前，一切都可以在前台和后台正常运行。

当应用程序在后台被iOS终止时，随后出现地理围栏区域通知时，startScanningForPeripherals将不起作用。

徽章(外围设备)用完2块手表电池，为了最大程度地减少电池消耗，我们连接到外围设备(徽章)只是为了更新LED，然后断开与外围设备的连接。

这在前台和后台都可以正常工作，直到iOS在后台杀死该应用为止。当应用程序在地理围栏区域的后台启动后，调用它后，更改startScanningForPeripherals不会导致任何委托通知。

我确实有一个委托方法：willRestoreState
这不会接到电话。无法调用该应用程序的原因是，该应用程序在后台被iOS终止时未扫描设备或未连接到设备。以下是事件的顺序以及如何调用这些方法：

应用正在运行并置于后台

应用程序会收到地理围栏通知，并连接到徽章(外围设备)以更新LED并与徽章(外围设备)断开连接。根据需要工作。

一段时间后，iOS终止了该应用程序

出现了地理围栏区域通知

该应用程序将自动重新启动，(请注意：该应用程序仍在后台)
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])

委托方法：centralManagerDidUpdateState被调用：

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

然后使用正在寻找的serviceID调用开始扫描，因此扫描可以在后台进行。

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

此后未收到任何委托方法，即：

didDiscover
didConnect
didFailToConnect

非常感谢您的帮助。

更新问题。我在iOS编程的8年中向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.