目前我正在开发一个应用程序来跟踪最终用户的动作以进行相应的操作。就像最终用户进入某些地理围栏区域时，会弹出一条通知，告诉他们一些与该地点相关的信息。
在像“Google Pixel”系列这样的手机中，大部分时间一切正常。顺便说一句，有时会有明显的延迟。
但在三星制造的设备中，即使最终用户位于地理围栏区域的中心，进入或退出地理围栏也不会按预期触发。此外，在从“FusedLocationProviderClient”接收到位置更新后，我在日志控制台中打印当前位置。我的位置显示我现在正处于地理围栏中。
但是当最终用户关闭并打开 wifi 时，就会触发地理围栏事件。这个技巧大部分时间都能胜任。
这是我的问题：
有没有办法让我们调试地理围栏功能？这样我们就可以知道到底发生了什么。
能否请你们解释一下地理围栏功能的工作原理？更多细节将使我们免于黑洞。谢谢。
有人可以为我提供有关地理围栏问题的 Google 支持团队的电话号码吗？
【问题讨论】：
为了帮助遇到同样问题的其他人，我想与你们分享伟大的谷歌团队的回应。
可能的原因
过去，一些移动 OEM 会进行一些过于激进的优化，以 降低功耗，并打破位置堆栈。这样的 优化通常在设备静止时启动，并导致 地理围栏接收错误的位置，然后导致错误的退出 事件。稍后，一个正确的定位结果会触发另一个 输入结果。这种位置跳跃和地理围栏事件 垃圾邮件破坏了许多基于地理围栏的基本用例。
所以我们在地理围栏方面添加了一些防御机制来 保护地理围栏免受错误的位置结果。当一个设备 是静止的，如果设备有活动的 Wi-Fi 连接，我们会停止 位置请求，如果准确度是，则忽略任何位置结果 不够高。当 Wi-Fi 连接发生变化时，无论是新的 已建立 Wi-Fi 连接，或设备失去 Wi-Fi 连接性，或设备在不同接入点之间漫游 在同一个 Wi-Fi 网络中，Geofencer 将立即发送 位置请求以检测设备是否刚刚进入或退出 地理围栏。
期待什么
因为当设备具有 Wi-Fi 连接时，我们不会对设备进行采样 设备静止时的位置。这意味着如果我们添加一个新的地理围栏 在用户当前位置附近，我们将无法接收 ENTER 事件，直到用户开始带着设备四处走动（不再 仍然），或 Wi-Fi 连接发生变化（断开连接，或 漫游）。如果用户长时间停留在同一个地方，我们 预计初始 ENTER 事件会延迟。
通常这种缺点对于现实生活中的用例来说不是问题。 因为当用户进入或退出地理围栏时，设备应该 始终处于“移动”状态。换句话说，我们不应该期望 当设备静止时触发地理围栏事件。如果我们想要 在设备静止时强制触发地理围栏事件， 关闭和重新打开 Wi-Fi 将是调试的解决方法 目的。
为什么三星设备表现更差？
总而言之，当设备静止且具有活动 Wi-Fi 时 连接，Geofence 将主动停止采样设备位置， 我们预计新添加的地理围栏会有更长的延迟 对于初始事件。但是，根据贵公司的说法，某些设备可以 仍然得到地理围栏事件。背后的原因是，我们可能有 设备上运行的一些其他应用程序也请求位置 偶尔。尽管 Geofencer 不要求位置，但它可以 如果仍然使用其他应用程序请求的被动位置结果 定位结果被认为“足够精确”。
我们希望所有手机型号的行为一致。然而， 根据贵公司的说法，三星设备的问题似乎比 其他移动设备。我们要求贵公司提供错误报告。并且从 错误报告，我们观察到当设备移动时，FLP 位置 结果相当准确。精度圈通常在15以下 米：
08-17 14:29:39 location=Location[fused lat,lng hAcc=13 ] 08-17 14:30:01 location=Location[fused lat,lng hAcc=15 ] 08-17 14:31:39 location=Location[fused lat,lng hAcc=14 ] 08-17 14:32:07 location=Location[fused lat,lng hAcc=14 ] 08-17 14:33:39 location=Location[fused lat,lng hAcc=14 ] 08-17 14:34:02 location=Location[fused lat,lng hAcc=14 ] 08-17 14:34:23 location=Location[fused lat,lng hAcc=14 ] 08-17 14:34:43 location=Location[fused lat,lng hAcc=13 ] 08-17 14:35:39 location=Location[fused lat,lng hAcc=14 ] 08-17 14:36:02 location=Location[fused lat,lng hAcc=13 ]但是当设备静止一段时间，并且位置 要求，精度圈变得更大。通常超过 30米，有时大于40米：
08-17 17:14:18 location=Location[fused lat,lng hAcc=43 ] 08-17 17:15:13 location=Location[fused lat,lng hAcc=43 ] 08-17 17:15:18 location=Location[fused lat,lng hAcc=43 ] 08-17 17:17:18 location=Location[fused lat,lng hAcc=43 ] 08-17 17:19:18 location=Location[fused lat,lng hAcc=43 ] 08-17 17:21:24 location=Location[fused lat,lng hAcc=43 ] 08-17 17:21:56 location=Location[fused lat,lng hAcc=43 ]还有：
08-17 17:24:45 location=Location[fused lat,lng hAcc=39 ] 08-17 17:27:27 location=Location[fused lat,lng hAcc=39 ] 08-17 17:28:11 location=Location[fused lat,lng hAcc=39 ] 08-17 17:32:03 location=Location[fused lat,lng hAcc=39 ] 08-17 17:34:10 location=Location[fused lat,lng hAcc=39 ] 08-17 17:38:11 location=Location[fused lat,lng hAcc=39 ]当被动位置不够准确时，Geofencer 会 只需删除它们，并且不会使用它们来计算地理围栏事件。 我们在其他制造商的设备上没有看到类似的行为。
如何解决问题？
正如我们之前所描述的，通常在现实生活中使用它不是问题 案例。当用户进入或退出地理围栏时，设备应 总是有运动。此外，当用户进入或离开家或 工作场所，很可能会发生 Wi-Fi 连接变化， 这可能会导致立即位置请求并触发 相应的地理围栏很快。所以我们不需要做任何事情 特别是在生产设备上解决此问题，即使对于 三星。唯一的问题是新添加的初始事件 地理围栏。如果客户端应用程序关心这些事件，并且不能 容忍初始延迟，客户端应用程序可以请求位置 自己检测它是否在任何新添加的地理围栏内。
在进行调试时，调试设备很可能是 仍然，并且有有效的 Wi-Fi 连接。所以 Wi-Fi 切换技巧 可以帮助很多。这个技巧的另一个优点是，当使用模拟 调试地理围栏客户端应用程序的位置，地理围栏通常会拒绝 模拟位置。使用 Wi-Fi 切换技巧并强制 Geofencer 使用模拟位置。
地理围栏方面未来可能发生的变化
无法触发初始地理围栏事件将是一个问题 对于某些用例。我们可能会更新 Geofence 以允许初始 即使设备处于正常状态，地理围栏事件也会被正确触发 仍然。所以将来我们可能不再需要在 客户端应用程序计算初始事件。
但是，能够触发初始地理围栏事件并不意味着 初始地理围栏事件将始终立即触发。 为了避免以过高的速度请求位置，我们将 添加新地理围栏时，切勿立即请求位置。 相反，我们只会以受限制的速率安排位置请求。所以 初始地理围栏事件仍会延迟几分钟 即使在我们未来的升级之后也是如此。
【讨论】：