Serial Studio 回放时间线重构磁带式拖拽与无丢帧追帧的实现Spec 0020 深度解析【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-StudioSerial Studio 的播放器把 CSV、MDF4 或会话数据库中的录放数据当作实时数据重放到仪表盘上用于事后回溯定位事件。Spec 0020spec.md记录了针对这条回放链路的一次彻底重构把拖动时间线会卡死数秒、播放永远追不上录制速率的两个顽疾改造成双向流畅的磁带式拖拽tape-style scrubbing和不跳过任何一行的有损追赶lossless catch-up。本文以该规格文档为主线结合 ReplayPlaybackEngine、ReplayIngest 与 集成测试 的源码完整拆解需求、设计与验证方式。问题背景大项目回放的两个退化规格文档给出的现场依据是一份 field project 文件88 个 group、571 个 dataset每条 CAN 消息一行记录于 2026-07-18 从 CSV 或 MDF4 回放时暴露出两个问题拖拽不可用。早期版本允许用户拖动时间线并看着曲线在光标下播放——这是肉眼定位事件再跳过去的主要手段。而当时每一次滑块移动都会丢弃全部绘图数据再经由通用解析管线同步重建整个绘图窗口在 field-project 规模下一个 tick 就要注入数百次完整管线帧UI 冻结数秒实时拖拽手感彻底消失。播放追不上。当录制的帧率超过回放管线的处理能力时catch-up 循环以固定批大小重放每一行中间数据却永远越落越远——录制文件以永久慢动作方式播放。Session 回放之所以感觉好些只是因为其帧数把同一毫秒内的爆发折叠了而非管线更快。维护者的方向2026-07-19拖拽必须像磁带——双向都快、绘图永远反映光标位置向回拖要看得见曲线回撤——且 catch-up 必须快到可以无损保持跳过录制数据不可接受。目标与非目标目标Goals拖动回放时间线时可见绘图连续更新双向、足够流畅能在 field-project 规模上肉眼定位事件在任意静止的时间线位置 P每个绘图恰好显示以 P 结尾的尾部窗口trailing window内录制的采样点——无论 P 是向前拖、向回拖还是播放到达的结果都相同正常播放以录制自身的节奏推进不丢行、不跳行并能从瞬时卡顿中无损恢复三种回放源CSV、MDF4、会话数据库行为一致。非目标Non-Goals——被明确排除的范围不改变实时设备流、仪表盘导出等回放之外的任何行为回放全链路禁止任何降采样、抽样或超前跳过维护者明确否决不新增播放功能倍速、循环区间、书签/事件标记——本次只是恢复并加固既有能力不改变录制/导出格式及其写入器除拖拽行为所需外不重新设计播放器对话框。需求 R1–R6磁带语义的完整定义规格把行为收敛为六条可验证需求需求内容R1 位置精确性磁带语义时间线静止在 P 时每个绘图恰好显示以 P 结尾的尾部窗口内的录制采样点没有来自 P 之后的残留点向回拖即回撤也没有来自窗口之前的空洞。与到达 P 的方式无关。R2 拖拽实时反馈在 field-project 规模上拖动时绘图以可交互速率更新每秒多次独立更新UI 永不硬冻结非绘图控件仪表、条形、LED跟踪光标的当前帧。R3 节奏化播放播放 field-project 规模录制时显示时间戳按录制自身速率推进墙钟播放 N 秒后时间线位置与 N 秒录制时间之差在一个小固定容差内无无界漂移。R4 无损性一次完整播放中每个录制行恰好被处理并投递到仪表盘一次——即使瞬时卡顿触发了 catch-up也不跳过、不重复。R5 播放器对等R1–R4 对 CSV、MDF4、会话回放商业版同等方式成立。R6 回放永不重录拖拽与播放不得向任何导出 sinkCSV/MDF4/session/MQTT 发布追加数据——拨动磁带不能产生新录制。架构两条协作通道取代一刀切注入plan.md 给出的方案是两条互相配合的通道通道 1 —— 回放摄入快速路径播放 / 静止重建用。在FrameBuilder中接受播放器已经分好的通道行QStringList 录制时间戳消除旧的join 成字节流 → 重新 split的往返发布目标是仪表盘与只读 API 观察者从不发布到录制 sink——R6 由构造保证by construction。节奏播放与 catch-up 走这条路径批处理从固定 100 行改为时间预算循环每个事件循环 pass 约 20 ms让重量级录制能无损保持节奏、GUI 不失去响应。通道 2 —— 批量 seek 通道拖拽用。滑块拖动期间合并到约 30 HzDashboard只批量加载绘图环ring从播放器既有内存存储中直接对窗口内行做数值解析仅针对启用了绘图的数据集field-project 规模下每 tick 约毫秒级再额外走一次通道 1 的快速注入让标量控件跟随光标随后一个防抖的静止 pass把完整尾部窗口通过通道 1 重放一遍使 FFT/瀑布/GPS/3D 等在静止时也精确对应 Open Question Q3。向前拖与向回拖是同一操作重建以光标结尾的窗口磁带语义因此由构造成立。该形态的取舍在 plan 中有明确对比仅预算化管线方案在 field-project 规模下无法达到 50 ms 拖拽预算预计算数值矩阵违反内存约束1000 万行需要 GB 级最终选择绘图环批量填充 静止时走管线。源码实证共享的 ReplayPlaybackEngine三个播放器CSV、MDF4、Sessions共用的回放机械封装在 ReplayPlaybackEngine 中头注释自述其职责scrub 定时器链、使旧 play() 链条退休的播放 epoch、让录制文件拥有回放时间的 steady-clock 锚点、catch-up 填充门控与尾部 seek 窗口遍历。组合而非继承各播放器存储不同。关键常量与规格数字一一对应ReplayPlaybackEngine.hstatic constexpr int kSeekTickMs 33; // ~30 Hz 拖拽合并 tickplan 中的 ~30 Hz static constexpr int kSeekSettleMs 250; // ~250 ms 防抖静止后才跑完整窗口重放 static constexpr int kMaxSeekWindowRows 262144; // 每 tick seek 窗口行数上限约束成本 static constexpr int kCatchUpScanMax 262144; // catch-up 单次扫描上限 static constexpr int kCatchUpFillMs 250; // 追帧期间的绘图填充节流间隔 static constexpr qint64 kCatchUpBudgetMs 20; // 每 pass 约 20 ms 的时间预算拖拽的定时器链ReplayPlaybackEngine.cppseekTimer与settleTimer都是 single-shot。armSeek()只在 tick 定时器空闲时才启动它使快速拖动合并而非每次滑块采样排队一次重建settle 定时器则每次滑块采样都重启确保精确重建要等滑块真正静止——这正是 spec Q1 所批准的field-project 参考录制上单次 UI 卡顿不超过约 50 ms的实现手段。录制文件拥有回放时间anchorSteadyBase / steadyTimestampFor引擎把steady_clock::now()锚定到某一行的录制秒数之后每一行的时间戳 锚点 录制时间差。注释写道录制而非墙钟拥有回放时间。这直接支撑 R3无无界漂移两行回放之间的间隔就是录制捕捉到的间隔而不是机器当下跑多快。播放 epochnextEpoch / isCurrentEpoch每次 play 开一个新 epoch旧定时器链检测到 epoch 过期即静默退休防止一次暂停/播放循环同时跑两条注入链——这是不重复投递任何行R4的底层保险之一。尾部窗口起点计算seekWindowStartRow从目标行向前遍历直到覆盖range秒且不少于points行且被kMaxSeekWindowRows封顶保证稠密录制下每 tick 成本有界未知时间负值的行会终止遍历。摄入侧ReplayIngest 与发布目标策略ReplayIngest 是dataset apply 的回放半区持有每个源 uniqueId→列号的映射m_replayColumnMapper-source因为 uniqueId 跨源并不唯一并提供applySpanValue字节 span 通道QuickPlot 字节路径使用与applyTypedValue类型化通道字符串通道借指针、数值通道直接存double两个单元格写入器。类注释强调它非虚、直接调用因为这要逐 dataset 逐回放行执行——即热路径上刻意避免虚调用。发布目标策略是 plan 中五选一决策的核心决策选项选择与理由拖拽拖扫机制(a) 仅预算化管线(b) 绘图环批量填充 静止时走管线(c) 预计算数值矩阵(b)——唯一能在 field-project 规模满足 50 ms 拖拽预算又不降采样、不爆内存的形态回放发布目标(a) 仅仪表盘(b) 仪表盘 只读观察者API/gRPC不碰录制器/MQTT(c) 全扇出 逐 sink 回放门控(b)——构造上满足 R6同时让盯着回放的 SDK/API 消费者照常工作静止重建范围(a) 仅绘图(b) 完整窗口走通道 1(b)——Q3 要求 FFT/瀑布/GPS/3D 静止时精确每次手势约 100–200 ms 的一次性开销可接受预算约束针对拖拽中追赶批处理(a) 更大的固定批(b) 墙钟预算批~20 ms/pass(b)——固定批要么饿死吞吐要么阻塞 GUI时间预算随项目宽度与机器速度自适应Q2 的拉伸时间行为自然浮现拖扫数据源(a) 新逐录制数值缓存(b) 现读播放器既有行存储(b)——零额外内存按需 toDouble 是纳秒级每格热路径与线程约束规格与 plan 对性能边界的约束非常具体这也是回放优化不得伤及实时链路的护栏实时设备热路径保持吞吐门槛256 kHz 参考、全部九个 benchmark 层级回放侧加速不得向实时通道添加任何工作量、分配或锁缓存热路径标志纪律不变任何影响缓存标志的新输入其变化信号必须接到缓存刷新回放期间变换transforms、帧解析脚本、控制脚本与脚本看门狗保持惰性播放器关闭时恢复状态录制值即最终值回放永不重跑 dataset 变换功能可用性不变CSV 回放仍是 GPLMDF4/会话回放仍属商业门控任何逐录制的预计算必须内存有界且不得明显拖慢文件打开现有 1000 万行上限内的录制必须仍可打开绘图窗口容量语义每 dataset 的points不变。plan 同时确认不新增跨线程信号槽——播放器、FrameBuilder、Dashboard 全在主线程新调用都是直接函数调用两个新 QTimer合并、settle都是主线程 single-shot不新增缓存标志复用既有的m_playerOpen、m_streamAvailable及 2026-07-18 的 capture/watchdog 门控。验收标准与集成测试五条 AC 的落地方式tasks.md 显示 T1–T11 全部完成AC1磁带精确性与AC3节奏 无损与AC5不重录由 tests/integration/test_replay_timeline.py 覆盖需要应用启动且开启 API ServerSettings → Miscellaneous → Enable API Server后运行pytest tests/integration/test_replay_timeline.py -vAC2field project 文件 真实抓包上的拖拽观感与AC4--benchmark-hotpath全部门槛层级由维护者在构建上验证。测试文件本身即是需求的可执行表达生成一个 50 Hz、200 行的恒定速率 CSVROW_COUNT 200ROW_HZ 50.0四个用例分别对应——test_backward_scrub_matches_direct_seekAC1先 seek 到 0.8 再向回拖到 0.4等待 settle 后取dashboard.tailFrames的尾部序列与重新打开后直接 seek 到 0.4的基线逐值断言相等并断言两次framePosition相同——这就是 R1与到达方式无关的直接验证test_scrub_then_play_resumes向回拖后继续播放断言framePosition继续前进对应 plan 风险项中plot/display 时钟不得倒退、seek 必须重置时钟的修复验证test_playback_pace_and_losslessnessAC3播放 2 秒后断言framePosition在2.0 × ROW_HZ的半个行容差内R3 节奏播完整个文件后断言tailFrames尾部序列等于0..199的期望值R4 无损每行恰好一次test_replay_never_re_recordsAC5先csvExport.setEnabled打开导出再播放 拖拽断言csvExport.getStatus的isOpen仍为False——R6拨动磁带不产生新录制从外部可观测。tasks 文件记录了最终覆盖口径CSV 端到端覆盖了共享通道AC1/AC3/AC5MDF4/会话因无测试造数辅助而依赖共享代码覆盖 AC2。任务分解与完成状态tasks.md 把 plan 拆成 11 个可独立验证的任务并全部完成T1 在 FrameBuilder 增加回放摄入入口断言m_playerOpen经acquireFrame槽池发布只到 Dashboard API/gRPC 观察者T2–T4 把 CSV/MDF4/Sessions 三条播放通道切到快速路径 时间预算 catch-upT5 在 Dashboard 实现绘图环批量加载与 seek 时钟重置只写 ring不碰 push tableT6–T8 落地三个播放器的磁带拖拽合并 → 批量填充 → 250 ms 防抖 settleT9 计划中的 QMLpressed手势提示按计划跳过——250 ms settle 防抖每次 move 重启足以检测手势结束对话框零改动。完成标准Definition of Done还包括所有改动文件scripts/code-verify.py --check零错误零建议六 agent 的qt-cpp-review发现的确认项已修复如 catch-up 时间预算旁增设静态迭代上限、QuickPlot 拖拽回退到 settle 重建而非清空 ring、Sessions seek 查询一次性 prepare 失败时清 NaN 序列等--benchmark-hotpath作为 AC4 维护者门槛span 通道未动、QList 通道严格更轻。开放问题的最终裁决三条 Open Questions 均由维护者于 2026-07-19 裁决spec.md并已在实现中落地Q1 拖拽卡顿预算批准——field-project 参考录制上的拖动过程中单次 UI 卡顿不超过约 50 ms由 ~30 Hz 合并 tick 批量 ring 填充实现Q2 永久算力不足的设备确认——硬件无法维持录制速率时播放拉伸时间无损跳过仍然禁止Q2 行为正是墙钟预算批决策的自然结果与kCatchUpBudgetMs时间预算一致Q3 拖拽中绘图之外的控件确认——静止时精确即足够FFT/瀑布/GPS/3D 靠 settle pass 达到精确绘图与标量控件在拖拽中实时更新。小结Spec 0020 的价值在于它把一个手感问题翻译成了六条可测试的行为契约R1–R6再用两条职责分明的通道快速摄入 批量 seek在不动实时热路径的前提下兑现拖拽走重建窗口这一统一操作从而天然获得磁带语义播放走 20 ms 时间预算批加 steady-clock 锚定从而获得录制文件拥有回放时间的无损节奏。对二次开发者而言最直接的入手点是三个共享常量与两个单发定时器所在的 ReplayPlaybackEngine以及能完整复现 AC1/AC3/AC5 的 test_replay_timeline.py——前者解释了为什么快后者定义了怎样才算对。【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-Studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Serial Studio 回放时间线重构：磁带式拖拽与无丢帧追帧的实现（Spec 0020 深度解析）
Serial Studio 回放时间线重构磁带式拖拽与无丢帧追帧的实现Spec 0020 深度解析【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-StudioSerial Studio 的播放器把 CSV、MDF4 或会话数据库中的录放数据当作实时数据重放到仪表盘上用于事后回溯定位事件。Spec 0020spec.md记录了针对这条回放链路的一次彻底重构把拖动时间线会卡死数秒、播放永远追不上录制速率的两个顽疾改造成双向流畅的磁带式拖拽tape-style scrubbing和不跳过任何一行的有损追赶lossless catch-up。本文以该规格文档为主线结合 ReplayPlaybackEngine、ReplayIngest 与 集成测试 的源码完整拆解需求、设计与验证方式。问题背景大项目回放的两个退化规格文档给出的现场依据是一份 field project 文件88 个 group、571 个 dataset每条 CAN 消息一行记录于 2026-07-18 从 CSV 或 MDF4 回放时暴露出两个问题拖拽不可用。早期版本允许用户拖动时间线并看着曲线在光标下播放——这是肉眼定位事件再跳过去的主要手段。而当时每一次滑块移动都会丢弃全部绘图数据再经由通用解析管线同步重建整个绘图窗口在 field-project 规模下一个 tick 就要注入数百次完整管线帧UI 冻结数秒实时拖拽手感彻底消失。播放追不上。当录制的帧率超过回放管线的处理能力时catch-up 循环以固定批大小重放每一行中间数据却永远越落越远——录制文件以永久慢动作方式播放。Session 回放之所以感觉好些只是因为其帧数把同一毫秒内的爆发折叠了而非管线更快。维护者的方向2026-07-19拖拽必须像磁带——双向都快、绘图永远反映光标位置向回拖要看得见曲线回撤——且 catch-up 必须快到可以无损保持跳过录制数据不可接受。目标与非目标目标Goals拖动回放时间线时可见绘图连续更新双向、足够流畅能在 field-project 规模上肉眼定位事件在任意静止的时间线位置 P每个绘图恰好显示以 P 结尾的尾部窗口trailing window内录制的采样点——无论 P 是向前拖、向回拖还是播放到达的结果都相同正常播放以录制自身的节奏推进不丢行、不跳行并能从瞬时卡顿中无损恢复三种回放源CSV、MDF4、会话数据库行为一致。非目标Non-Goals——被明确排除的范围不改变实时设备流、仪表盘导出等回放之外的任何行为回放全链路禁止任何降采样、抽样或超前跳过维护者明确否决不新增播放功能倍速、循环区间、书签/事件标记——本次只是恢复并加固既有能力不改变录制/导出格式及其写入器除拖拽行为所需外不重新设计播放器对话框。需求 R1–R6磁带语义的完整定义规格把行为收敛为六条可验证需求需求内容R1 位置精确性磁带语义时间线静止在 P 时每个绘图恰好显示以 P 结尾的尾部窗口内的录制采样点没有来自 P 之后的残留点向回拖即回撤也没有来自窗口之前的空洞。与到达 P 的方式无关。R2 拖拽实时反馈在 field-project 规模上拖动时绘图以可交互速率更新每秒多次独立更新UI 永不硬冻结非绘图控件仪表、条形、LED跟踪光标的当前帧。R3 节奏化播放播放 field-project 规模录制时显示时间戳按录制自身速率推进墙钟播放 N 秒后时间线位置与 N 秒录制时间之差在一个小固定容差内无无界漂移。R4 无损性一次完整播放中每个录制行恰好被处理并投递到仪表盘一次——即使瞬时卡顿触发了 catch-up也不跳过、不重复。R5 播放器对等R1–R4 对 CSV、MDF4、会话回放商业版同等方式成立。R6 回放永不重录拖拽与播放不得向任何导出 sinkCSV/MDF4/session/MQTT 发布追加数据——拨动磁带不能产生新录制。架构两条协作通道取代一刀切注入plan.md 给出的方案是两条互相配合的通道通道 1 —— 回放摄入快速路径播放 / 静止重建用。在FrameBuilder中接受播放器已经分好的通道行QStringList 录制时间戳消除旧的join 成字节流 → 重新 split的往返发布目标是仪表盘与只读 API 观察者从不发布到录制 sink——R6 由构造保证by construction。节奏播放与 catch-up 走这条路径批处理从固定 100 行改为时间预算循环每个事件循环 pass 约 20 ms让重量级录制能无损保持节奏、GUI 不失去响应。通道 2 —— 批量 seek 通道拖拽用。滑块拖动期间合并到约 30 HzDashboard只批量加载绘图环ring从播放器既有内存存储中直接对窗口内行做数值解析仅针对启用了绘图的数据集field-project 规模下每 tick 约毫秒级再额外走一次通道 1 的快速注入让标量控件跟随光标随后一个防抖的静止 pass把完整尾部窗口通过通道 1 重放一遍使 FFT/瀑布/GPS/3D 等在静止时也精确对应 Open Question Q3。向前拖与向回拖是同一操作重建以光标结尾的窗口磁带语义因此由构造成立。该形态的取舍在 plan 中有明确对比仅预算化管线方案在 field-project 规模下无法达到 50 ms 拖拽预算预计算数值矩阵违反内存约束1000 万行需要 GB 级最终选择绘图环批量填充 静止时走管线。源码实证共享的 ReplayPlaybackEngine三个播放器CSV、MDF4、Sessions共用的回放机械封装在 ReplayPlaybackEngine 中头注释自述其职责scrub 定时器链、使旧 play() 链条退休的播放 epoch、让录制文件拥有回放时间的 steady-clock 锚点、catch-up 填充门控与尾部 seek 窗口遍历。组合而非继承各播放器存储不同。关键常量与规格数字一一对应ReplayPlaybackEngine.hstatic constexpr int kSeekTickMs 33; // ~30 Hz 拖拽合并 tickplan 中的 ~30 Hz static constexpr int kSeekSettleMs 250; // ~250 ms 防抖静止后才跑完整窗口重放 static constexpr int kMaxSeekWindowRows 262144; // 每 tick seek 窗口行数上限约束成本 static constexpr int kCatchUpScanMax 262144; // catch-up 单次扫描上限 static constexpr int kCatchUpFillMs 250; // 追帧期间的绘图填充节流间隔 static constexpr qint64 kCatchUpBudgetMs 20; // 每 pass 约 20 ms 的时间预算拖拽的定时器链ReplayPlaybackEngine.cppseekTimer与settleTimer都是 single-shot。armSeek()只在 tick 定时器空闲时才启动它使快速拖动合并而非每次滑块采样排队一次重建settle 定时器则每次滑块采样都重启确保精确重建要等滑块真正静止——这正是 spec Q1 所批准的field-project 参考录制上单次 UI 卡顿不超过约 50 ms的实现手段。录制文件拥有回放时间anchorSteadyBase / steadyTimestampFor引擎把steady_clock::now()锚定到某一行的录制秒数之后每一行的时间戳 锚点 录制时间差。注释写道录制而非墙钟拥有回放时间。这直接支撑 R3无无界漂移两行回放之间的间隔就是录制捕捉到的间隔而不是机器当下跑多快。播放 epochnextEpoch / isCurrentEpoch每次 play 开一个新 epoch旧定时器链检测到 epoch 过期即静默退休防止一次暂停/播放循环同时跑两条注入链——这是不重复投递任何行R4的底层保险之一。尾部窗口起点计算seekWindowStartRow从目标行向前遍历直到覆盖range秒且不少于points行且被kMaxSeekWindowRows封顶保证稠密录制下每 tick 成本有界未知时间负值的行会终止遍历。摄入侧ReplayIngest 与发布目标策略ReplayIngest 是dataset apply 的回放半区持有每个源 uniqueId→列号的映射m_replayColumnMapper-source因为 uniqueId 跨源并不唯一并提供applySpanValue字节 span 通道QuickPlot 字节路径使用与applyTypedValue类型化通道字符串通道借指针、数值通道直接存double两个单元格写入器。类注释强调它非虚、直接调用因为这要逐 dataset 逐回放行执行——即热路径上刻意避免虚调用。发布目标策略是 plan 中五选一决策的核心决策选项选择与理由拖拽拖扫机制(a) 仅预算化管线(b) 绘图环批量填充 静止时走管线(c) 预计算数值矩阵(b)——唯一能在 field-project 规模满足 50 ms 拖拽预算又不降采样、不爆内存的形态回放发布目标(a) 仅仪表盘(b) 仪表盘 只读观察者API/gRPC不碰录制器/MQTT(c) 全扇出 逐 sink 回放门控(b)——构造上满足 R6同时让盯着回放的 SDK/API 消费者照常工作静止重建范围(a) 仅绘图(b) 完整窗口走通道 1(b)——Q3 要求 FFT/瀑布/GPS/3D 静止时精确每次手势约 100–200 ms 的一次性开销可接受预算约束针对拖拽中追赶批处理(a) 更大的固定批(b) 墙钟预算批~20 ms/pass(b)——固定批要么饿死吞吐要么阻塞 GUI时间预算随项目宽度与机器速度自适应Q2 的拉伸时间行为自然浮现拖扫数据源(a) 新逐录制数值缓存(b) 现读播放器既有行存储(b)——零额外内存按需 toDouble 是纳秒级每格热路径与线程约束规格与 plan 对性能边界的约束非常具体这也是回放优化不得伤及实时链路的护栏实时设备热路径保持吞吐门槛256 kHz 参考、全部九个 benchmark 层级回放侧加速不得向实时通道添加任何工作量、分配或锁缓存热路径标志纪律不变任何影响缓存标志的新输入其变化信号必须接到缓存刷新回放期间变换transforms、帧解析脚本、控制脚本与脚本看门狗保持惰性播放器关闭时恢复状态录制值即最终值回放永不重跑 dataset 变换功能可用性不变CSV 回放仍是 GPLMDF4/会话回放仍属商业门控任何逐录制的预计算必须内存有界且不得明显拖慢文件打开现有 1000 万行上限内的录制必须仍可打开绘图窗口容量语义每 dataset 的points不变。plan 同时确认不新增跨线程信号槽——播放器、FrameBuilder、Dashboard 全在主线程新调用都是直接函数调用两个新 QTimer合并、settle都是主线程 single-shot不新增缓存标志复用既有的m_playerOpen、m_streamAvailable及 2026-07-18 的 capture/watchdog 门控。验收标准与集成测试五条 AC 的落地方式tasks.md 显示 T1–T11 全部完成AC1磁带精确性与AC3节奏 无损与AC5不重录由 tests/integration/test_replay_timeline.py 覆盖需要应用启动且开启 API ServerSettings → Miscellaneous → Enable API Server后运行pytest tests/integration/test_replay_timeline.py -vAC2field project 文件 真实抓包上的拖拽观感与AC4--benchmark-hotpath全部门槛层级由维护者在构建上验证。测试文件本身即是需求的可执行表达生成一个 50 Hz、200 行的恒定速率 CSVROW_COUNT 200ROW_HZ 50.0四个用例分别对应——test_backward_scrub_matches_direct_seekAC1先 seek 到 0.8 再向回拖到 0.4等待 settle 后取dashboard.tailFrames的尾部序列与重新打开后直接 seek 到 0.4的基线逐值断言相等并断言两次framePosition相同——这就是 R1与到达方式无关的直接验证test_scrub_then_play_resumes向回拖后继续播放断言framePosition继续前进对应 plan 风险项中plot/display 时钟不得倒退、seek 必须重置时钟的修复验证test_playback_pace_and_losslessnessAC3播放 2 秒后断言framePosition在2.0 × ROW_HZ的半个行容差内R3 节奏播完整个文件后断言tailFrames尾部序列等于0..199的期望值R4 无损每行恰好一次test_replay_never_re_recordsAC5先csvExport.setEnabled打开导出再播放 拖拽断言csvExport.getStatus的isOpen仍为False——R6拨动磁带不产生新录制从外部可观测。tasks 文件记录了最终覆盖口径CSV 端到端覆盖了共享通道AC1/AC3/AC5MDF4/会话因无测试造数辅助而依赖共享代码覆盖 AC2。任务分解与完成状态tasks.md 把 plan 拆成 11 个可独立验证的任务并全部完成T1 在 FrameBuilder 增加回放摄入入口断言m_playerOpen经acquireFrame槽池发布只到 Dashboard API/gRPC 观察者T2–T4 把 CSV/MDF4/Sessions 三条播放通道切到快速路径 时间预算 catch-upT5 在 Dashboard 实现绘图环批量加载与 seek 时钟重置只写 ring不碰 push tableT6–T8 落地三个播放器的磁带拖拽合并 → 批量填充 → 250 ms 防抖 settleT9 计划中的 QMLpressed手势提示按计划跳过——250 ms settle 防抖每次 move 重启足以检测手势结束对话框零改动。完成标准Definition of Done还包括所有改动文件scripts/code-verify.py --check零错误零建议六 agent 的qt-cpp-review发现的确认项已修复如 catch-up 时间预算旁增设静态迭代上限、QuickPlot 拖拽回退到 settle 重建而非清空 ring、Sessions seek 查询一次性 prepare 失败时清 NaN 序列等--benchmark-hotpath作为 AC4 维护者门槛span 通道未动、QList 通道严格更轻。开放问题的最终裁决三条 Open Questions 均由维护者于 2026-07-19 裁决spec.md并已在实现中落地Q1 拖拽卡顿预算批准——field-project 参考录制上的拖动过程中单次 UI 卡顿不超过约 50 ms由 ~30 Hz 合并 tick 批量 ring 填充实现Q2 永久算力不足的设备确认——硬件无法维持录制速率时播放拉伸时间无损跳过仍然禁止Q2 行为正是墙钟预算批决策的自然结果与kCatchUpBudgetMs时间预算一致Q3 拖拽中绘图之外的控件确认——静止时精确即足够FFT/瀑布/GPS/3D 靠 settle pass 达到精确绘图与标量控件在拖拽中实时更新。小结Spec 0020 的价值在于它把一个手感问题翻译成了六条可测试的行为契约R1–R6再用两条职责分明的通道快速摄入 批量 seek在不动实时热路径的前提下兑现拖拽走重建窗口这一统一操作从而天然获得磁带语义播放走 20 ms 时间预算批加 steady-clock 锚定从而获得录制文件拥有回放时间的无损节奏。对二次开发者而言最直接的入手点是三个共享常量与两个单发定时器所在的 ReplayPlaybackEngine以及能完整复现 AC1/AC3/AC5 的 test_replay_timeline.py——前者解释了为什么快后者定义了怎样才算对。【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-Studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考