Android FusedLocationProviderClient 突然不再触发位置回调的问题求助

一、是否存在高频调用触发的配额/限制 #

• 谷歌融合定位没有公开的按调用次数的硬配额，但存在系统级自动节流机制：
  • 当应用短时间内高频发起PRIORITY_HIGH_ACCURACY高精度定位请求时，系统会判定为占用GPS硬件资源的滥用行为，自动丢弃部分请求、降低定位优先级
  • 该节流阈值无公开文档，但实测单次高精度请求间隔小于1s时，很容易触发你遇到的「约15次调用1次成功」的随机丢弃现象
  • 此前调用频率低未触发，新功能上线后高频调用刚好命中节流逻辑，完全符合观测特征

二、代码层面的核心诱因（优先级高于系统节流） #

1. 全局复用同一locationCallback且未主动移除注册 #

• 你的代码中locationCallback是单例对象，每次调用getUpdatedLocation都会执行requestLocationUpdates传入同一实例
• 谷歌融合定位内部会对「相同callback的重复注册」做去重：如果上一次注册的请求还未触发（或刚触发未完全清理），新的请求会直接覆盖旧请求，甚至被判定为重复调用直接丢弃
• setNumUpdates(1)虽然会在回调后自动移除注册，但这个清理过程是异步的，高频调用时很容易出现清理未完成就发起新注册的冲突

2. 全局复用同一个subject导致订阅冲突 #

• 如果你的subject是全局单例的PublishSubject，多次调用getUpdatedLocation会返回同一实例
• 一旦回调触发一次，所有订阅者都会收到位置数据，但后续重复发起的定位请求因为callback复用问题根本不会触发新的回调，表现为间歇性成功
• 旧的订阅未及时取消的话，还会导致位置数据被推送到已经不需要的页面，加重资源占用

3. play-services-location 17.1.0的已知问题 #

• 该2020年发布的版本本身存在高频单次定位回调丢失的bug，尤其是搭配setNumUpdates(1)使用时，回调丢失概率远高于后续版本
• 你当前用的17.1.0刚好是bug高发版本，和高频调用的问题叠加放大了故障概率

三、可直接落地的修复方案 #

• 每次发起定位请求前，先执行client.removeLocationUpdates(locationCallback)，确保上一次的注册完全清除后再发起新请求
• 每次回调触发后，手动调用removeLocationUpdates，不要依赖setNumUpdates(1)的自动清理逻辑
• 不要全局复用subject：每次调用getUpdatedLocation时创建新的Observable，通过Observable.create实现请求、订阅、清理的完整闭环，避免订阅冲突
• 给定位请求加本地节流逻辑：两次发起高精度定位的间隔不少于1.5s，避开系统节流阈值
• 升级play-services-location到21.0.1以上版本，该版本已修复17.x系列的高频回调丢失bug
• 临时调试可将setNumUpdates(1)替换为setExpirationDuration(10000)，避免无回调的残留请求堆积

四、补充说明 #

• lastLocation返回陈旧数据是上述问题的连锁反应：定位回调未触发时，系统不会更新位置缓存，lastLocation自然会返回旧数据
• 调用lastLocation预热无法提升成功率，是因为预热本身也属于定位请求，同样会被系统节流或注册冲突拦截

内容的提问来源于stack exchange，提问作者Dusty