使用 Google API 进行后台位置更新 - Fused Location Provider 不准确

Posted 2023-04-14

【中文标题】使用 Google API 进行后台位置更新 - Fused Location Provider 不准确

【英文标题】：Background Location updates using Google API - Fused Location Provider not accurate

【发布时间】：2018-06-02 21:01:33

【问题描述】：

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

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

在使用 setMinimumDisplacement 进行基于距离的更新时，假设我将 位移 设置为 200 米，我只能在 静止点（行驶时即使超过200米也不更新）200米及以上。这样正常吗？

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

fusedLocationProviderClient.requestLocationUpdates(locationRequest, pendingIntent);

在测试期间，定位服务开启，定位模式为HIGH_ACCURACY。

【问题讨论】：

我不能说正常行为，但我看到了与您类似的问题。老实说，答案是@Mitesh Vanaliya 从文档中引用的内容，所有位置请求都被视为提示，您可能会收到比请求更准确/更差，更快/更慢的位置。或者，套用一句，“你可以告诉我们你想要什么，我们有时会这样做，但最终我们会在我们想要的时候做什么”

如果你不想使用谷歌推荐的FusedLocationApi，你可以使用旧的LocationManager来获得更多的控制权。 Here 是一些关于如何做到这一点的信息。

我不想选择LocationListener，因为它会在应用程序终止时终止。即使应用程序终止，我也想获得位置更新，这就是为什么我选择PendingIntent 版本的FusedLocationProviderClient 的requestLocationUpdates。我从setInterval 获得的更新比setMinimumDisplacement 好得多，因为来自 setInterval 的位置比 setMinimumDisplacement 更准确。

由于我有一些基于用户行进距离的过程要完成，我希望它能够以至少 1 公里的精度提供位置更新。但是 setMinimumDisplacement 的问题是，它仅在用户停止某处时才提供更新。当用户连续旅行时，即使它超过指定的 MinimumDisplacement 范围，我也不会得到单个更新。是否有任何其他方法或实施可以确保我至少根据指定距离获得位置更新？

我的试验确实有类似的问题。查看我的问题和来自 SO ***.com/questions/35745924/…

的同胞的回答

【参考方案1】：

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

LocationRequest Api documentation

来自本文档：

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

所有位置请求都被视为提示，您可能会收到比请求更准确/更差、更快/更慢的位置

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

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

【讨论】：

感谢您的解释。我已经知道一些关于位置来源和准确性的信息。我期待有关问题中第二点的更多信息，例如，它是如何正常工作的？还是我必须为它实现更多代码。

【参考方案2】：

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

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

前台服务是上述场景的首选，这样位置更新不会被操作系统杀死。