BLE 恢复/保存意外效果

Posted 2023-03-05

【中文标题】BLE 恢复/保存意外效果

【英文标题】：BLE Restoration/Preservation unexpected effect

【发布时间】：2017-03-14 06:50:43

【问题描述】：

我已经为CoreBluetooth 实现了恢复功能，它工作正常，除了一件事 - 在后台一周后（+/- - 不确定 100%），没有打开，应用程序终止并且不再恢复基于 BLE 的事件（测试了几次）。

我还向所有 BLE 相关任务添加了日志记录，添加了用于捕获崩溃的分析，另外跟踪恢复过程/事件 - 在检查此日志/信息/报告后 - 未发现任何异常或可以终止我的应用程序的东西。

问题是 - 谁能解释我为什么会出现这种行为？

【参考方案1】：

蓝牙相关问题确实很难识别。过去我们遇到了几个无法解释的错误。确定 BLE 不再工作或行为异常的唯一方法是查看设备上的 CoreBluetooth 日志。

如果您还没有尝试过，您可以通过可以从Apple Developer Pages 下载的配置文件启用这些日志（查找蓝牙并按照说明进行操作）。

启用日志记录后，您可以从底层 BLE 堆栈下载完整的日志，它会告诉您出了什么问题。他们甚至会告诉您是否以某种方式滥用了 API。希望对您有所帮助。

【讨论】：

哦，那应该有帮助，事件不要考虑这种可能性

是的，它是ios开发的隐藏宝藏之一。准备好阅读大量有关蓝牙堆栈的 C++ 日志记录；-)。

【参考方案2】：

根据我在 CoreBluetooth 状态保存和恢复方面的经验，我得出的结论是它不能可靠地工作。你可以让它“正常”地工作，但在后台使用长时间运行的挂起连接时，你永远不会让它可靠地重新连接。

我已经报告了几个与此相关的错误，但我认为最严重的一个是如果蓝牙管理器在应用程序终止时切换状态，那么所有挂起的连接都将丢失（因为它们不会被模块或iOS 堆栈）。由于蓝牙状态切换不会导致您的应用程序重新启动，因此这仅意味着在任何时候您的挂起连接都可能丢失并且您不会知道它。这本身就意味着状态恢复是相当无用的。你可以说这不是一个错误，而是一个糟糕的设计选择……

另一个问题是，有时框架会“卡”在不良状态（可能是由于内部竞争条件或类似情况）。这可以随机发生，但您可以通过在 didFailToConnect 或 didDisconnect 回调中立即调用 connectPeripheral 来轻松重现此情况。发生这种情况时，connectionState 将设置为正在连接，而实际上并非如此。

等等……

/安东