LowPower AltBeacon扫描澄清

Question

我的目标是了解AltBeacon是如何工作的，并获得关于功耗和信标检测的最有效应用。目前，我正在分析图书馆，我需要一些澄清。

环境：

• 使用自定义信标，不依赖于功率(信标HW)，发射速率(adv)大于1/s。
• 使用android-信标库-参考与光修改，以匹配自定义信标；
• 使用Android 10操作系统
• 所有测试都是使用backgroundMode进行的。

以下是我的问题：

1. 在初始化时(使用RegionBootstrap)，我们从两个点到达ScanJobScheduler

- `BeaconManager:startMonitoringBeaconsInRegion`: schedules an immediate ScanJob to run in `50 millis`
- `BeaconManager:setBackgroundMode`: cancels the previous scheduled immediate ScanJob (because we are in background mode) and schedules a periodic ScanJob

是因为第二个电话不到50 millis而立即取消ScanJob的原因吗？为什么周期ScanJob被排定两次？

​

1. 在我关闭应用程序之后，重新启动需要10分钟，第一次扫描需要15分钟才能启动。 我们能否在应用程序启动后立即执行一次“定期扫描”，而不必再等待15分钟才能启动第一次定期ScanJob？
2. 低功耗HW滤波器只在一个ScanJob完成后才能工作

- I've seen that the HW filter is installed after ScanJob Lifecycle is completed (`createScanFiltersForBeaconParsers`)
- In the case where the application is killed, this means that the filter will be installed after the 1st periodic ScanJob completes (25 minutes)

我们可以在初始化后立即安装低功耗HW过滤器，而不是等待第一个ScanJob完成吗？

​

1. 如果我修改自定义信标上的ADV功率降低，距离计算器还能正常工作吗？
2. 只使用背景模式有意义吗?还是应该切换到前台？这会否达到我的目标呢？

- Start service in foreground
- Install HW filter (if point 3 is not an option, do an immediate scan in foreground to trigger it)
- Scan in background until the HW filter delivers the intent
- Start scanning in foreground after we detect the 1st beacon
- Scan in foreground until we are out of the region in order for the HW filter to be installed again (`startPassiveScanIfNeeded`)
- Switch to scanning in background and wait for the next wake-up

​

1. 当信标不在射程内时，是否有可能从BluetoothLEScanner接收意图？

谢谢，弗拉德

Answer 1

以下是几个答案：

1. 启动立即扫描作业的50秒延迟是为了防止同时启动两个立即扫描作业的竞争条件。当您将背景模式设置为true时，它假设您正在更改背景模式，以便取消正在进行的任何立即扫描作业(仅为前台使用而设计)，以切换到没有扫描作业的后台操作。调度发生两次，因为第一个BeaconManager:startMonitoringBeaconsInRegion和BeaconManager:setBackgroundMode都触发了一个“重新调度”进程。您可以通过在您的init过程的早期先调用BeaconManager:setBackgroundMode:来避免这一切。这样，当您调用BeaconManager:startMonitoringBeaconsInRegion时，库已经处于后台模式，并且工作将更加顺利。
2. Android作业调度程序的工作方式是，如果在最频繁的(~15分钟)间隔内设置一个定期作业，它不会立即运行。因此，当库以后台模式启动时，在下一个间隔开始之前，它不会做任何事情。这个间隔可能很快，也可能长达25分钟。如果我们通过一些持久化的时间戳确定最后一个扫描作业已经很长时间没有运行，那么就可以通过调度立即扫描作业来优化这个过程。这是一个合理的优化，如果您感兴趣的话，可以通过准备拉请求将其添加到库中。
3. 库只在扫描周期完成后设置低功耗意图交付扫描，因为这是正常的操作过程。我同意，如果该应用程序被杀死，它不一定会尽快设置时，应用程序重新启动。对此进行优化的最简单方法是完成上文(2)中提出的优化，这将作为副作用解决这个问题。
4. 如果你不想损害距离估计的准确性，你希望你的硬件信标的发射功率尽可能高，你希望广告率尽可能高。每秒的数据包越少，可以处理的统计样本就越少，并且增加了距离估计中的噪声。较低的输出功率增加了相对于信号的噪声地板，并且在1米和10米的RSSI之间的可检测差值中，给出了很小的裕度。我理解高发射功率和高广告率会显著影响电池供电信标的使用寿命。然而，如果你降低发送器的功率，以节省电池，或者降低低于5赫兹的广告率，那么你可能应该放弃距离估计。
5. 如何最好地使用库取决于您的用例。如果每隔15分钟进行一次扫描，对于用例来说就足够了，那么您可能应该坚持后台模式。我不确定您所描述的黑客是否能够使库在不进行修改的情况下按照您的要求运行。您可以尝试，但最终可能要花费更多的时间，而不是像上面第(2)点所描述的那样简单地进行更改。
6. 从理论上讲，Android确实支持硬件支持的API，支持与信标消失相关的快速回调。然而，不幸的是，Android的Doze特性使得这对于大多数用例来说都是不可靠和毫无价值的。请参阅我对这个这里的工作总结