解读

面试官问“对比”，不是让你背数字，而是看你是否：

1. 知道三种定位在 Android 里的实现路径（HAL→Framework→Fused Location Provider）
2. 能把“精度-功耗-场景”三角关系讲清，并给出代码级调优思路
3. 结合国内 ROM 的“对齐唤醒、省电精灵、后台冻结”等现实限制，说明如何落地

一句话：既要理论指标，也要工程折中，还要能扛住国内厂商“魔改”后的坑。

知识点

1. Android 定位栈：GNSS HAL → GNSS Location Provider / Network Location Provider → Fused Location Provider API（FLP）
2. 功耗模型：GPS 持续 1 Hz 全星跟踪 ≈ 120–200 mA；网络定位单次 ≈ 15–30 mA；混合定位依赖 Google 算法（国内用高德/百度/厂商算法）做场景切换
3. 精度指标：开阔地 GPS 3–8 m RMS；网络定位基站 100–300 m、Wi-Fi 10–50 m；混合定位在“城市峡谷”利用 Kalman+地图匹配可到 5 m 内
4. 国内差异：GMS 缺失，Fused 由厂商 SDK 接管；后台定位必须弹窗“始终允许”；部分 ROM 把 GPS 芯片供电锁 5 min 就断
5. 调优 API：setPriority()、setInterval()、setMinUpdateDistanceMeters()、setMaxUpdateDelayMillis()；前台用 HIGH_ACCURACY，后台切 BALANCED_POWER；前台服务+可见通知保活
6. 耗电定位工具：dumpsys location、Systrace gps 通道、Battery Historian “GPS scanning” 栏、厂商功耗仪

答案

“从 Android 系统视角，我把定位拆成‘精度-功耗-实时性’三角，先说结论再讲落地。

精度：
GPS 单点开阔地 3–8 m，城市峡谷因多路径会飘到 20 m；网络定位基站 100–300 m，Wi-Fi 10–50 m；混合定位（Fused）利用 Kalman 滤波+地图匹配，能把城市场景压到 5–10 m，与 GPS 接近但收敛更快。

功耗：
GPS 芯片全星跟踪 120–200 mA，连续 1 Hz 跑 1 小时耗电约 12–15 %；网络定位单次 15–30 mA，批量 20 s 一次，一小时耗电 < 1 %；混合定位在 HAL 层做 duty-cycle，城市常驻 Wi-Fi/基站，户外自动切 GPS，实测同场景比纯 GPS 省 35–50 %。

国内落地：

1. 前台导航：Priority=HIGH_ACCURACY，interval=1 s，distance=0，必须挂前台服务+通知，否则 5 min 被系统断 GPS
2. 后台轨迹：Priority=BALANCED_POWER，interval≥30 s，distance≥50 m，利用被动回调（setMaxUpdateDelayMillis=2*interval）批量上报，降低唤醒
3. 保活策略：国内 ROM 对齐唤醒，把 GPS 和网络请求放进同一 AlarmManager 窗口；同时监听 POWER_SAVE_MODE，一旦进入省电就主动降级到 LOW_POWER 模式，防止被省电精灵冻结
4. 灰度验证：用 Battery Historian 看“GPS scanning”栏，目标后台 1 小时 GPS 累计时长 < 3 min；用厂商功耗仪验证电流峰值 < 80 mA

一句话：精度 GPS 最高，功耗网络最低，混合定位用系统算法做场景切换，在国内必须配合前台服务、省电模式监听和厂商对齐策略，才能把‘5 m 级精度’和‘小时级续航’同时做到。”

拓展思考

1. Android 14 引入“Location Privacy Indicator”常驻状态栏，用户对 GPS 敏感度高，如何设计“精度降级”弹窗，既合规又不打扰？
2. 折叠屏车载场景，大屏导航同时投屏副驾，GPS 天线被金属铰链遮挡，如何利用 SensorManager 的磁场/加速度做航位推算（DR）补偿？
3. 国内厂商把 Fused 换成自己服务，回调线程与 Google 不一致，导致 Hilt 注入的 LocationRepository 空指针，你会用哪种 Binder 死亡回调机制兜底？