在纽约市发布基于位置的应用：地铁死区、城市峡谷，以及真正有效的方案

Source: Dev.to

📍 为什么纽约市会破坏“普通”定位功能

NYC 有三种反复出现的故障模式：

1. 地铁死区 – 连接会中断，然后以突发的方式恢复。
2. 城市峡谷 GPS 漂移 – 高楼导致多路径和错误定位，产生抖动的标记、突发的方向翻转，以及“在街道错误侧面”的问题，严重影响叫车和路径规划。
3. 后台现实 – 操作系统的后台限制意味着“实时”是预算，而不是承诺。过度采样会消耗电池并被系统终止。

解决方案不是“获取更好的 GPS”。解决方案是 在数据变得混乱时，仍让用户体验保持可信。

🎯 从产品目标开始：可靠的用户体验，而非完美的准确性

在动代码之前，先决定每个功能的“足够好”标准：

一个简单且有效的方法

1. 为每个功能定义可接受的误差范围（例如，“nearby”30 m，“pickup”10 m，“city‑level”100 m）。
2. 如果定位结果超出该范围，不要假装你拥有最新的定位——展示降级体验（见下文“stale but honest” UI）。

📊 构建位置置信度分数（并以此控制 UI）

原始的经纬度信息不足。至少需要跟踪：

• accuracy（米）
• speed（米/秒）
• heading（度）
• provider / source（如有）
• timestamp

然后计算一个轻量级的置信度等级：

# Example confidence logic
if accuracy_m  50:
    ignore = True               # reject terrible fixes
else:
    points.append(new)
    smoothed = average(points[-5:])   # moving average of last 5 points

• 拒绝精度极差的定位。
• 对最近的 N 个点使用移动平均。
• 使用速度和方向来忽略明显的突变。

第 2 阶段 – 选择性捕捉（受保护的地图匹配）

捕捉对道路上的车辆有用，但对行人、公园、广场以及密集街区则可能带来风险。

防护措施

• 仅在置信度高时才进行捕捉。
• 仅当偏差 ≤ 某阈值（例如 ≤ 20 米）时才捕捉。
• 如果捕捉会导致相对于最近移动的向后跳跃，则绝不捕捉。

如果进行捕捉，请平滑动画并保持一致。随机捕捉会让人感觉像是 bug。

🔋 背景与电池：像预算一样对待更新

如果你的应用“持续更新”，操作系统最终会将其杀死。

良好模式

• 事件驱动的更新（在可能的情况下）。
• 动态限流——在积极导航时更快更新，空闲时更慢。
• 将 “主动跟踪” 模式与 被动 模式分离。

示例规则集

通过对更新进行预算，你可以保持在操作系统限制范围内，节省电池，并仍然提供可靠的用户体验——即使在纽约市的钢筋混凝土丛林中也是如此。

NYC 测试检查清单（大多数团队会跳过的部分）

保持 UI 稳定。 稍有延迟但看起来流畅的更新胜过高频混乱。

在测试 NYC‑like 条件之前不要宣称已完成

不仅仅是快速绕街区走一圈。

能揭露真实问题的路线

• Midtown avenues – 高楼峡谷
• A bridge approach and crossing – GPS + 速度边缘情况
• A park segment – 快速出现的捕捉错误
• Subway segment – 带有重新连接突发

测试期间需要衡量的指标

• % of updates 的高 / 中 / 低置信度
• Average accuracy 与年龄
• Snap‑delta distribution（捕捉偏移的分布）
• “Teleport” events（短时间内的大幅跳跃）
• ETA error drift 随时间的漂移

如果您需要真实的 NYC 现场测试以及生产级别的位置可靠性，与经验丰富的 mobile app developers in New York 合作可以节省数周的猜测时间。

实际上可以修复的日志记录内容

如果看不到，就无法修复。

至少，在获得用户同意并明确保留规则的前提下，记录以下信息：

• accuracy_m, age_s, provider
• speed, heading
• background vs foreground state
• confidence level
• snap delta（如果启用捕捉）
• network state（online / offline）

然后构建一个简易的事件处理手册：

• 如果瞬移事件激增，检查精度过滤和捕捉阈值。
• 如果在市中心的大部分置信度偏低，降低用户体验，而不是假装一切正常。
• 如果电池投诉增加，检查后台采样和“始终开启”行为。

底线

NYC 将会暴露你在定位方面的每一个捷径。

如果你采用以下方式构建：

• 信心门控，
• 离线优先思维，
• 捕捉前进行平滑处理，且
• 现实的后台预算，

你的应用将不再显得脆弱。你仍然会得到混乱的数据，但你将不再让混乱的数据主导用户体验。