Rob*_*ins 3 ios core-bluetooth btle
我知道答案名义上是"不",但我的意思是 -如果应用程序进入后台(启用BTLE后台处理)会怎么样？24小时？在应用更新中？
在"重新连接到外围设备"标题下,此Apple文档描述了重新连接工作流程,该工作流程首先尝试重新连接到先前通过配对的外围设备,retrievePeripheralsWithIdentifiers:但如果连接失败则再次开始扫描.connect如果没有正式超时,你怎么知道何时放弃以前找到的外围设备？你怎么知道什么时候开始/继续扫描,如果想要重新连接到以前找到的BTLE设备,只要你回到它附近,而不是用户必须与你的应用程序交互？
此外,该页面下方的一个注释表明,一些BTLE设备可能会在每次开机时为自己创建一个随机标识符,因此即使您发现一些以前配对的外围设备retrievePeripheralsWithIdentifiers:也可能无法连接到它们作为其名称已经改变.任何BTLE设备在实践中都这样做吗？那太疯狂了!
Ant*_*ton 17
这是一个难以回答的问题.CoreBluetooth框架本身没有连接请求的正式超时.事实上,它会尝试尽可能长时间地连接外设.但这有多长？
好吧,不幸的是,这不是一个非常明确的定义.当应用程序位于前台时,您可以非常确信连接不会超时,但只要您在后台处理连接,那么事情就不再那么有趣了.显然,就像你提到的那样,待机连接在手机重启后不会保留等等.这很好,因为没有用户会希望应用程序在重新启动后仍然运行.关于长时间运行的挂起连接,您将在Apple的文档中找到它们,它们会指示您选择加入状态保留和恢复,以确保在应用程序暂停并最终终止时正确保留挂起的连接.如果它像宣传的那样工作会很好,但不幸的是它没有.经过多年的努力,我发现在iOS上获得可靠的后台挂起连接几乎是不可能的.我已经报告了很多关于这个主题的错误,但到目前为止还没有解决.
特别是有几个问题,我认为你应该特别注意:
如果在您的应用处于终止状态时发生蓝牙状态更改事件,则状态保留和恢复将完全停止工作.这实际上意味着如果蓝牙芯片因任何原因(例如切换蓝牙/飞行模式/等等)而被重置,那么当外围设备在范围内进行广告时,您的应用将永远不会被Core Bluetooth重新启动.这样做的原因是,每当蓝牙芯片重新启动时,您的应用程序设置的所有待处理连接都将被清除.这样做的问题是您的应用程序不会被重新启动以通知此更改,因此挂起的连接将永远不会被恢复.所以你的应用程序会认为外围设备会连接,而事实上他们不会.对我来说,这是最严重的问题,仅此一点使CoreBluetooth非常不可靠.
有时框架会"陷入"状态(可能是内部竞争条件或类似情况).这可能是随机发生的,但您可以通过在didFailToConnect或didDisconnect回调中立即调用connectPeripheral来轻松地重现这一点.发生这种情况时,如果未设置挂起连接,则"连接状态"属性将设置为"连接".为了避免这种情况,我发现你应该在连接之前至少等待大约20ms,例如使用dispatch_after或者其他东西.
框架内部使用XPC连接进行进程间通信,以便提供蓝牙事件.在某些情况下,无论出于何种原因,这都将破裂,并且连接将丢失.我不知道为什么会发生这种情况,但无论何时发生,状态保存都将停止工作,您将手动重新启动应用程序以从中恢复.有时我设法在设备sysdiagnose日志中捕获这个...
使用iPhone 7并同时拥有Apple Watch(与手机配对)将完全打破锁定屏幕后面的所有重新连接,以防手表当前未连接(超出范围/飞行模式/低电量/或任何其他原因).这是特别糟糕的,因为它是最近推出的!但看起来Apple Watch出于某种原因比其他蓝牙外围设备具有"优先级".
这些都是我的头脑,但也有其他问题.关于随机地址,通常这些外围设备使用所谓的"随机可解析"地址.这意味着它们看起来是随机的,但事实上它们可以使用IRK(身份解析密钥)来解决,IRK通常在初始蓝牙绑定期间共享.据我所知,使用完全随机地址的设备并不常见.
| 归档时间： |
|
| 查看次数： |
2195 次 |
| 最近记录： |