ios - CBCentralManager是否会超时连接？

Question

我知道答案名义上是“否”，但我的意思是真的-如果应用程序进入后台(启用​​了BTLE后台处理)会怎样？ 24小时？跨应用更新？

在“重新连接到外围设备”标题下，此Apple documentation描述了重新连接工作流程，该工作流程首先尝试重新连接到通过retrievePeripheralsWithIdentifiers:找到的先前配对的外围设备，然后在连接失败时再次开始扫描。如果没有正式的超时，您如何知道何时放弃connect -ing到以前找到的外围设备？如果您想重新连接到先前找到的BTLE设备，而又无需用户与您的应用进行交互，那么您如何知道何时开始/继续扫描呢？

此外，该页面下方的注释还指出，某些BTLE设备在每次开机时都可能会为其自己发明一个随机标识符，因此，即使您从retrievePeripheralsWithIdentifiers:找到一些先前配对的外围设备，您也可能无法连接到它们名称已更改。在实践中，是否有任何BTLE设备能够做到这一点？疯了!

Answer 1

这是一个棘手的问题。 CoreBluetooth框架本身没有针对连接请求的正式超时。实际上，它将尝试尽可能长时间地连接外围设备。但是那要多久？

好吧，不幸的是，这并不是一个很好的定义。您可以非常有信心，当应用程序处于前台时，连接不会超时，但是一旦您在后台涉及到连接，事情就不再那么有趣了。显然，就像您提到的那样，挂起的连接不会在电话重启后保留，等等。这很好，因为没有用户希望该应用在重启后仍然可以运行。关于长期运行的未决连接，您会在Apple的文档中找到它们告诉您选择加入状态保留和恢复，以确保在应用程序暂停并最终终止时正确保留未决的连接。如果按广告说的那样做，那会很好，但不幸的是，它却并非如此。经过多年的研究，我发现几乎不可能在iOS上获得可靠的后台挂起连接。我已经报告了有关此主题的许多错误，但到目前为止，尚未解决。

我认为您应该特别注意一些问题:

如果您的应用程序处于终止状态时发生了蓝牙状态更改事件，则

状态保留和恢复将完全停止工作。从本质上讲，这意味着如果蓝牙芯片由于任何原因(例如，通过切换蓝牙/飞行模式等)被重置，那么只要外围设备在范围内进行广告宣传，您的应用就不会再由Core Bluetooth重新启动。这样做的原因是，每当蓝牙芯片重新启动时，您应用程序已设置的所有未决连接都将被清除。问题是您的应用程序将不会重新启动以通知您此更改，因此挂起的连接将永远无法恢复。因此，您的应用程序会认为外围设备会连接，而实际上它们不会连接。对我来说，这是最严重的问题，仅此一项就使CoreBluetooth非常不可靠。

有时，框架处于“卡住”状态时(可能是由于内部竞争条件或类似原因)。这可以随机发生，但是您可以通过在didFailToConnect或didDisconnect回调中立即调用connectPeripheral来轻松重现此错误。当发生这种情况时，实际上未设置挂起的连接，则“连接状态”属性将设置为“正在连接”。为避免这种情况，我发现您应至少等待20毫秒左右再进行连接，例如使用dispatch_after或其他方法。

框架内部使用XPC连接进行进程间通信，以便传递蓝牙事件。在某些情况下，无论出于何种原因，连接都会中断，并且连接将会丢失。我不知道为什么会这样，但是无论何时发生，状态保存都会停止，您必须手动重新启动应用程序才能从中恢复。有时我设法在设备sysdiagnose日志中捕获到此信息...

如果当前未连接 watch (超出范围/飞行模式/电池电量低/或任何其他情况)，则使用iPhone 7并同时具有Apple Watch(与手机配对)将完全断开锁定屏幕后面的所有重新连接。其他原因)。自从最近引入以来，这尤其糟糕!但是，由于某种原因，Apple Watch似乎比其他蓝牙外设具有“优先权”。

这些是从我的头上来的，但也有其他问题。关于随机地址，最常见的是这些外围设备使用所谓的“随机可解析”地址。这意味着它们看起来是随机的，但实际上它们可以使用IRK(身份解析 key )来解析，该身份通常在初始蓝牙绑定(bind)期间共享。据我所知，使用完全随机地址的设备不是很常见。