1. 从LocationManager开始你的应用如何“感知”位置大家好我是老张在移动定位和智能硬件这块摸爬滚打了十来年。今天咱们不聊那些虚头巴脑的概念就来实实在在地扒一扒 Android 10 里你的手机到底是怎么知道“我在哪儿”的。整个过程就像一场精心策划的接力赛数据从最底层的硬件芯片出发经过层层传递和加工最终送到你的 App 手里。而这场接力赛的第一棒接棒员就是我们应用开发者最熟悉的LocationManager。很多刚接触 Android 定位开发的朋友可能觉得调用requestLocationUpdates拿到一个Location对象就完事了。但如果你做过高精度定位、运动轨迹记录或者车载导航这类对定位数据有更高要求的应用你肯定会遇到一些困惑为什么我拿到的位置有时候跳来跳去怎么才能获取更原始的卫星观测数据来做算法优化GnssMeasurement和GnssNavigationMessage这些听起来高大上的类到底是干嘛用的要解开这些疑惑我们必须深入这场接力赛的内部。在 Android 10 的架构里LocationManager绝不是一个简单的“传话筒”。它扮演着“经纪人”和“调度中心”的角色。你的应用客户端通过它来表达需求“我想要每秒一次的位置更新”、“我需要原始的卫星测量数据来做 RTK 解算”。LocationManager则负责把这些需求打包通过 Binder 跨进程通信机制告诉系统服务端的LocationManagerService“嗨有个应用需要这些数据请安排一下。”更重要的是LocationManager还管理着一系列回调传输器Callback Transport。这是理解整个流程的关键。系统服务端产生的数据比如新的位置、卫星状态变化、原始的 NMEA 语句是“汹涌而来”的而你的应用可能只需要其中的一部分或者需要以特定的方式比如批处理来接收。这些传输器就是专门负责“过滤”和“格式化”数据流的。例如当你调用registerGnssMeasurementsCallback时LocationManager内部就会创建一个GnssMeasurementCallbackTransport对象。这个对象封装了你的回调接口并作为一个 Binder 代理在系统服务那边“挂号”。从此来自 GNSS 芯片的原始观测值就会通过这个专属通道精准地送达你的应用。所以下次当你调用 LocationManager 的 API 时可以想象一下你并不是直接在和 GPS 芯片对话而是在和一位经验丰富的“经纪人”沟通。你告诉他你的需求他负责去和后台的“制作团队”系统服务协调资源并建立一条稳定的“数据配送专线”Callback Transport确保你收到的信息既及时又符合要求。这个初步的认知是我们深入后续复杂流程的基础。2. 深入LocationManager揭秘四大核心“数据通道”理解了LocationManager的“经纪人”角色后我们来看看它手底下到底有哪些关键的“数据通道”。在 Android 10 中针对 GNSS 数据主要设计了四类回调传输机制它们各自负责不同类型的数据满足从基础定位到高精度算法的不同需求。弄懂它们你就能像搭积木一样按需组合出强大的定位功能。2.1 GnssMeasurementCallbackTransport高精度定位的“原料仓库”这是我认为最强大、也最被低估的一个通道。很多开发者只知道用Location对象那个是已经加工好的“成品菜”包含了经纬度、精度、速度等。而GnssMeasurementCallbackTransport传递的GnssMeasurement对象则是做菜的“原始食材”。它里面包含什么每一颗可见卫星的原始观测数据。比如伪距Pseudorange卫星信号传播到手机的大概距离是计算位置的基础。载波相位Carrier Phase精度比伪距高好几个数量级是实现 RTK实时动态差分、PPK后处理动态差分等高精度定位技术的核心。简单理解伪距能告诉你大概在哪个街区载波相位能精确到厘米级告诉你站在人行道的哪块砖上。多普勒频移Doppler Shift用来计算速度非常精准。卫星ID、信号强度Cn0DbHz、时间戳等元数据。当你通过addGnssMeasurementsListener注册这个监听器后你的应用就能源源不断地收到这些原始数据。有什么用呢举个例子我们团队之前做农机自动驾驶的辅助系统手机作为移动站需要和远处的基准站数据进行差分计算。如果只用系统提供的Location精度最多几米拖拉机开沟都能开歪。但当我们自己处理GnssMeasurement数据结合基准站的校正信息进行 RTK 解算就能轻松实现亚米级甚至厘米级的定位让农机沿着预设路线笔直前进。这个通道就是把手机 GNSS 芯片的底层能力完全开放给开发者的钥匙。2.2 GnssNavigationMessageCallbackTransport卫星的“身份证”和“轨道说明书”如果说GnssMeasurement告诉你信号“什么时候”到的那么GnssNavigationMessageCallbackTransport传递的GnssNavigationMessage就告诉你信号是“从哪颗卫星”、“以什么轨道”发出来的。导航电文是卫星自己广播的“身份信息”和“运行手册”主要包含星历Ephemeris描述卫星自身精确位置、速度、时间的高精度参数有效期短几小时但定位时必须用到。历书Almanac所有卫星的大概轨道信息和健康状况精度低但有效期长几个月主要用于卫星快速搜索和可见性预测。你的手机在冷启动完全不知道天上卫星情况时需要先抓取导航电文这个过程就是“星历下载”可能需要几十秒。通过监听这个通道你可以直接拿到这些原始的电文数据。对于普通应用来说可能用处不大系统底层已经用它来解算位置了。但对于我们做定位算法研究、或者开发专业 GNSS 模拟测试工具的人来说这些原始电文数据至关重要。我们可以分析不同卫星星座GPS、北斗、GLONASS、Galileo的电文结构差异或者模拟特定卫星的故障场景来测试我们算法的鲁棒性。2.3 BatchedLocationCallbackTransport省电省流的“快递打包服务”频繁的位置更新意味着频繁的跨进程 Binder 调用和 App 进程唤醒这对手机电量是巨大的消耗。BatchedLocationCallbackTransport就是为了解决这个问题而生的“批处理”高手。想象一下外卖小哥不是每做一道菜就给你送一次而是等几道菜都做好了打一个包一次性送上门。这个传输器干的就是这个活儿。它会把一段时间内产生的多个连续位置点聚合成一个ListLocation然后通过一次回调传递给你的应用。系统会根据你的应用需求比如你是运动健身 App 需要高频记录还是天气 App 只需要低频更新以及手机本身的运动状态智能地调整这个“打包”的大小和频率。在 Android 10 上你可以通过LocationRequest的setMaxWaitTime()方法来暗示系统“我不急着要每一个点你可以攒一攒但最多攒 5000 毫秒给我送一次。” 这在后台持续记录轨迹的场景下省电效果非常明显。我实测过一个运动记录应用开启批处理模式后在相同轨迹记录精度下整机功耗下降了接近 15%。2.4 GnssStatusListenerTransport 与 NMEA系统状态的“实时播报员”最后这两个监听器更多是用于获取 GNSS 系统的状态信息和一种通用的原始数据格式。GnssStatusListenerTransport它告诉你 GNSS 引擎的状态变化。比如onGnssStarted()定位开始了、onGnssStopped()定位停止了、onFirstFix()首次定位成功这个回调对用户体验很重要以及最重要的onSvStatusChanged()可见卫星状态变化了。在onSvStatusChanged回调里你会拿到一个GnssStatus对象里面包含了当前天空中所有可见卫星的列表、它们的卫星号PRN、信噪比Cn0、是否被用于解算usedInFix等信息。你在很多地图 App 上看到的那个搜星图数据就来源于此。NMEA 监听器NMEA 0183 是一个古老的、文本格式的通用 GNSS 数据协议。它像是一份“电报”每行一条语句包含了位置、速度、时间、卫星信息等。比如$GPGGA语句就包含了最基础的定位结果。虽然系统已经为我们解析好了更结构化的Location和GnssStatus但直接读取 NMEA 在某些专业领域比如航海、航空设备对接仍然是必需的。它是最原始、最通用的数据流。这里我踩过一个坑也正好解释一下源码里一个有趣的设计。在LocationManager的registerGnssStatusCallback方法里你会发现每注册一个回调就会新建一个GnssStatusListenerTransport它是一个 Binder 对象并注册到服务端。这意味着如果你的 App 里多个模块都注册了状态监听就会建立多条 Binder 通道。如果回调非常频繁比如每秒一次这会对系统性能造成不必要的开销。所以在实际项目中我通常会设计一个单例的“定位数据中枢”由它来统一注册这些系统回调然后再分发给 App 内部各个需要的模块避免重复注册减少 Binder 通信负担。这种优化在需要高频更新卫星状态的应用如专业的测绘软件中效果显著。3. 穿越Binder数据如何抵达系统服务端数据从我们的 App 发出请求到LocationManager接手接下来就要进行一次关键的“跨界旅行”——从应用进程穿越到系统进程。这个边界的守护者就是 Android 的Binder 机制。理解这个过程能帮你更好地处理跨进程通信带来的延迟和异常。当你在 App 里调用locationManager.requestLocationUpdates()或者registerGnssMeasurementsCallback时你手里的locationManager对象实际上是一个代理Proxy。它并不是真正的实现者而是一个“代言人”。这个代言人通过 Binder 驱动将你的调用请求包括你的回调传输器CallbackTransport打包成一个Parcel对象发送给系统服务进程中的本体Stub。这个“本体”就是LocationManagerService简称 LMS。它是 Android 系统中所有定位相关请求的“总调度中心”运行在一个叫做system_server的核心进程里拥有更高的权限可以统一管理硬件资源、协调多个应用的竞争需求比如两个 App 同时要 GPSLMS 会决定如何分配。以注册一个 NMEA 监听器为例流程是这样的App 调用locationManager.addNmeaListener()。LocationManager创建一个OnNmeaMessageListener的传输器封装。通过 Binder调用到LocationManagerService的registerGnssStatusCallback方法NMEA 监听在底层也是通过状态监听接口实现的。LMS 中的addGnssDataListener方法会接手这个请求。它会进行一系列安全检查比如检查你的 App 有没有定位权限然后将你的 Binder 回调对象也就是那个传输器添加到一个专门的监听器列表里进行管理比如mGnssNmeaListeners。这里有个核心点你传递过去的GnssStatusListenerTransport本身是一个IGnssStatusListener.Stub对象。在 Binder 机制里Stub 对象是服务端实现功能的实体但它在客户端这边创建然后通过 Binder 传递到服务端服务端持有它的引用就可以直接回调它上面的方法如onSvStatusChanged。这就建立了一条从服务端到客户端的反向回调通道。LMS 的管理非常细致。它内部为不同类型的 GNSS 数据维护着不同的“监听器助手”Helper比如GnssStatusListenerHelper、GnssMeasurementsListenerHelper。这些 Helper 负责管理所有注册上来的客户端监听器列表。当底层的GnssLocationProvider这是 GNSS 功能的核心管理者我们稍后讲有新的数据比如卫星状态变化、新的 NMEA 句子上来时就会通知对应的 Helper。Helper 则遍历自己管理的监听器列表通过那条 Binder 回调通道将数据逐一发送给每一个感兴趣的客户端。这种设计的好处是解耦和高效。LMS 作为管理者不关心数据的具体产生逻辑GnssLocationProvider作为生产者不关心数据要发给谁。所有客户端的注册、注销、生命周期管理都由 LMS 和这些 Helper 统一负责确保了系统的稳定性和安全性。对于我们开发者而言需要记住的是所有通过LocationManager注册的回调其生命周期是和 LMS 中的记录绑定在一起的。如果 App 进程崩溃Binder 链接断开LMS 会检测到并自动清理对应的监听器防止内存泄漏。4. 核心引擎GnssLocationProvider承上启下的“翻译官”数据经过LocationManagerService的调度下一步就交给了定位功能真正的核心引擎——GnssLocationProvider简称 GLP。这个类不在system_server进程里而是运行在一个独立的com.android.location.fused进程或者类似的系统进程中。它是 Java 框架层与更底层的 C/HAL硬件抽象层进行交互的关键枢纽扮演着“翻译官”和“控制器”的角色。GLP 的工作非常繁重我把它总结为三大任务与 HAL 层对话它通过 JNIJava Native Interface调用底层的 C 代码向 GNSS 芯片发送启动、停止、注入时间/辅助数据等命令并接收从芯片上报的原始数据。数据处理与转换它将 HAL 层上报的、格式原始的 C/C 结构体数据“翻译”成 Java 层框架定义好的、更易用的对象。比如将原始的卫星观测值打包成GnssMeasurement数组将导航电文解析成GnssNavigationMessage或者将定位结果封装成Location对象。向上汇报将处理好的数据通过LocationManagerService提供的回调接口比如reportLocationreportSvStatus等通知给 LMS进而分发给所有注册的客户端。GLP 的初始化过程很有意思体现了 Android 系统对硬件兼容性的处理。在它的 JNI 层com_android_server_location_GnssLocationProvider.cpp有一个关键的class_init_native方法。这里面会尝试通过android_location_GnssLocationProvider_set_gps_service_handle来探测当前设备 HAL 层使用的 GNSS 服务版本。它的策略是“就高不就低逐步降级”首先尝试获取HAL 2.0的服务。这是较新的标准功能更强大。如果获取不到返回 null则认为设备不支持 2.0接着尝试获取HAL 1.1的服务。如果 1.1 也获取不到则默认使用最老的HAL 1.0服务。你可以通过adb shell在手机上验证你的设备用的是哪个服务adb shell ps -A | grep gnss或者adb shell ps -A | grep gps在输出中你可能会看到类似android.hardware.gnss2.0-service-qti高通平台或android.hardware.gnss1.1-service这样的进程名。这就是正在运行的 GNSS HAL 服务。GLP 就是和这个进程里的服务进行通信。这种设计保证了 Android 定位框架能够兼容不同年份、不同芯片厂商的设备。对于应用开发者来说这通常是透明的但如果你在做深度定制比如为特定硬件开发 ROM了解这一点有助于你定位一些 HAL 层兼容性问题。GLP 就像一个万能适配器无论底层是 USB 口还是 Type-C 口它都能想办法接上并把数据转换成统一的格式往上送。5. 潜入HAL层与硬件芯片的直接对话经过GnssLocationProvider的翻译和转发我们的请求终于抵达了这次接力赛的最后一棒——HAL 层Hardware Abstraction Layer硬件抽象层。这里是软件世界和硬件世界的边界是 Android 系统能够运行在成千上万种不同设备上的关键。HAL 层定义了一套标准的接口芯片厂商如高通、联发科、博通必须按照这个接口来实现他们自家 GNSS 芯片的驱动。这样上层的 Android 框架包括 GLP就不需要关心手机里用的到底是高通的 GPS 芯片还是北斗的芯片它只需要调用统一的 HAL 接口函数即可。在 Android 10 的时代主流的 GNSS HAL 接口版本是2.0和1.1。它们的定义文件位于hardware/interfaces/gnss/目录下。我们以 2.0 版本为例看看几个最核心的接口IGnss.hal这是主控制接口。框架通过它来执行最基本的操作比如interface IGnss { setCallback(IGnssCallback callback) generates (bool success); start() generates (bool success); stop() generates (bool success); injectLocation(GnssLocation location) generates (bool success); // ... 其他方法 };start()和stop()就是控制芯片开始/停止定位的“开关”。setCallback()则用于注册一个IGnssCallback这是 HAL 层向框架层上报数据的反向通道。IGnssCallback.hal这是数据上报的接口。当芯片有新的数据时就通过这里定义的方法回调给框架层。例如interface IGnssCallback { gnssLocationCb(GnssLocation location); gnssSvStatusCb(GnssSvStatus svStatus); gnssNmeaCb(uint64_t timestamp, string nmea); // ... 2.0 版本特别加强了测量值和导航电文的支持 gnssMeasurementCb(GnssData data); gnssNavigationMessageCb(GnssNavigationMessage message); };看到这些方法名是不是很眼熟是的gnssLocationCb上报的位置最终会变成Location对象gnssSvStatusCb上报的卫星状态最终会触发onSvStatusChangedgnssNmeaCb上报的字符串就是 NMEA 数据。而gnssMeasurementCb和gnssNavigationMessageCb正是高精度定位数据的源头。IGnssMeasurement.hal和IGnssNavigationMessage.hal在 HAL 2.0 中为了更高效地支持原始观测值和导航电文将它们从主回调中独立出来提供了专门的接口和回调通道。芯片厂商的具体实现通常放在vendor/厂商/平台/gps或hardware/厂商/gps目录下。例如高通的实现可能叫android.hardware.gnss2.0-service-qti。这个服务进程启动后会实现上述 HAL 接口并等待框架层GLP 通过 JNI来调用。数据流的终点当 GNSS 芯片通过天线接收到卫星信号解算出位置或原始数据后驱动层会调用 HAL 实现中对应的回调函数如gnssMeasurementCb。这个调用会穿越进程边界触发 GLP 中 JNI 层对应的回调函数。JNI 函数将 C 结构体数据转换为 Java 对象然后 GLP 调用 Java 方法如reportMeasurement将这些对象上报给LocationManagerService。LMS 再通过我们之前建立的 Binder 回调通道最终把数据分发到你的 App 中注册的GnssMeasurementCallbackTransport。一个完整的数据闭环就此形成。理解 HAL 层最大的意义在于当遇到一些棘手的、芯片相关的定位问题时比如某款机型搜星特别慢、RTK 数据不稳定你知道问题的可能根源在哪里。是 HAL 实现有 Bug还是芯片驱动本身的问题这时候查看厂商提供的 HAL 日志通常需要 eng 版本的系统或特定的调试命令就成为了解决问题的关键。而对于绝大多数应用开发者来说知道这条数据链的终点在这里知道 Android 为我们抽象了硬件的差异就已经足够了。我们只需要在框架层定义好的 API 范围内尽情地利用GnssMeasurement等数据去实现那些令人兴奋的高精度定位应用。