使用Google API的背景位置更新 - 融合位置提供商不准确

Question

我一直在使用GoogleApiClient进行基于间隔和置换的更新，对背景位置更新进行测试。经过几天的测试和分析，我发现了一些我没想到的输出变化。

1. 使用setInterval和setFastestInterval进行基于时间间隔的更新时，请说我已将时间间隔设置为 15分钟和最快时间间隔为 10分钟，90％的时间我在预期的时间间隔内获得更新（10到15分钟）。但有时我注意到更新所需的时间比指定的Interval长得多，例如，差异大约是30分钟和60分钟。关于为什么会有区别的任何想法？

2. 使用setMinimumDisplacement进行基于距离的更新时，比如说我已将置换设置为 200米，我只会在 固定点 （旅行时，即使超过200米也不提供更新），200米及以上。这是正常的吗？

我正在使用PendingIntent类型的位置请求，以便在BroadcastReceiver中接收位置更新，以便在后台进行位置更新。

fusedLocationProviderClient.requestLocationUpdates(locationRequest, pendingIntent);

测试时，位置服务 开启，位置模式 HIGH_ACCURACY 。

Answer 1

请参阅文档以获取LocationRequest API的正确行为。

LocationRequest Api documentation

从此文档：

• 应用程序无法指定LocationClient使用的确切位置来源，例如GPS。实际上，系统可能有多个位置源（提供者）正在运行，并且可能会将来自多个源的结果融合到一个Location对象中
• 来自ACCESS_COARSE_LOCATION而不是ACCESS_FINE_LOCATION的应用程序的位置请求将自动限制为较慢的间隔，并且位置对象将被混淆为仅显示粗略的准确度。
• 所有位置请求都被视为提示，您可能会收到更多/更不准确，比请求更快/更慢的位置

有关详细说明，请阅读上述链接的完整文档。

希望这个解释可以帮助你。

Answer 2

我找到了第二个问题的answer。文档说不建议将setMinimumDisplacement设置为0，但这是实际的技巧。设置为0时，它可以正常工作。

当有两个不同的LocationRequest（基于时间间隔和位移）时，它可以正常工作，因此一个设置不会影响另一个。

在上述情况下，首选前景服务，以便位置更新不会被操作系统杀死。