路测与台架回放运营体系

版本铺到 10 多个车型平台、每天好几波路测的时候，靠人肉记忆管版本和数据一定会丢。这套体系做了三件事：每一波路测的版本与数据强制归档、E29 压测的内存曲线逐波跟踪、把「拿到缺陷回放文件后怎么复现验证」沉淀成人人可执行的 SOP。

路测波次60+ 波

车型平台10+ 个

内存峰值跟踪3942 MB 级

背景

2026 年 6 月到 7 月，一张图/SR 的版本进入高频路测期：北京和上海两地同时跑车，覆盖 D01、D02、D03、E29、E38、F01、F57、G01、H93 等 10 多个车型平台，同一个平台一天能跑出第一波到第四波。每一波路测都要回答三个问题：车上刷的是哪个 ROM、配的哪版地图、出了问题拿哪份回放文件复现。

问题

版本对不上：路测车刷的 ROM 每天都在变，格式形如 XMARTM2ZHD02E1_V6.2.4.1807_20260603032439.0_REV01_USER_DEV，地图版本又是另一条线（V6.2.4_20260603044910_Release）。出问题后回忆「那天车上是什么版本」基本靠猜。
数据散：一次行车态路测要采集 7 类数据——录屏、回放数据、大屏日志、百度日志、百度回放数据、百度定位数据、车外实景（可选）。少拉一类，回放就缺一条腿。
压测无量化跟踪：E29 稳定性压测一跑就是几个小时，内存是缓慢爬升还是稳定波动，没有逐波记录就没有对比基线。
复现靠口口相传：新人拿到缺陷回放文件，不知道推哪个目录、怎么挂 D 档、怎么触发播放，每个人都要重新问一遍。

方案

版本与数据归档：一波一条记录

每一波路测在共享文档里落一条结构化记录：日期 + 城市 + 车型平台 + 波次作为标题，下面固定登记 ROM Version、Map Version，需要时补充高德/百度 SDK 信息（构建分支、构建编号、引擎版本）。比如 7 月 7 日北京 E38be 那波，除了 ROM 和地图版本，还登记了高德 SDK android.9.810.27.0.364、引擎 AutoEngine_13.16.40.5325 和百度构建编号 62151——后来排查 SDK 侧问题时，这条记录直接省掉一轮上车抓版本。

归档闭环长这样：

mermaid

flowchart LR
    A["路测执行<br>录屏+回放+日志"] --> B["数据拉取<br>7 类清单逐项核对"]
    B --> C["版本登记<br>ROM/Map/SDK"]
    C --> D["共享文档归档<br>日期+城市+车型+波次"]
    D --> E["问题回溯<br>按波次定位数据"]

数据采集手顺标准化

路测采集的关键约束全部写进手顺，不再依赖个人经验：

回放文件上限：默认 300 个文件，大致覆盖 1 小时路测，所以长路测建议每 1 小时左右拉一次回放。要改上限用 adb shell setprop persist.subreality.record.maxfilecnt 300，改完必须 killall com.xiaopeng.montecarlo 重启进程才生效，再用 getprop 确认。
Native 回放录制：adb shell am broadcast -a com.xiaopeng.guide.action.native.startRecord 开始、stopRecord 结束，文件落在 /data/user/0/com.xiaopeng.montecarlo/cache/record_file。
百度日志：在 /sdcard 下建 autodrive_log_open 和 record_autopilot_open 两个空文件夹，重启大屏后去 BaiduMapAuto 目录和 ldnavi_log 目录确认有日志生成。
D 级日志：TEST_ENABLE_DETAIL_NAVI_LOG 广播开启，注意进程重启后失效，需要重发。
崩溃卡顿现场：adb shell am broadcast -a com.xiaopeng.action.START_STUCK_DETECT --el threshold 1000 抓堆栈，崩溃后执行一次，生成在应用 files 目录下。

录制结束后的拉取路径也固定成清单：/data/Log（大屏日志与导航日志）、/data/user/0/com.xiaopeng.montecarlo/cache/record_file（Native 回放）、/data/map/ldnavi_log/（百度日志与回放）、BaiduMapAuto 目录（百度回放数据），需要高德日志时再加 /data/map/navi_log/bllog/。拉取完按波次上传归档，指向共享文档里对应那条记录。

台架回放 4 步手顺

百度车道级 record 的台架回放沉淀成固定 4 步：

确认连上台架（adb devices）。
推送回放文件：adb push <本地回放文件夹> /sdcard/subreality/Playback/。
挂 D 档：adb shell am broadcast -a com.xiaopeng.guide.action.mock.datacenter --ei code 40001 --ei format 3 --es value 1。
播放回放：adb shell am broadcast -a com.xiaopeng.guide.action.native.replayPath --es filePath "/sdcard/subreality/Playback/<回放文件夹>"。

关键实现

「缺陷回放复现与验证」SOP V1.0

在 4 步手顺之上，我把完整的缺陷处理流程写成 SOP V1.0，适用对象是 SR 和一张图全体的开发、测试、技术支持。目标三条：高效复现（快速在台架或实车复现缺陷现场）、可靠验证（修复后在原回放数据上确认问题消失）、信息闭环（缺陷接收到结论归档全程标准化）。

mermaid

flowchart LR
    A["缺陷接收<br>视频+回放+日志"] --> B["环境准备<br>APK+回放文件+台架"]
    B --> C["台架复现<br>push+挂D档+播放"]
    C --> D{"现象复现？"}
    D -->|是| E["记录现象+抓日志<br>更新缺陷单"]
    D -->|否| F["核对版本与路径<br>重新复现"]
    F --> C
    E --> G["修复后新APK<br>同一回放文件验证"]
    G --> H["归档<br>[缺陷ID]_[描述]_[日期]"]

SOP 的准备阶段也把依赖项列全了：待验证 APK 走「Unity 侧出 AAR → GuideEngine 侧出完整 APK」的两段构建；问题回放文件从缺陷单附件或共享目录获取；调试工具统一用 TestHelper 并同步团队的自定义命令集；台架提前开机、联网、开 ADB。准备清单的意义是让复现失败时能快速区分「操作问题」和「环境问题」。

SOP 里几个容易踩的点都写死了：

装 APK 用 adb install -r -d：-r 覆盖安装现有版本，装完台架桌面会自动重启大屏。
验证修复必须播同一个回放文件：换了数据样本，「问题消失」就没有意义。验证通过在缺陷单里写明「使用版本号 XXX，在回放文件 YYY 上验证，问题已修复」并附正常画面截图；没通过就写清现象变化，@开发继续排查。
归档命名 [缺陷ID]_[描述]_[日期]：回放文件上传到团队共享目录，命名带缺陷 ID，半年后还能从缺陷单反查到数据。

E29 压测内存曲线监控

E29 稳定性压测期间，每波压测记录版本信息并盯内存曲线。7 月中旬一波压测（ROM V6.3.0.1865 基线）的曲线很有代表性：com.xiaopeng.montecarlo 总内存从 14:48 开始逐渐爬升，19:57 冲到峰值 3942 MB，20:11 回落到 2154 MB 后又缓慢回升。另一波 V6.3.0.1868 的压测曲线则完全不同：内存在 2500 MB 上下波动，中间出现两次掉到 200 MB 量级的深谷。两种曲线形态对应不同的内存行为，逐波留档后，哪一波开始劣化、劣化斜率多少，都能直接翻出来对比，不需要复跑。曲线统一上传到内部稳定性平台，和波次记录一一对应。

指标

指标	数值
路测覆盖	北京/上海两地，10+ 车型平台
归档波次	60+ 波（单平台单日最多 4 波）
单次路测数据采集	7 类（录屏/回放/大屏日志/百度日志/百度回放/百度定位/车外实景）
E29 压测内存峰值跟踪	3942 MB 级，逐波曲线留档
台架回放手顺	4 步固化，新人零问询可执行
SOP	V1.0，覆盖 SR 与一张图全体开发/测试/技术支持

复盘

运营体系的价值在回溯那一刻才兑现。平时记版本号、拉数据都是琐碎体力活，但问题一来，「7 月 7 日 E38be 那波跑的什么 SDK」能 30 秒查到，和翻半天聊天记录是两个世界。
手顺要写「为什么」以外的所有细节。文件上限 300 个、改完要重启进程、D 级日志重启失效——这些坑每个都值一次路测白跑，写进手顺就只值一行字。
SOP 的核心是「同一回放文件」这条纪律。复现和验证用同一份数据，结论才可比；归档命名带缺陷 ID，信息闭环才算真正闭上。
这套体系和监控上报链路是互补的：监控管线上问题的自动发现，路测运营管版本数据的线下归档与人工回溯。回放数据的离线分析效率则依赖回放工具多线程 75 倍提速那条线。

路测与台架回放运营体系 ​

背景 ​

问题 ​

方案 ​

版本与数据归档：一波一条记录 ​

数据采集手顺标准化 ​

台架回放 4 步手顺 ​

关键实现 ​

「缺陷回放复现与验证」SOP V1.0 ​

E29 压测内存曲线监控 ​

指标 ​

复盘 ​