MozStumbler数据管道详解从观测点到MLSIchnaeaJSON序列化、压缩与批量上报【免费下载链接】MozStumblerAndroid Stumbler for Mozilla项目地址: https://gitcode.com/gh_mirrors/mo/MozStumblerMozStumbler 是 Mozilla 推出的 Android 信号勘测应用Android Stumbler for Mozilla它会持续扫描手机周围的 Wi-Fi 与蜂窝基站结合 GPS 定位生成观测点再经过 MLSIchnaeaJSON 序列化、gzip 压缩、批量打包后上报给 Mozilla 的 MLS 位置服务用于完善全球 Wi-Fi 与基站定位数据库。本文带你完整走一遍 MozStumbler 数据管道的四个阶段观测点聚合 → JSON 序列化 → 压缩落盘 → 批量上报。一、数据管道总览一个观测点的旅程整个数据流可以概括为下面这条链路每个阶段都有独立的源码模块负责阶段做什么关键源码1️⃣ 观测点聚合监听 Wi-Fi、基站、GPS、气压广播攒成一个StumblerBundlelibraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/stumblerthread/Reporter.java2️⃣ JSON 序列化将StumblerBundle转为 Ichnaea 规范的 MLS geosubmit JSONStumblerBundle.java中的toMLSGeosubmit()3️⃣ 批量压缩落盘攒够 50 条观测点后序列化为{items:[...]}并 gzip 压缩datahandling/base/JSONRowsObjectBuilder.java、utils/Zipper.java4️⃣ 批量上报异步将压缩字节流 POST 到 MLS geosubmit 接口core/http/MLSLocationService.java、uploadthread/AsyncUploaderMLS.java下面按顺序拆解。二、观测点聚合Reporter 如何攒出一批信号数据管道的起点是Reporter类libraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/stumblerthread/Reporter.java。它本质上是一个广播接收器startup()中注册了四类广播Wi-Fi 扫描结果WifiScanner.ACTION_WIFIS_SCANNED基站扫描结果CellScanner.ACTION_CELLS_SCANNEDGPS 位置更新GPSScanner.ACTION_GPS_UPDATED气压传感器数据PressureScanner.ACTION_PRESSURE_SCANNED工作流程非常直观GPS 每次给出新定位就新建一个StumblerBundle把该位置作为锚点之后的 Wi-Fi / 基站扫描结果不断挂到这个StumblerBundle上GPS 信号丢失、或单点信号数达到上限时调用flush()把当前观测点封口交给存储层。为了防止内存膨胀StumblerBundlelibraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/stumblerthread/datahandling/StumblerBundle.java内置了两个硬上限单个观测点最多200 个 Wi-Fi 接入点MAX_WIFIS_PER_LOCATION单个观测点最多50 个蜂窝基站MAX_CELLS_PER_LOCATION超过上限就提前flush()保证数据不丢。三、MLSIchnaeaJSON 序列化把观测点翻译成标准格式flush()的核心是调用StumblerBundle.toMLSGeosubmit()把观测点转换为符合 Ichnaea 规范的 JSON 对象封装在MLSJSONObject中datahandling/MLSJSONObject.java注释中明确说明它是Ichnaea JSON 规范的便捷访问层。字段的键名统一定义在datahandling/DataStorageConstants.java的ReportsColumns中例如经纬度latitude/longitude精度截断到小数点后 6 位时间戳timestamp基站列表cellTowersWi-Fi 列表wifiAccessPoints每个条目含macAddress、frequency、signalStrength、age附加信息radioType、heading、speed、pressure、accuracy、altitude一个序列化后的观测点大致长这样{ latitude: 39.9042, longitude: 116.4074, timestamp: 1700000000000, radioType: lte, cellTowers: [ { cellId: 123456, signalStrength: -85 } ], wifiAccessPoints: [ { macAddress: AA:BB:CC:DD:EE:FF, frequency: 2437, signalStrength: -62 } ] }Wi-Fi 的age字段是扫描时间与 GPS 时间的差值毫秒帮助服务端判断信号新鲜度是很好的工程细节。四、批量缓冲与 gzip 压缩50 条一攒1~5KB 一压单个观测点序列化后并不会立即发送而是先进入内存队列JSONRowsObjectBuilderdatahandling/base/JSONRowsObjectBuilder.java用ConcurrentLinkedQueue收集 JSON 行常量MAX_ROWS_IN_MEMORY 50表示内存中最多缓冲 50 条ReportBatchBuilderdatahandling/ReportBatchBuilder.java继承它重写finalizeToJSONRowsObject()调用generateJSON()拼出{items:[...]}结构再用Zipper.zipData()做 gzip 压缩libraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/utils/Zipper.java得到ReportBatchDataStorageManagerdatahandling/DataStorageManager.java管理内存 → 磁盘两级缓冲。注释里写得很清楚磁盘文件名自带元信息例如reports-t1406863343313-r4-w25-c7.gz其中t是时间戳、r是观测点数量、w是 Wi-Fi 数量、c是基站数量每个 .gz 文件通常只有1~5KB。磁盘容量也有保护机制DataStorageConstants.java默认库场景上限 250 KiB / 2 周独立 App 场景放宽到 20 MB / 4 周超期数据会被整体清除作为隐私保护。五、批量上报压缩字节流直达 MLS 服务上报由独立的上传线程完成核心是MLSLocationServicelibraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/core/http/MLSLocationService.java提交地址是 MLS 的geosubmit接口源码中为location.services.mozilla.com/v1/geosubmit带上 Mozilla API Keysubmit(byte[] data, ..., boolean precompressed)的precompressed参数正是为数据管道服务的——因为批次已经是 gzip 字节流POST 时可以直接标记已预压缩省去服务器二次处理调度上由uploadthread/UploadAlarmReceiver.java的闹钟触发周期性上传AsyncUploaderMLS.java逐批取出getNextBatch()返回的批次发送每成功上传一批DataStorageManager.incrementSyncStats()会把bytes_sent、observations_sent、wifis_sent、cells_sent等统计持久化到PersistedStats这些数字最终展示在 App 的设置/关于页面里。值得称赞的一点如果网络足够活跃、上报速度跟得上数据可以全程只在内存里流转mCachedReportBatches→mCurrentReportsSendBuffer完全不产生磁盘 I/O。六、本地调试如何跑起 MozStumbler 验证数据管道 ️想亲自跑一遍项目验证上述流程可以用仓库根目录的 Makefile 直接执行make构建调试版构建系统会自动拉取所需 SDK。若使用 Android Studio推荐按 README.md 配置一个 Gradle-Aware Make 运行配置Build Tasks 填:android:assembleGithubDebug与:android:installGithubDebug并将 Installation Options 设为 Deploy Nothing配置完成后直接运行即可把调试版装到设备结合开发者选项页里的队列计数QueuedCountsTracker可以实时观察观测点攒批 → 落盘 → 上报的全过程。小结MozStumbler 的数据管道是一个教科书级的移动端数据工程范例广播驱动采集→上限保护聚合→Ichnaea 标准序列化→50 条批量 gzip 压缩→可离线重试的批量上报每一环都有明确的容量约束和统计可观测性。如果你想给自己的 App 设计信号采集与上报模块这条攒批、压缩、预压缩上传的链路非常值得参考。【免费下载链接】MozStumblerAndroid Stumbler for Mozilla项目地址: https://gitcode.com/gh_mirrors/mo/MozStumbler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MozStumbler数据管道详解：从观测点到MLS（Ichnaea）JSON序列化、压缩与批量上报
MozStumbler数据管道详解从观测点到MLSIchnaeaJSON序列化、压缩与批量上报【免费下载链接】MozStumblerAndroid Stumbler for Mozilla项目地址: https://gitcode.com/gh_mirrors/mo/MozStumblerMozStumbler 是 Mozilla 推出的 Android 信号勘测应用Android Stumbler for Mozilla它会持续扫描手机周围的 Wi-Fi 与蜂窝基站结合 GPS 定位生成观测点再经过 MLSIchnaeaJSON 序列化、gzip 压缩、批量打包后上报给 Mozilla 的 MLS 位置服务用于完善全球 Wi-Fi 与基站定位数据库。本文带你完整走一遍 MozStumbler 数据管道的四个阶段观测点聚合 → JSON 序列化 → 压缩落盘 → 批量上报。一、数据管道总览一个观测点的旅程整个数据流可以概括为下面这条链路每个阶段都有独立的源码模块负责阶段做什么关键源码1️⃣ 观测点聚合监听 Wi-Fi、基站、GPS、气压广播攒成一个StumblerBundlelibraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/stumblerthread/Reporter.java2️⃣ JSON 序列化将StumblerBundle转为 Ichnaea 规范的 MLS geosubmit JSONStumblerBundle.java中的toMLSGeosubmit()3️⃣ 批量压缩落盘攒够 50 条观测点后序列化为{items:[...]}并 gzip 压缩datahandling/base/JSONRowsObjectBuilder.java、utils/Zipper.java4️⃣ 批量上报异步将压缩字节流 POST 到 MLS geosubmit 接口core/http/MLSLocationService.java、uploadthread/AsyncUploaderMLS.java下面按顺序拆解。二、观测点聚合Reporter 如何攒出一批信号数据管道的起点是Reporter类libraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/stumblerthread/Reporter.java。它本质上是一个广播接收器startup()中注册了四类广播Wi-Fi 扫描结果WifiScanner.ACTION_WIFIS_SCANNED基站扫描结果CellScanner.ACTION_CELLS_SCANNEDGPS 位置更新GPSScanner.ACTION_GPS_UPDATED气压传感器数据PressureScanner.ACTION_PRESSURE_SCANNED工作流程非常直观GPS 每次给出新定位就新建一个StumblerBundle把该位置作为锚点之后的 Wi-Fi / 基站扫描结果不断挂到这个StumblerBundle上GPS 信号丢失、或单点信号数达到上限时调用flush()把当前观测点封口交给存储层。为了防止内存膨胀StumblerBundlelibraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/stumblerthread/datahandling/StumblerBundle.java内置了两个硬上限单个观测点最多200 个 Wi-Fi 接入点MAX_WIFIS_PER_LOCATION单个观测点最多50 个蜂窝基站MAX_CELLS_PER_LOCATION超过上限就提前flush()保证数据不丢。三、MLSIchnaeaJSON 序列化把观测点翻译成标准格式flush()的核心是调用StumblerBundle.toMLSGeosubmit()把观测点转换为符合 Ichnaea 规范的 JSON 对象封装在MLSJSONObject中datahandling/MLSJSONObject.java注释中明确说明它是Ichnaea JSON 规范的便捷访问层。字段的键名统一定义在datahandling/DataStorageConstants.java的ReportsColumns中例如经纬度latitude/longitude精度截断到小数点后 6 位时间戳timestamp基站列表cellTowersWi-Fi 列表wifiAccessPoints每个条目含macAddress、frequency、signalStrength、age附加信息radioType、heading、speed、pressure、accuracy、altitude一个序列化后的观测点大致长这样{ latitude: 39.9042, longitude: 116.4074, timestamp: 1700000000000, radioType: lte, cellTowers: [ { cellId: 123456, signalStrength: -85 } ], wifiAccessPoints: [ { macAddress: AA:BB:CC:DD:EE:FF, frequency: 2437, signalStrength: -62 } ] }Wi-Fi 的age字段是扫描时间与 GPS 时间的差值毫秒帮助服务端判断信号新鲜度是很好的工程细节。四、批量缓冲与 gzip 压缩50 条一攒1~5KB 一压单个观测点序列化后并不会立即发送而是先进入内存队列JSONRowsObjectBuilderdatahandling/base/JSONRowsObjectBuilder.java用ConcurrentLinkedQueue收集 JSON 行常量MAX_ROWS_IN_MEMORY 50表示内存中最多缓冲 50 条ReportBatchBuilderdatahandling/ReportBatchBuilder.java继承它重写finalizeToJSONRowsObject()调用generateJSON()拼出{items:[...]}结构再用Zipper.zipData()做 gzip 压缩libraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/utils/Zipper.java得到ReportBatchDataStorageManagerdatahandling/DataStorageManager.java管理内存 → 磁盘两级缓冲。注释里写得很清楚磁盘文件名自带元信息例如reports-t1406863343313-r4-w25-c7.gz其中t是时间戳、r是观测点数量、w是 Wi-Fi 数量、c是基站数量每个 .gz 文件通常只有1~5KB。磁盘容量也有保护机制DataStorageConstants.java默认库场景上限 250 KiB / 2 周独立 App 场景放宽到 20 MB / 4 周超期数据会被整体清除作为隐私保护。五、批量上报压缩字节流直达 MLS 服务上报由独立的上传线程完成核心是MLSLocationServicelibraries/stumbler/src/main/java/org/mozilla/mozstumbler/service/core/http/MLSLocationService.java提交地址是 MLS 的geosubmit接口源码中为location.services.mozilla.com/v1/geosubmit带上 Mozilla API Keysubmit(byte[] data, ..., boolean precompressed)的precompressed参数正是为数据管道服务的——因为批次已经是 gzip 字节流POST 时可以直接标记已预压缩省去服务器二次处理调度上由uploadthread/UploadAlarmReceiver.java的闹钟触发周期性上传AsyncUploaderMLS.java逐批取出getNextBatch()返回的批次发送每成功上传一批DataStorageManager.incrementSyncStats()会把bytes_sent、observations_sent、wifis_sent、cells_sent等统计持久化到PersistedStats这些数字最终展示在 App 的设置/关于页面里。值得称赞的一点如果网络足够活跃、上报速度跟得上数据可以全程只在内存里流转mCachedReportBatches→mCurrentReportsSendBuffer完全不产生磁盘 I/O。六、本地调试如何跑起 MozStumbler 验证数据管道 ️想亲自跑一遍项目验证上述流程可以用仓库根目录的 Makefile 直接执行make构建调试版构建系统会自动拉取所需 SDK。若使用 Android Studio推荐按 README.md 配置一个 Gradle-Aware Make 运行配置Build Tasks 填:android:assembleGithubDebug与:android:installGithubDebug并将 Installation Options 设为 Deploy Nothing配置完成后直接运行即可把调试版装到设备结合开发者选项页里的队列计数QueuedCountsTracker可以实时观察观测点攒批 → 落盘 → 上报的全过程。小结MozStumbler 的数据管道是一个教科书级的移动端数据工程范例广播驱动采集→上限保护聚合→Ichnaea 标准序列化→50 条批量 gzip 压缩→可离线重试的批量上报每一环都有明确的容量约束和统计可观测性。如果你想给自己的 App 设计信号采集与上报模块这条攒批、压缩、预压缩上传的链路非常值得参考。【免费下载链接】MozStumblerAndroid Stumbler for Mozilla项目地址: https://gitcode.com/gh_mirrors/mo/MozStumbler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考