如何通过CDP自动化采集长时间运行应用的原始性能数据？

本文共计1011个文字，预计阅读时间需要5分钟。

CDP+自身不支持长期运行的持续性性能采集，面向的是单次航行、交互或明确停止的追踪任务。所谓长期运行（如页面停留+10分钟、用户滚动浏览、后台Tab持续运行），必须依赖主动轮询+事件监听+状态管理来模拟，核心是避免内存溢出、时序错乱和指针丢失。

明确长周期采集的目标类型

先区分你要的“原始性能指标”属于哪一类，这直接决定用哪个 CDP 域和策略：

• 高频采样类：CPU 使用率、JS 堆内存、DOM 节点数、布局/绘制次数——适合用 Performance.getMetrics 定期轮询（如每 2 秒一次），它返回固定 10 个字段，开销低、响应快
• 事件驱动类：资源加载完成、首屏渲染、用户交互（click/input）、滚动触发——监听 Network.responseReceived、Page.lifecycleEvent、DOM.childNodeCountUpdated 等事件，按需记录时间戳和上下文
• 高精度轨迹类：FCP、LCP、CLS、帧率、JS 调用栈——必须用 Tracing，但不能全程开启；应分段启用（例如每次滚动开始前 start，滚动结束后 end），否则 trace 文件会迅速达 GB 级别

用 Performance.getMetrics 实现轻量级轮询采集

这是最稳定、最易落地的长周期方式，适用于监控内存泄漏、JS 执行膨胀等缓慢变化问题：

• 在页面加载完成后启用 Performance.enable()
• 启动一个定时器（如 Node.js 的 setInterval 或 Python 的 threading.Timer），间隔建议 1–5 秒，太密会干扰主线程
• 每次调用 Performance.getMetrics，提取 Timestamp、JSHeapUsedSize、DomSize、LayoutCount 等字段，连同当前 Unix 时间戳一起写入本地文件或发往监控服务
• 注意：该方法无法获取 Web Vitals（如 LCP 元素 ID），它只反映瞬时状态，不带事件上下文

用 Tracing 分段捕获关键交互片段

真正需要帧级精度时，不要试图“一直开着 tracing”，而应聚焦用户行为节点：

• 监听 Page.lifecycleEvent 中 state === 'interactive' 或 'complete'，作为首屏后稳定期起点
• 监听 Input.dispatchTouchEvent 或 DOM.scroll（需配合 DOM.enable()）识别用户滚动/点击动作
• 检测到动作后立即 Tracing.start（指定 categories: ["devtools.timeline", "loading", "paint", "v8"]），并在动作结束（如 Page.lifecycleEvent 再次触发或自定义空闲判定）后调用 Tracing.end
• 每个 Tracing.dataCollected 流按 session 或 timestamp 单独保存为 JSON 文件，后续再用工具（如 traceviewer 或自定义解析器）提取 FCP/LCP/CLS

规避常见陷阱

长周期采集失败，往往不是代码写错，而是忽略了运行时约束：

• WebSocket 连接可能超时断开——必须实现重连逻辑，并在重连后重新 enable 所有已订阅的域
• trace events 数据量极大，transferMode: 'ReturnAsStream' 是必须项，否则容易 OOM；收到流后应边收边解析，而非全量缓存
• 页面可能被浏览器自动冻结（尤其是后台 Tab），Page.lifecycleEvent 的 state: 'frozen' 需捕获并暂停采集，恢复时重新同步状态
• 不要依赖 performance.timing 或 getEntries() 的全局快照——它们只反映页面初始加载阶段，对长周期无意义