为啥 locationmanager 使用新的 gettime-timestamp 返回旧的位置修复？

Posted 2023-04-14

【中文标题】为啥 locationmanager 使用新的 gettime-timestamp 返回旧的位置修复？

【英文标题】：Why is locationmanager returning old location fixes with new gettime-timestamp?为什么 locationmanager 使用新的 gettime-timestamp 返回旧的位置修复？

【发布时间】：2011-11-30 16:23:58

【问题描述】：

我们有一个应用程序，它会根据用户操作尝试获取位置修复。它同时在 GPS 和网络上进行侦听，并具有基于时间/准确性的决策矩阵来确定何时停止侦听以及返回什么修复。

我们有时会注意到一种非常奇怪的行为。我们使用经典的方法来查看修复的历史，如下所示：

long age = now - newLocation.getTime();
if(age >= prefs.getLocationMaxAge())
    Log.d(TAG, "location too old.");
    return;

但有时，根据返回的时间戳，从操作系统返回的 location.getTime 的年龄可能为 15-20 秒，尽管我们可以确定它已经很老了。例如，如果经度/纬度定位来自 30 分钟前手机所在的位置！

这似乎是通过 Wi-Fi 和网络发生的，但不是 GPS。对我来说，这完全是疯狂的。有没有其他人看到过这个，有什么办法可以解决吗？

我们已经在几部不同的手机上获得了它，最近的一部是Samsung Galaxy S II。

非常欢迎帮助。

编辑：要非常清楚，问题是操作系统调用了“onlocationchanged”回调，其时间戳年龄可能为几秒钟，当我确定时“新”修复中的经度/纬度是手机至少 30 分钟未使用的地方。

这使得准确确定手机的位置有点困难......

【参考方案1】：

这似乎来自 Wi-Fi 和网络，但不是 GPS

这似乎很公平，因为在基于 Wi-Fi 和网络蜂窝站点的三角测量中，准确性非常差。他们可能正在使用可以追溯到 30 分钟前的缓存位置。除非您没有更改您的蜂窝站点或移动到另一栋建筑物以便可以发现新的APs，否则恐怕您只会得到缓存的位置。如果您想要新的位置，请使用 GPS 提供商。

【讨论】：

我认为你没有理解我的意思。如果位置的时间戳能反映这一点，缓存位置就可以了。但是采用缓存的旧修复程序并应用当前时间戳是疯狂的。我会更新我的问题，使其更加清晰。

感谢您的清理；我找到了the culprit

嗨 Guyz ，相对于此，我得到了正确的位置，但是当我尝试使用 ->> long age = System.currentTimeMillis() -location.getTime(); 找到这个位置时并根据这个值计算我的位置，但问题是有时我得到负值（年龄）。无法理解为什么，因为那个年龄永远不会消极