尧图网页设计 
1、实时监控2、轨迹查询3、告警管理4、围栏设置5、看板与报表万级车辆实时地图 双模拟器车联网前端与测试工程实践第 3 篇 · 前端与测试前两篇讲了业务架构和后端链路。这篇讲数据到达前端之后的故事——也是整个系列里工程密度最高的一篇。车联网的前端不是一个后台 一个小程序就完事没有终端联调无从谈起。所以我们的前端体系是四位一体Web 管理端 小程序/H5 PC 模拟器 Android 模拟器。前两位是产品后两位是测试资产四位一体才构成一个能交付、能验收、能回归的完整工程。一、功能矩阵两端展示两台模拟器图3-1 业务架构图Web 管理端功能最全按三个域组织监控域监控大屏、实时监控地图、轨迹回放、宫格分组多车同屏管理域车辆档案、电子围栏、报警处理、运营报表视频与指令域视频墙轮巡 云台控制 对讲、历史录像回放、终端指令下发与台账小程序/H5聚焦移动看车实时定位、设备树、报警处理、轨迹查询、实时视频。一套 uni-app 代码双端产出——微信小程序用原生 map 组件H5 用 MapLibre 天地图。它的 WS 协议实现与 Web 端逐字平移——不是差不多是同一份逻辑同一份常量的完整复制两端行为严格一致。两台模拟器是测试体系的根基PC 模拟器Java 21 JavaFX AtlantaFX808/1078/809 三协议全模拟四个 808 协议版本多车批量压测JSON 剧本驱动HTTP 控制面8899 端口供自动化测试远程驱动Android 模拟器Kotlin Compose808 1078六种定位模式CSV 回放 / GPX 回放 / 真实 GPS / 手动驾驶等全量下行指令自动应答表能真拍照、真推流为什么模拟器敢拿去验收因为它们的协议编解码和后端用的是同一个 codec jar——模拟器行为 真终端行为。这不是口号是第 1 篇说的 codec 红线在前端测试域的延伸。二、核心难题上万辆车实时动怎么不卡先把问题定义清楚。监控大屏打开订阅上万辆车每台车 5~30 秒上报一次定位高峰期意味着每秒数百个位置更新穿过网络、穿过状态管理、最终变成地图上的像素移动。裸写的话每秒数百次 Vue 响应式更新 数百次 DOM/图层操作浏览器主线程直接卡死风扇起飞。答案是四级节流——不是一招是一条管线每一级把更新次数往下压一个量级图3-2 流程架构图第 1 级网络层检丢补全。自研 WS 协议里每帧带序号seq解帧时检查连续性。发现缺口怎么办注意位置是覆盖式状态——旧位置没有任何价值不需要逐条补。所以策略是缺口一旦检出直接走 REST 拉一次全量快照干净利落。另有两道保险心跳看门狗——2.5 个心跳周期收不到任何帧就判定假死TCP 半开连接的典型症状主动断开重连页签可见性监听——浏览器页签切到后台时渲染被冻结、定时器被节流切回前台时主动做一次快照校验补查。第 2 级订阅层引用计数。订阅来源是多方同时存在的设备树勾选了一批车、地图视野圈了一批车、报警列表又在跟踪几台车。三方的订阅集合有重叠。做法是给每台车维护引用计数任一来源订阅就 1全部退订才 -1 归 0 真正退订——谁退订都不影响其他订阅方。上行订阅帧分批发送每批不超过 2000 台避免单帧过大。第 3 级状态层批刷。WS 帧到达后不直接写响应式状态先进一个 100ms 的批刷队列到点一次性合并提交——一帧合批了 200 台车的更新也只触发一次 Vue 更新周期。车辆的尾迹车头后面拖着的小尾巴走非响应式环形缓冲固定 60 个点push 即覆盖完全不进 Vue 的依赖追踪系统。第 4 级渲染层 rAF 合批。地图图层操作按 50ms 节奏在 requestAnimationFrame 里合批执行。最重要的一条军规万级点位禁止逐台 new Marker——每台车一个 DOM 元素上万台就是上万个 DOM 节点必死。正确姿势是全量车辆走 MapLibre 的矢量图层GPU 渲染一次绘制只有用户选中的那台车单独挂一个真 Marker 承载点击弹窗。四级叠起来的效果网络层保证不重不漏订阅层保证只收该收的状态层把每秒数百次更新压成每秒 10 次提交渲染层再压成每秒 20 次绘制。每一级都在做同一件事合并同类项砍掉无意义的中间态。三、自研 WS 协议为什么不直接用裸 JSONWebSocket 本身只是管道上面跑什么格式得自己定。我们的协议极简上行浏览器 → 服务端订阅帧按车订阅、批量订阅 ping 心跳下行服务端 → 浏览器三种帧——单台位置帧、合批位置帧一帧打包 N 台车的最新位置整帧 ≤64KB、上下线通知帧三个设计取舍合批帧是性能关键。后端推送侧本身就按窗口聚合一帧推 200 台车只花一次帧头、一次解析、一次 JS 事件。如果一台一帧光帧解析的开销就能把主线程吃垮二进制友好。字段定长定序比 JSON 省流量也省解析时间。别迷信 JSON 的可读性——推送链路是机器读的可读性应该体现在文档和抓包工具上Web 端与小程序端逐字平移。协议的 TS 实现在两端是同一份逻辑的复刻帧常量、解析函数、心跳参数完全一致。一端改了协议另一端必须同步改这是纪律不是建议——两端行为不一致的 bug是联调阶段最贵的那类 bug四、四端四套技术栈四条契约绑成一个系统图3-3 技术架构图WebVue3 Vite MapLibre、小程序/H5uni-app wot-design-uni、PC 模拟器JavaFX、Android 模拟器Compose——四套技术栈各玩各的但四条共享契约谁也不能违反契约它消灭的问题codec 纯 jar编解码唯一实现四个进程共用模拟器能过真车不能过WS 协议契约Web 与小程序逐字平移两端行为不一致坐标纪律存储计算 WGS-84渲染边界才转 GCJ-02同车不同位置、轨迹漂移ID 纪律carId档案 ID≠ tid设备号字段命名强制区分张冠李戴指令发错车坐标纪律值得展开说因为它是车联网前端最高发的 bug 来源。国内地图坐标体系有三套GPS 原始的 WGS-84、国测局加密的 GCJ-02高德/腾讯/微信原生 map 用、百度再加密的 BD-09。坐标一旦在不同环节有的转了有的没转同一辆车在不同页面上能差出几百米。我们的纪律是单一口径 边界转换服务端存储、计算、推送只用 WGS-84天地图CGCS2000显示上与 WGS-84 可直接对齐免转换直接上图微信小程序原生 map 组件要 GCJ-02在数据进入 map 组件的最后一跳统一转换。任何中间环节禁止私自转换——转换函数在整个前端只有两个允许出现的位置。坐标错乱和 ID 混用这两类 bug 有个共同点不是能力问题是制度问题——从制度上让它们不可能发生比事后修便宜一百倍。五、数据模型三条线汇入一个状态源图3-4 数据架构图前端数据面三条线职责互不替代WS 帧管实时订阅上行、推送下行全双工只承载变化REST 管快照与历史设备树懒加载、地图全量快照配合缺口补全、历史轨迹抽稀、报警处理、视频信令——一切一次性、可重来的请求坐标流管渲染边界WGS-84 单一口径贯穿按端决定在不在最后一跳转 GCJ-02三条线都汇入同一个wsStore——全端唯一的车辆状态源再经批刷管线流向地图和列表。数据流单向、可追溯界面上任何一辆车的状态都能反推出它来自哪一帧、哪次快照、哪次合并。历史轨迹回放单独说一句原始轨迹点动辄几万个全画到地图上又卡又乱。服务端按地图缩放级别做抽稀——缩得越小点越少放得越大点越全配合回放时的速度曲线和报警点位标注取证场景既流畅又完整。六、视频链路浏览器播 H.265 的坎车载摄像头为了省流量大量采用 H.265 编码但浏览器原生不支持 H.265 硬解——这是车联网 Web 端绕不过去的坎。我们的方案容器与传输后端 1078 网关把 RTP 流转封装成 FLV浏览器走 WS-FLV6899 端口用 mpegts.js 解封装小程序走 HTTP-FLV6810 端口H.265 解码mpegts.js 解出的 H.265 裸流交给 h265webWASM 软解码器逐帧解码上屏。软解吃 CPU所以视频墙做了路数控制——同屏路数超过阈值时非焦点窗口自动降码流/降帧率焦点窗口保清晰对讲独立端口6805承载双向音频与视频流互不干扰视频墙还有个和后端呼应的设计用户切走页面或关闭窗口前端主动通知后端关流——配合后端30 秒无消费者自动回收双保险绝不让忘关的流烧流量。七、PC 模拟器多车压测与剧本回归PC 模拟器Java 21 JavaFX AtlantaFX是测试体系的重型武器四个能力三协议全模拟808 的定位/报警/指令应答、1078 的 RTP 推流读取本地视频文件打成 RTP 包、809 的下级平台行为一个进程全搞定四协议版本808 的 2011/2013/2019 等版本可逐车切换后端的多版本兼容性全靠它回归JSON 剧本把终端该干什么写成剧本——几点几分上线、沿某条路线行驶、行驶中触发超速报警、收到指令后延迟 N 秒应答。剧本可版本化管理测试用例就是代码HTTP 控制面8899创建/销毁车辆、启停剧本、注入报警全部可通过 HTTP 远程驱动——CI 里的自动化集成测试就是脚本调控制面 断言后端台账压测场景是这么跑的控制面批量创建几千台虚拟车 → 全部上线鉴权 → 按真实频率并发上报定位 → 观察全链路水位网关 CPU、MQ 堆积、PG 写入、WS 推送延迟→ 找到拐点确认余量。上线前的每一次容量结论都是模拟器压出来的不是拍脑袋拍的。八、Android 模拟器真机行为最后一块拼图PC 模拟器解决了量Android 模拟器Kotlin Compose解决真六种定位模式CSV 轨迹回放、GPX 回放、真实 GPS、手动驾驶摇杆控制方向速度等——既能复现固定路线做回归也能开着真车路测全量下行自动应答表每一类 0x8xxx 指令的应答行为都可在表里配置——立即应答/延迟应答/应答失败覆盖各种刁钻的终端行为真拍照、真推流用真机摄像头应答拍照指令、给 1078 推真实摄像头画面——这两件事 PC 模拟器只能用图片/文件模拟真机才能端到端验证交付验收的最后一环就是 Android 模拟器拿着手机在真实园区里跑一圈平台上看到的轨迹、视频、报警和真终端跑出来的逐条比对。它过不了的验收真终端一定也过不了。九、系列总结三篇文章一条主线第 1 篇五层架构 一条定位帧的业务闭环——骨架第 2 篇协议面/业务面分离 MQ 信封 Redis 路由 月分区——后端第 3 篇本篇四级节流渲染管线 四端四契约 双模拟器测试闭环——前端与测试回头看这套平台没有黑科技值钱的全是纪律协议与业务分离、codec 零依赖红线、坐标单一口径、看车不查库、订阅不互踢、更新必节流。这些纪律没有一条写在教科书上条条都是事故的学费。守住它们万级车辆实时监控用常规技术栈也能做得稳、做得久。如果这个系列对你有帮助欢迎点赞收藏评论交流。协议细节、渲染管线、模拟器设计哪块想深入聊的评论区见。文中部署地址、密钥、域名等敏感信息均已脱敏架构图为作者基于实际项目整理绘制。 万级车辆实时地图 + 双模拟器：车联网前端与测试工程实践（第 3 篇 · 前端与测试）
1、实时监控2、轨迹查询3、告警管理4、围栏设置5、看板与报表万级车辆实时地图 双模拟器车联网前端与测试工程实践第 3 篇 · 前端与测试前两篇讲了业务架构和后端链路。这篇讲数据到达前端之后的故事——也是整个系列里工程密度最高的一篇。车联网的前端不是一个后台 一个小程序就完事没有终端联调无从谈起。所以我们的前端体系是四位一体Web 管理端 小程序/H5 PC 模拟器 Android 模拟器。前两位是产品后两位是测试资产四位一体才构成一个能交付、能验收、能回归的完整工程。一、功能矩阵两端展示两台模拟器图3-1 业务架构图Web 管理端功能最全按三个域组织监控域监控大屏、实时监控地图、轨迹回放、宫格分组多车同屏管理域车辆档案、电子围栏、报警处理、运营报表视频与指令域视频墙轮巡 云台控制 对讲、历史录像回放、终端指令下发与台账小程序/H5聚焦移动看车实时定位、设备树、报警处理、轨迹查询、实时视频。一套 uni-app 代码双端产出——微信小程序用原生 map 组件H5 用 MapLibre 天地图。它的 WS 协议实现与 Web 端逐字平移——不是差不多是同一份逻辑同一份常量的完整复制两端行为严格一致。两台模拟器是测试体系的根基PC 模拟器Java 21 JavaFX AtlantaFX808/1078/809 三协议全模拟四个 808 协议版本多车批量压测JSON 剧本驱动HTTP 控制面8899 端口供自动化测试远程驱动Android 模拟器Kotlin Compose808 1078六种定位模式CSV 回放 / GPX 回放 / 真实 GPS / 手动驾驶等全量下行指令自动应答表能真拍照、真推流为什么模拟器敢拿去验收因为它们的协议编解码和后端用的是同一个 codec jar——模拟器行为 真终端行为。这不是口号是第 1 篇说的 codec 红线在前端测试域的延伸。二、核心难题上万辆车实时动怎么不卡先把问题定义清楚。监控大屏打开订阅上万辆车每台车 5~30 秒上报一次定位高峰期意味着每秒数百个位置更新穿过网络、穿过状态管理、最终变成地图上的像素移动。裸写的话每秒数百次 Vue 响应式更新 数百次 DOM/图层操作浏览器主线程直接卡死风扇起飞。答案是四级节流——不是一招是一条管线每一级把更新次数往下压一个量级图3-2 流程架构图第 1 级网络层检丢补全。自研 WS 协议里每帧带序号seq解帧时检查连续性。发现缺口怎么办注意位置是覆盖式状态——旧位置没有任何价值不需要逐条补。所以策略是缺口一旦检出直接走 REST 拉一次全量快照干净利落。另有两道保险心跳看门狗——2.5 个心跳周期收不到任何帧就判定假死TCP 半开连接的典型症状主动断开重连页签可见性监听——浏览器页签切到后台时渲染被冻结、定时器被节流切回前台时主动做一次快照校验补查。第 2 级订阅层引用计数。订阅来源是多方同时存在的设备树勾选了一批车、地图视野圈了一批车、报警列表又在跟踪几台车。三方的订阅集合有重叠。做法是给每台车维护引用计数任一来源订阅就 1全部退订才 -1 归 0 真正退订——谁退订都不影响其他订阅方。上行订阅帧分批发送每批不超过 2000 台避免单帧过大。第 3 级状态层批刷。WS 帧到达后不直接写响应式状态先进一个 100ms 的批刷队列到点一次性合并提交——一帧合批了 200 台车的更新也只触发一次 Vue 更新周期。车辆的尾迹车头后面拖着的小尾巴走非响应式环形缓冲固定 60 个点push 即覆盖完全不进 Vue 的依赖追踪系统。第 4 级渲染层 rAF 合批。地图图层操作按 50ms 节奏在 requestAnimationFrame 里合批执行。最重要的一条军规万级点位禁止逐台 new Marker——每台车一个 DOM 元素上万台就是上万个 DOM 节点必死。正确姿势是全量车辆走 MapLibre 的矢量图层GPU 渲染一次绘制只有用户选中的那台车单独挂一个真 Marker 承载点击弹窗。四级叠起来的效果网络层保证不重不漏订阅层保证只收该收的状态层把每秒数百次更新压成每秒 10 次提交渲染层再压成每秒 20 次绘制。每一级都在做同一件事合并同类项砍掉无意义的中间态。三、自研 WS 协议为什么不直接用裸 JSONWebSocket 本身只是管道上面跑什么格式得自己定。我们的协议极简上行浏览器 → 服务端订阅帧按车订阅、批量订阅 ping 心跳下行服务端 → 浏览器三种帧——单台位置帧、合批位置帧一帧打包 N 台车的最新位置整帧 ≤64KB、上下线通知帧三个设计取舍合批帧是性能关键。后端推送侧本身就按窗口聚合一帧推 200 台车只花一次帧头、一次解析、一次 JS 事件。如果一台一帧光帧解析的开销就能把主线程吃垮二进制友好。字段定长定序比 JSON 省流量也省解析时间。别迷信 JSON 的可读性——推送链路是机器读的可读性应该体现在文档和抓包工具上Web 端与小程序端逐字平移。协议的 TS 实现在两端是同一份逻辑的复刻帧常量、解析函数、心跳参数完全一致。一端改了协议另一端必须同步改这是纪律不是建议——两端行为不一致的 bug是联调阶段最贵的那类 bug四、四端四套技术栈四条契约绑成一个系统图3-3 技术架构图WebVue3 Vite MapLibre、小程序/H5uni-app wot-design-uni、PC 模拟器JavaFX、Android 模拟器Compose——四套技术栈各玩各的但四条共享契约谁也不能违反契约它消灭的问题codec 纯 jar编解码唯一实现四个进程共用模拟器能过真车不能过WS 协议契约Web 与小程序逐字平移两端行为不一致坐标纪律存储计算 WGS-84渲染边界才转 GCJ-02同车不同位置、轨迹漂移ID 纪律carId档案 ID≠ tid设备号字段命名强制区分张冠李戴指令发错车坐标纪律值得展开说因为它是车联网前端最高发的 bug 来源。国内地图坐标体系有三套GPS 原始的 WGS-84、国测局加密的 GCJ-02高德/腾讯/微信原生 map 用、百度再加密的 BD-09。坐标一旦在不同环节有的转了有的没转同一辆车在不同页面上能差出几百米。我们的纪律是单一口径 边界转换服务端存储、计算、推送只用 WGS-84天地图CGCS2000显示上与 WGS-84 可直接对齐免转换直接上图微信小程序原生 map 组件要 GCJ-02在数据进入 map 组件的最后一跳统一转换。任何中间环节禁止私自转换——转换函数在整个前端只有两个允许出现的位置。坐标错乱和 ID 混用这两类 bug 有个共同点不是能力问题是制度问题——从制度上让它们不可能发生比事后修便宜一百倍。五、数据模型三条线汇入一个状态源图3-4 数据架构图前端数据面三条线职责互不替代WS 帧管实时订阅上行、推送下行全双工只承载变化REST 管快照与历史设备树懒加载、地图全量快照配合缺口补全、历史轨迹抽稀、报警处理、视频信令——一切一次性、可重来的请求坐标流管渲染边界WGS-84 单一口径贯穿按端决定在不在最后一跳转 GCJ-02三条线都汇入同一个wsStore——全端唯一的车辆状态源再经批刷管线流向地图和列表。数据流单向、可追溯界面上任何一辆车的状态都能反推出它来自哪一帧、哪次快照、哪次合并。历史轨迹回放单独说一句原始轨迹点动辄几万个全画到地图上又卡又乱。服务端按地图缩放级别做抽稀——缩得越小点越少放得越大点越全配合回放时的速度曲线和报警点位标注取证场景既流畅又完整。六、视频链路浏览器播 H.265 的坎车载摄像头为了省流量大量采用 H.265 编码但浏览器原生不支持 H.265 硬解——这是车联网 Web 端绕不过去的坎。我们的方案容器与传输后端 1078 网关把 RTP 流转封装成 FLV浏览器走 WS-FLV6899 端口用 mpegts.js 解封装小程序走 HTTP-FLV6810 端口H.265 解码mpegts.js 解出的 H.265 裸流交给 h265webWASM 软解码器逐帧解码上屏。软解吃 CPU所以视频墙做了路数控制——同屏路数超过阈值时非焦点窗口自动降码流/降帧率焦点窗口保清晰对讲独立端口6805承载双向音频与视频流互不干扰视频墙还有个和后端呼应的设计用户切走页面或关闭窗口前端主动通知后端关流——配合后端30 秒无消费者自动回收双保险绝不让忘关的流烧流量。七、PC 模拟器多车压测与剧本回归PC 模拟器Java 21 JavaFX AtlantaFX是测试体系的重型武器四个能力三协议全模拟808 的定位/报警/指令应答、1078 的 RTP 推流读取本地视频文件打成 RTP 包、809 的下级平台行为一个进程全搞定四协议版本808 的 2011/2013/2019 等版本可逐车切换后端的多版本兼容性全靠它回归JSON 剧本把终端该干什么写成剧本——几点几分上线、沿某条路线行驶、行驶中触发超速报警、收到指令后延迟 N 秒应答。剧本可版本化管理测试用例就是代码HTTP 控制面8899创建/销毁车辆、启停剧本、注入报警全部可通过 HTTP 远程驱动——CI 里的自动化集成测试就是脚本调控制面 断言后端台账压测场景是这么跑的控制面批量创建几千台虚拟车 → 全部上线鉴权 → 按真实频率并发上报定位 → 观察全链路水位网关 CPU、MQ 堆积、PG 写入、WS 推送延迟→ 找到拐点确认余量。上线前的每一次容量结论都是模拟器压出来的不是拍脑袋拍的。八、Android 模拟器真机行为最后一块拼图PC 模拟器解决了量Android 模拟器Kotlin Compose解决真六种定位模式CSV 轨迹回放、GPX 回放、真实 GPS、手动驾驶摇杆控制方向速度等——既能复现固定路线做回归也能开着真车路测全量下行自动应答表每一类 0x8xxx 指令的应答行为都可在表里配置——立即应答/延迟应答/应答失败覆盖各种刁钻的终端行为真拍照、真推流用真机摄像头应答拍照指令、给 1078 推真实摄像头画面——这两件事 PC 模拟器只能用图片/文件模拟真机才能端到端验证交付验收的最后一环就是 Android 模拟器拿着手机在真实园区里跑一圈平台上看到的轨迹、视频、报警和真终端跑出来的逐条比对。它过不了的验收真终端一定也过不了。九、系列总结三篇文章一条主线第 1 篇五层架构 一条定位帧的业务闭环——骨架第 2 篇协议面/业务面分离 MQ 信封 Redis 路由 月分区——后端第 3 篇本篇四级节流渲染管线 四端四契约 双模拟器测试闭环——前端与测试回头看这套平台没有黑科技值钱的全是纪律协议与业务分离、codec 零依赖红线、坐标单一口径、看车不查库、订阅不互踢、更新必节流。这些纪律没有一条写在教科书上条条都是事故的学费。守住它们万级车辆实时监控用常规技术栈也能做得稳、做得久。如果这个系列对你有帮助欢迎点赞收藏评论交流。协议细节、渲染管线、模拟器设计哪块想深入聊的评论区见。文中部署地址、密钥、域名等敏感信息均已脱敏架构图为作者基于实际项目整理绘制。