WebSocket仅提供实时数据通道，时间轴动作回放需叠加时间戳同步、动作编码、客户端调度；核心是端到端时间一致性，依赖performance.now()采集、rAF驱动插值播放及滑动窗口容错。
WebSocket 本身不直接支持“时间轴动作捕捉回放”，它只负责低延迟、双向、持久的实时数据通道。要实现基于时间轴的动作回放，需在 WebSocket 基础上叠加时间戳同步、动作采样编码、客户端时间轴调度三部分逻辑。核心难点不在连接建立，而在端到端的时间一致性与播放精度控制。
1. 动作数据采集与带时间戳编码
前端通过 requestAnimationFrame 或高精度定时器（如 performance.now()）采集动作数据（如骨骼旋转、手部坐标、姿态置信度），每帧打上本地高精度时间戳（非 Date.now()）：
- 使用
performance.timeOrigin + performance.now()获取毫秒级单调递增时间戳，避免系统时钟跳变影响 - 动作数据建议结构化压缩：例如只传变化量（delta）、关键帧插值标记、或使用 Protocol Buffers / CBOR 序列化减小体积
- 示例数据包：
{type:"pose", ts:124567890.456, joints:[{id:0, q:[0.1,0.2,-0.1,0.9]}, ...]}
2. WebSocket 传输与服务端轻量中继
服务端无需理解动作语义，仅做可靠转发与可选缓冲（如为多客户端同步加简单 NTP 校准）：
- 客户端连接后，服务端记录其初始连接时间及首次上报的
performance.timeOrigin（可选，用于粗略偏移估算） - 推荐用 Node.js 的
ws库或 Python 的websockets，避免 HTTP 代理干扰 WebSocket 升级 - 若需回放历史动作，服务端可将消息写入内存 RingBuffer 或 Redis Stream，供新连接拉取最近 N 秒快照+增量流
3. 客户端时间轴驱动回放（关键）
回放不是简单“收到就渲染”，而是根据原始时间戳对齐本地时钟，用 requestAnimationFrame 驱动插值播放：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 接收全部动作帧后，提取首帧
ts_start，计算本地播放起始偏移：offset = performance.now() - ts_start - 每一帧渲染时，用
targetTime = frame.ts + offset判断是否到达播放时刻；未到则跳过，到了再执行插值或直接应用 - 使用
setTimeout或requestIdleCallback不够精准，必须绑定到 rAF 循环中做时间差校验 - 支持暂停/拖动：拖动时间轴时，重新计算
offset，并查找最邻近的关键帧作为起点
4. 同步优化与容错策略
真实网络存在抖动与丢包，需保障回放稳定性：
- 服务端可附带全局单调时钟（如
process.hrtime()转换为毫秒），客户端用其替代本地performance.now()做基准（需校准 RTT） - 客户端维护滑动窗口缓存（如 500ms 动作帧），网络卡顿时从缓存续播，避免画面冻结
- 对丢失帧做线性插值或使用上一帧保持（取决于动作敏感度），骨骼动画可结合 Three.js 的
AnimationMixer自动处理关键帧插值
不复杂但容易忽略：时间轴回放的“实时”指逻辑时间连续，而非网络实时。重点是把原始采集时间戳贯穿采集→传输→解码→渲染全链路，并用本地高精度时钟做锚点调度。WebSocket 是管道，时间轴是大脑，动作数据是血液——三者缺一不可。
