万级车辆实时地图 + 双模拟器：车联网前端与测试工程实践（第 3 篇 · 前端与测试） - Sam Xiao
内容提要
车联网前端采用Web、小程序、PC与Android模拟器四端架构，核心挑战是万级车辆实时监控卡顿。通过网络层检丢补全、订阅层引用计数、状态层百毫秒批刷、渲染层rAF合批的四级节流，并以矢量图层替代逐台Marker解决性能问题。四端共享codec、WS协议、坐标与ID四条契约，统一状态源，同时处理H.265播放、压测与真机验收。
延伸解读
四级节流：从网络到渲染的逐级合并
文章提出网络层检丢补全、订阅层引用计数、状态层百毫秒批刷、渲染层rAF合批的四级节流管线。每一级都将更新次数压下一个量级，最终把每秒数百次更新压成每秒10次提交、20次绘制。这种分层设计的关键在于每级只解决一类问题，避免单点优化带来的复杂度。
坐标与ID纪律：制度性防错优于事后修复
车联网前端最高发的bug来源是坐标体系混用和ID混淆。文章强调单一口径加边界转换：服务端存储计算推送只用WGS-84，仅在渲染边界按需转换；同时严格区分carId与tid。这两类问题不是能力问题而是制度问题，从制度上让错误不可能发生，比事后修复成本低得多。
双模拟器：测试资产如何支撑验收与压测
PC模拟器（JavaFX）用于多车压测与剧本回归，可批量创建数千虚拟车并发上报，观察全链路水位并找到容量拐点；Android模拟器（Compose）解决真机行为验证，在真实园区跑一圈比对轨迹、视频、报警。两者与后端共用同一codec jar，保证模拟器行为等于真终端行为，使验收结论可靠。
H.265播放与视频流回收：Web端的现实约束
车载摄像头为省流量多用H.265，但浏览器原生不支持硬解，这是Web端绕不过的坎。文章未展开具体方案，但提到视频墙设计：用户切走页面或关闭窗口时前端主动通知后端关流，配合后端30秒无消费者自动回收，形成双保险，避免忘关的流持续消耗流量。
Q&A
车联网前端如何解决万级车辆实时监控的卡顿问题？
采用四级节流管线：网络层通过WS帧序号检丢，缺口时拉取全量快照，并有心跳看门狗和页签可见性监听；订阅层使用引用计数管理多来源订阅，上行订阅帧分批发送（每批不超过2000台）；状态层将WS帧先放入100ms批刷队列合并提交，尾迹走非响应式环形缓冲；渲染层按50ms节奏在requestAnimationFrame中合批执行图层操作，万级点位使用MapLibre矢量图层而非逐台Marker。
车联网前端四端架构中，如何保证不同端行为一致？
通过四条共享契约：codec纯jar作为编解码唯一实现，四个进程共用；WS协议契约要求Web与小程序逐字平移；坐标纪律规定存储计算用WGS-84，渲染边界才转GCJ-02；ID纪律强制区分carId（档案ID）和tid（设备号）。这些契约从制度上避免了模拟器与真车行为不一致、坐标漂移和ID混用等问题。
车联网前端处理坐标转换有哪些最佳实践？
采用单一口径+边界转换：服务端存储、计算、推送只用WGS-84；天地图（CGCS2000）免转换直接上图；微信小程序原生map组件需要GCJ-02，在数据进入map组件的最后一跳统一转换。任何中间环节禁止私自转换，转换函数在整个前端只有两个允许出现的位置。这避免了同一车辆在不同页面位置相差几百米的问题。
车联网前端如何管理车辆状态数据？
前端数据面有三条线：实时位置、历史轨迹和报警事件，它们都汇入同一个wsStore作为全端唯一的车辆状态源，再经批刷管线流向地图和列表。数据流单向、可追溯，界面上任何车辆状态都能反推出其来源。历史轨迹回放时，服务端按地图缩放级别抽稀，缩放越小点越少，越大点越全，配合速度曲线和报警点位标注，保证取证场景流畅完整。
车联网Web端如何解决浏览器播放H.265视频的问题？
车载摄像头为省流量多用H.265编码，但浏览器原生不支持H.265硬解。方案包括：视频墙设计用户切走页面或关闭窗口时，前端主动通知后端关流，配合后端30秒无消费者自动回收，双保险避免流量浪费。具体解码方案未在文中详述，但通过前后端协作确保流媒体高效管理。
PC模拟器和Android模拟器在车联网测试中分别起什么作用？
PC模拟器（Java 21 + JavaFX + AtlantaFX）用于多车压测与剧本回归，可批量创建几千台虚拟车，模拟真实频率并发上报定位，观察全链路水位，找到容量拐点。Android模拟器（Kotlin + Compose）解决真机行为验证，用于交付验收，在真实园区跑一圈，比对平台轨迹、视频、报警与真终端的一致性。两者结合，PC解决量，Android解决真。
