android - Oreo 上的 altbeacon 库的 BLE 扫描如何工作？

Question

在 Android L 之前，Android Altbeacon 库使用后台运行服务来扫描 BLE 信标。默认扫描时间在前台循环中为 1.1 秒，在后台每 5 分钟为 10 秒。对于后台任务，警报管理器也用于唤醒应用程序。

鉴于不允许长时间运行的后台服务，我正在研究类似设置在 Android Oreo 中的工作原理。我正在经历 http://www.davidgyoungtech.com/2017/08/07/beacon-detection-with-android-8它确实清除了一些东西，但我仍然不完全清楚扫描如何与蓝牙扫描 API 和作业调度程序结合使用。

那么低功耗扫描如何结合基于作业调度程序的周期性调度来监视和范围信标？如果有人可以提供一个很好的例子。

更具体一点-

1. 我们什么时候进行被动新信标检测与正常背景扫描？
2. 为什么被动扫描仅适用于新检测？为什么我们不能循环运行它？为什么它只在作业调度程序扫描之间运行？
3. 假设我设置了 10 秒的扫描周期和 2 分钟的扫描间隔。在什么时间间隔使用什么技术来扫描信标？
4. 如果作业调度程序可以安排频率超过 15 分钟的作业，并且最多可以运行 10 分钟，我们可以将扫描间隔设置为 10 分钟，将扫描间隔设置为 5 分钟吗？由于操作系统的限制，我们只会损失 5 分钟的扫描时间吗？另外，我们可以在这 5 分钟内进行被动扫描吗？所以我们没有任何不扫描信标的时间跨度？

Answer 1

了解低功耗扫描如何在低级别工作至关重要:

低功耗扫描依赖于将蓝牙 LE 模式匹配卸载到蓝牙芯片上的硬件过滤器。如果与传入数据包匹配，芯片会通知操作系统，操作系统会向应用程序发送一个 Intent ，唤醒它以处理数据包。

以上内容依赖于由 Intent (Android 8 中的新 API)传递的过滤扫描的组合。

当计划的扫描作业以 Android Beacon 库结束时，这种基于 Intent 的交付被设置为由操作系统和蓝牙芯片处理。最终结果是，如果检测到新的信标，广播接收器将很快处理它。这可以在几秒钟内向应用程序发送一个监控回调，而不是等待 15 分钟等待下一个预定作业。

这一切都是为了在过滤器与附近的蓝牙设备不匹配时起作用。如果一个已经在附近，Intent 将在 100 毫秒左右发送，这是一种非常低效的 CPU 获取持续更新的方式，这破坏了低功耗 API 的全部意义，并且会导致应用持续运行并符合条件由 Android 8 终止。

使用的过滤器匹配任何信标。这样做是为了节省过滤器，因为它们是有限的硬件资源。出于这个原因，如果已知信标已经存在，则不会使用这些扫描 API，因为它会立即匹配数据包并破坏该技术的目的。底线:如果扫描作业以可见的信标结束，则低功率扫描未完成。

您不能将计划的作业设置为执行超过 15 分钟的频率。这是操作系统限制。扫描周期之间间隔 10 分钟是可行的，但图书馆只在周期结束时提供扫描结果，因此这可能没有太大帮助。可以将库修改为在每个扫描作业中最多只扫描 10 分钟，但目前它不会这样做，正如您所注意到的那样，它会留下 5 分钟的时间。

如果您真的想在 Android 8+ 的后台进行持续的 BLE 扫描，操作系统允许的方法是使用显示图标的前台服务，以便用户知道它正在运行。不过，在消费者应用程序中执行此操作时要小心，因为电池消耗非常大，用户可能会在将电池没电归咎于应用程序后卸载该应用程序。但是，对于特殊用例，这可能是可以接受的。