Ios CBCentralManager连接是否超时？

我知道答案名义上是“不”，但我的意思是，如果应用程序进入后台（启用BTLE后台处理），该怎么办？24小时？通过应用程序更新

在标题“重新连接到外围设备”下，描述了一个重新连接工作流，该工作流首先尝试重新连接到通过

检索外围设备标识：

找到的先前配对的外围设备，然后在连接失败时再次开始扫描。如果没有正式超时，您如何知道何时放弃连接以前找到的外设？如果您的想法是在移动回BTLE设备附近时重新连接到以前找到的BTLE设备，而用户不必与您的应用程序交互，那么您如何知道何时开始/保持扫描

---

此外，该页下方的一条注释指出，某些BTLE设备可能会在每次通电时为自己发明一个随机标识符，因此即使您从

retrieveperipheralswithindicatiers:

中找到一些以前配对的外围设备，您可能无法连接到它们，因为它们的名称已更改。在实践中有没有BTLE设备可以做到这一点？真是疯了

这是一个很难回答的问题。CoreBluetooth框架本身在连接请求上没有正式超时。事实上，它将尽可能长时间地连接外围设备。但那要多长时间

不幸的是，这并不是很明确的定义。你可以非常自信，当应用程序在前台时，连接不会超时，但一旦你在后台加入连接，事情就不再那么有趣了。显然，正如您所提到的，在手机重新启动后，挂起的连接将不会保留，等等。。这很好，因为不管怎样，用户都不会期望应用程序在重新启动后仍在运行。关于长时间运行的挂起连接，您会在苹果的文档中发现，他们告诉您选择状态保留和恢复，以确保挂起的连接在应用程序挂起并最终终止时得到正确保留。这将是好的，如果它的工作广告，但不幸的是，它没有。经过多年的研究，我发现在iOS上建立一个可靠的后台连接几乎是不可能的。我已经报告了很多关于这个主题的bug，但是到目前为止还没有一个得到解决

我认为有几个问题需要特别注意：

如果在应用程序处于终止状态时发生蓝牙状态更改事件，则状态保留和恢复将完全停止工作。这本质上意味着，如果蓝牙芯片因任何原因（例如通过切换蓝牙/飞行模式等）被重置，则当外围设备在范围内进行广告时，核心蓝牙将不会再次启动您的应用程序。原因是，每当蓝牙芯片重新启动时，应用程序设置的所有挂起连接都将被清除。问题是，您的应用程序不会重新启动以获得此更改的通知，因此挂起的连接将永远无法恢复。因此，你的应用程序会认为外围设备会连接，而实际上它们不会。对我来说，这是一个最严重的问题，它本身就使得CoreBooth非常不可靠

有时，框架会“陷入”糟糕的状态（可能是由于内部竞争条件或类似情况）。这可能是随机发生的，但您可以通过在DIDFILETOCONNECT或DIDDUNCTANCE回调中立即调用ConnectPeripal来很容易地重现这种情况。当发生这种情况时，“连接状态”属性被设置为“连接”，而实际上未设置挂起的连接。为了避免这种情况，我发现您应该在连接前至少等待20毫秒左右，例如使用dispatch_或其他方法

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

如果手表当前未连接（超出范围/飞行模式/电池电量不足/或任何其他原因），使用iPhone 7并同时使用Apple Watch（与手机配对）将完全中断锁屏后面的所有重新连接。这是特别糟糕的，因为它是最近推出的！但出于某种原因，苹果手表似乎比其他蓝牙外围设备具有“优先权”

这些都是我的想法，但还有其他问题。关于随机地址，这些外围设备通常使用所谓的“随机可解析”地址。这意味着它们看起来是随机的，但实际上可以使用IRK（身份解析密钥）解析，该密钥通常在初始蓝牙连接期间共享。据我所知，使用完全随机地址的设备并不常见