我知道答案的名义上是“否”，但我的意思是真的-如果应用程序进入后台（启用了BTLE后台处理）会怎样？24小时？跨应用更新？
此Apple文档在“重新连接至外围设备”标题下，描述了重新连接工作流程，该工作流程首先尝试重新连接至通过配对找到的先前配对的外围设备，retrievePeripheralsWithIdentifiers:但如果连接失败，则重新开始扫描。connect如果没有正式的超时，您如何知道何时放弃-ing到先前发现的外围设备？如果您想重新连接到先前找到的BTLE设备，而又无需用户与您的应用进行交互，那么您如何知道何时开始/继续扫描呢？
此外，在该页面下的注释中还说，某些BTLE设备可能在每次开机时都会为自己创建一个随机标识符，因此即使您发现以前配对的一些外围设备retrievePeripheralsWithIdentifiers:也可能无法以它们的名称连接到它们已改变。在实践中是否有任何BTLE设备这样做？疯了！
这是一个棘手的问题。CoreBluetooth框架本身在连接请求上没有官方超时。实际上，它将尝试尽可能长时间地连接外围设备。但是那要持续多久？
好吧，不幸的是，这并不是一个很好的定义。您可以非常有信心，当应用程序处于前台时，连接不会超时，但是一旦您在后台涉及到连接，事情就不再那么有趣了。显然，就像您提到的那样，挂起的连接不会在电话重启后保留，等等。这很好，因为没有用户希望该应用在重启后仍然可以运行。关于长期运行的挂起连接，您会在Apple的文档中找到它们告诉您选择加入状态保存和恢复，以确保在应用程序暂停并最终终止时正确保留挂起的连接。如果按广告说的那样工作，那会很好，但不幸的是，它却并非如此。经过多年的研究，我发现在iOS上获得可靠的后台连接几乎是不可能的。我已经报告了有关此主题的许多错误，但到目前为止，尚未解决。
我认为您应该特别注意一些问题：
如果您的应用程序处于终止状态时发生了蓝牙状态更改事件，则状态保留和恢复将完全停止工作。从本质上讲，这意味着如果蓝牙芯片由于任何原因（例如，通过切换蓝牙/飞行模式等）被重置，那么只要外围设备在范围内进行广告宣传，您的应用就不会再由Core Bluetooth重新启动。这样做的原因是，每当重启蓝牙芯片时，您应用程序已设置的所有未决连接都会被清除。问题是您的应用程序将不会重新启动以通知您此更改，因此挂起的连接将永远无法恢复。因此，您的应用程序会认为外围设备可以连接，而实际上它们不会。对我来说，这是最严重的问题，仅此一项就使CoreBluetooth非常不可靠。
有时，框架处于“卡住”状态时（可能是由于内部竞争条件或类似原因）。这可以随机发生，但是您可以通过在didFailToConnect或didDisconnect回调中立即调用connectPeripheral来轻松重现此错误。当发生这种情况时，实际上未设置挂起的连接，则“连接状态”属性将设置为“正在连接”。为避免这种情况，我发现您应至少等待20毫秒左右再进行连接，例如使用dispatch_after或其他方法。
框架内部使用XPC连接进行进程间通信，以便传递蓝牙事件。在某些情况下，无论出于何种原因，连接都会中断，连接将会丢失。我不知道为什么会这样，但是无论何时发生状态保存都会停止工作，您将必须手动重新启动应用程序才能从中恢复。有时我设法在设备sysdiagnose日志中捕获到此信息...
如果iPhone当前未连接（超出范围/飞行模式/电量低//或其他任何原因），则使用iPhone 7并同时具有Apple Watch（已与手机配对）将完全断开锁定屏幕后面的所有重新连接。原因）。自从最近引入以来，这特别糟糕！但是由于某种原因，Apple Watch似乎比其他蓝牙外设具有“优先权”。
这些是从我的头上来的，但是还有其他问题。关于随机地址，最常见的是这些外围设备使用所谓的“随机可解析”地址。这意味着它们看起来是随机的，但实际上可以使用通常在初始蓝牙绑定期间共享的IRK（身份解析密钥）来解析它们。据我所知，使用完全随机地址的设备不是很常见。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句