gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-11-28 08:08:05 24 4
gpt4 key购买 nike

我有一个定制的 BLE 外围设备,它可以在有人进入建筑物时将 LED 变为绿色,并在他们离开建筑物时关闭 LED。当有人进入和离开建筑物时,iOS 应用程序使用地理围栏区域向应用程序发送通知。 locationManger didDetermineState 在区域更改时被调用,BadgeHandler 类被调用以更新角标(Badge)。在 iOS 终止应用程序之前,前台和后台的一切都运行良好。

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

角标(Badge)(外围设备)耗尽 2 block watch 电池,为了尽量减少电池消耗,我们连接到外围设备(角标(Badge))只是为了更新 LED,然后断开与外围设备的连接

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

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

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

让 cmQueue = DispatchQueue( label: "com.serial-queue")
centralManager = CBCentralManager(委托(delegate): self ,队列:cmQueue,选项:[CBCentralManagerOptionRestoreIdentifierKey:“com.TrueAccess.BLEConnect.CentralManager”,CBCentralManagerOptionShowPowerAlertKey:true,CBCentralManagerScanOptionAllowDuplicatesKey:true])

  1. 委托(delegate)方法:centralManagerDidUpdateState 被调用:

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

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

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

在此之后没有收到委托(delegate)方法,即:
发现
连接
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.

最佳答案

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

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

关于ios - 核心蓝牙 - 应用程序终止并在后台启动后,startScanningForPeripherals 在后台不工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44526136/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com