What problem does this feature solve?
在 Studio Recorder 录制场景中,随着操作次数和截图数量增加,录制链路会逐渐出现响应延迟、截图异常和处理时间过长等问题,影响录制结果的完整性与可用性。
What does the proposed API look like?
问题表现
| 阶段 |
问题表现 |
| 录制过程 |
连续操作时 Timeline 更新滞后,事件可能延迟或批量出现 |
| 录制过程 |
Timeline 截图可能与操作时看到的预览画面不一致 |
| 长录制 |
约 20 次操作后,部分步骤可能退化为只记录 click 坐标 |
| 停止录制 |
点击 Stop 后长时间无响应 |
| 生成与下载 |
点击 Download 后保存对话框长时间不出现,界面没有进度反馈 |
复现步骤
- 启动 Studio 并连接目标设备或页面。
- 开始录制。
- 连续执行至少 25~30 次可区分的点击或输入操作。
- 观察预览画面、Timeline 更新时间及每一步的截图和描述。
- 在 Timeline 尚未完全更新时点击 Stop。
- 完成 Generate 后点击 Download。
实际结果
- Timeline 无法随操作实时更新。
- 部分步骤的截图与操作时预览不匹配。
- 长录制后可能只保留点击坐标,不再生成具体元素描述。
- Stop 需要等待较长时间才能完成。
- Download 在保存对话框出现前没有明确反馈。
预期结果
- 每次操作都能及时出现在 Timeline 中,并显示当前处理状态。
- 操作步骤与操作时的预览截图准确对应。
- 长录制过程中步骤和元素描述保持完整;发生降级时明确提示原因。
- Stop 可以快速结束录制,剩余处理在后台可见地完成。
- Download 点击后立即显示导出状态和进度。
原因分析
上述表现来自同一录制链路中的多项累积问题:
- Recorder 事件严格串行处理,每个操作还需要等待截图和页面状态采集,连续操作会形成队列积压。
- Studio 每 500ms 轮询一次事件,进一步放大 Timeline 延迟。
- 操作与预览截图没有稳定的事务绑定,截图采集时点可能晚于实际操作。
- 单 Session 截图资产上限为 128MiB,高分辨率截图可能在约 20~25 次操作后触顶,导致后续语义描述退化。
- Generate 和 Download 默认最多使用 20 张截图,超出部分会被静默裁剪。
- Stop 会串联等待截图队列、事件拉取、AI 描述、持久化和元数据生成。
- Download 在 Renderer 中串行读取截图并生成完整 Base64 ZIP,完成后才打开保存对话框。
What problem does this feature solve?
在 Studio Recorder 录制场景中,随着操作次数和截图数量增加,录制链路会逐渐出现响应延迟、截图异常和处理时间过长等问题,影响录制结果的完整性与可用性。
What does the proposed API look like?
问题表现
复现步骤
实际结果
预期结果
原因分析
上述表现来自同一录制链路中的多项累积问题: