KlineChartQuant Tooltip 高频交互 200FPS 性能优化完整复盘

刚刚将项目的状态管理全部重构到自研的一套借鉴 vue pinia react 结合体的零依赖状态管理，既有计算属性，又能精准控制渲染时机。但是数据走标准通道后，暴露出先前架构的问题。

只要鼠标在图表上快速滑动，更新十字线和 Tooltip 浮窗 layer 的时候，Chrome DevTools 的 Performance 面板里就经常飙出刺眼的黄帧甚至红帧。

这暗示主线程被严重阻塞了。我们的交互目标是稳定跑满 200fps，算下来一帧的预算满打满算只有 5ms。但录个 trace 一看，单次 Tooltip 更新在 Vue 框架内部处理 Vnode 的 FlushJob 上就要吃掉 1.5ms 多，并且还每帧触发布局计算。一个浮窗把大半帧预算抢光了，后续帧统统被延迟渲染，呈现为黄帧。碰上 GC，直接红帧。

我一路从数据层挖到了浏览器底层的 HTML Parser，最终实现单帧 2.12ms（CPU）+0.6ms（GPU） 的顶级渲染速度。这里复盘一下整个排查和优化的过程。

开源高性能金融图表，欢迎使用

体验：363045841.github.io/KLineChartQ... Github：github.com/363045841/K... NPM：www.npmjs.com/package/@36... 项目持续更新中！欢迎提出宝贵建议！如果对您有帮助可以给个 Star！

阶段一：数据层的无脑浅拷贝

看 trace，getRenderData() 这个函数特别扎眼，单帧耗时 1.09ms。

AI 编程出现漏洞：

getRenderData(): unknown[] {
  return [...this._dataState.readonly.data()] as unknown[]
}

每调一次，就把 5000 多条 K 线数据做一次 spread 浅拷贝，同一帧里渲染和交互计算要调它 5、6 次。5000 乘 6，几万次无意义的内存分配，严重 GC 压力导致大量帧被延迟。

改法很简单：直接返回 Signal 的 .peek() 原始引用，零拷贝。交互层单独开个 getInternalData() 去读底层 raw buffer。渲染器那边也改了，外部读一次数据当参数传进去，不准在函数里面自己再去读。

这一刀下去，1ms 没了。

阶段二：DOM 测量引发的强制重排

继续看 trace，发现 getBoundingClientRect 也很耗时。

Tooltip 内容更新后，需要量一下实际宽高，好通知 Canvas 层避让。原来的写法是在 requestAnimationFrame 里调 getBoundingClientRect。 问题在于，你刚用 JS 改完 DOM 内容，紧接着就去问浏览器"这玩意儿现在多宽"，浏览器为了给出准确数据，必须强行同步计算一次 Layout（Forced Layout，强制回流）。布局计算本就宝贵，高频交互下就是性能灾难。

直接把这坨逻辑删了，换成 ResizeObserver 监听容器尺寸变化，配合 WeakSet 防重复绑定。只有当其他地方触发了布局重算，且 Tooltip 大小真的改变，才触发回调处理。

修改前：rAF + getBoundingClientRect（触发强制回流）

在每次 DOM 内容更新后，通过 requestAnimationFrame 或 queueMicrotask 异步获取尺寸。由于此时浏览器尚未完成当前帧的 Layout，调用 getBoundingClientRect 会触发 Forced Layout（强制同步布局），在高频交互下造成严重的性能阻塞。

function setTooltipEl(el: HTMLDivElement | null) {
  if (!el) return
  
  requestAnimationFrame(() => {
    if (!el.isConnected) return
    // 强制浏览器立即计算 Layout，性能杀手
    const rect = el.getBoundingClientRect() 
    controller.value?.setTooltipSize({
      width: Math.max(180, Math.round(rect.width)),
      height: Math.max(80, Math.round(rect.height)),
    })
  })
}

修改后：ResizeObserver + WeakSet（零强制布局）

移除主动查询尺寸的逻辑，改为使用 ResizeObserver 被动监听。浏览器会在 Layout 完成后、Paint 之前自动通知尺寸变化。配合 WeakSet 防止对同一个 DOM 节点重复绑定 Observer。

const _measuredTooltips = new WeakSet<HTMLElement>()
let _tooltipRO: ResizeObserver | null = null

function setTooltipEl(el: HTMLDivElement | null) {
  // 1. WeakSet 防重复绑定，避免内存泄漏和重复监听
  if (!el || _measuredTooltips.has(el)) return
  _measuredTooltips.add(el)

  // 2. 复用同一个 ResizeObserver 实例
  if (!_tooltipRO) {
    _tooltipRO = new ResizeObserver((entries) => {
      for (const entry of entries) {
        const target = entry.target as HTMLDivElement
        if (!target.isConnected) continue
        
        // 优先读取 borderBoxSize，回退到 contentRect
        const w = entry.borderBoxSize[0]?.inlineSize ?? entry.contentRect.width
        const h = entry.borderBoxSize[0]?.blockSize ?? entry.contentRect.height
        
        controller.value?.setTooltipSize({
          width: Math.max(180, Math.round(w)),
          height: Math.max(80, Math.round(h)),
        })
      }
    })
  }
  
  // 3. 仅观察，不主动触发 Layout
  _tooltipRO.observe(el)
}

这步做完，测量环节的开销基本从面板上消失了，每帧不再耗时在强制回流上。

阶段三：Vue VNode 遍历的天花板

数据层和测量层都干净了，但跨 K 线移动鼠标时，Vue 的 flushJobs 依然稳稳占了 2.44ms。

原因很直白：KLineTooltip 是个框架层 Vue 组件。每次数据一变，Vue 就得老老实实走一遍 VNode 创建、Diff、Patch 的全套流程。

我们在框架内能做的都做了：

1. 给"开、高、低、收"这些死文本加 v-once。
2. 上 v-memo="[hoveredKLine?.timestamp, hoveredIndex]"，鼠标在同一根 K 线内移动时直接跳过更新。
3. :style 绑定的坐标对象做值比较缓存，引用不变就不触发重渲染。

结果：同 Bar 移动耗时归零。但只要一跨 Bar，VNode 树遍历的 2.44ms 纹丝不动，而高频交互下跨 Bar 恰恰是高频交互下最经常做的，我们的目标是完全稳住 200 FPS，但是只要依赖框架层，就会在高刷、高频交互下产生大量红帧，直接将帧率拖累到 160 - 130 FPS。这是 Vue 框架本身的调度成本，靠常规 API 根本干不掉。

很多开发者可能认为这个拖累的帧率不影响用户体验，但是帧率实际上只是表象，而其揭露了背后的性能问题。作为一个快速迭代的及其复杂的图表库，这会累积非常多的性能问题，况且这是高性能桌面端下跑出的成绩，在很多平板设备上，GPU 核心会被屏蔽 1 - 2 个，CPU 侧也不及桌面端，即使屏幕刷新率在 120 FPS 、60 FPS，这样的性能问题只会更明显。

阶段四：绕过 Vue，但撞上了 HTML Parser

既然 Vue 管不过来，那就把它踢开。

我把 KLineTooltip 组件从模板里连根拔起，换成一个空的 <div ref="tooltipContentRef">。在 Setup 里直接订阅 Kernel 的 interactionState 信号，脱离 Vue 响应式系统，直接操作 DOM。

第一版图省事，用了 innerHTML 拼 HTML 字符串：

el.innerHTML = _buildTooltipHTML(kline, idx, data, ...)

一测，flushJobs 确实没了，但 innerHTML 赋值自己耗时 1.31ms。点开底层堆栈一看，1.13ms 全花在浏览器的 HTML Parser 上。

把字符串塞给浏览器，让它从头解析一遍再建 DOM 树，这跟 Vue 建 VNode 树其实是类似的活，只是换了个地方挨揍。

阶段五：程序化 DOM 与引用缓存

一句话概括就是不重建 DOM，只修改 DOM 属性。

既然 HTML Parser 慢，那就不传字符串了。

我们在 Tooltip 首次展示时，用 document.createElement 纯手工把 DOM 树捏出来，并把所有需要动态更新的 <span> 节点引用缓存到一个对象里。

interface _TooltipSlots {
  container: HTMLDivElement
  date: HTMLSpanElement
  open: HTMLSpanElement
  // ... 其他字段
}

后续跨 Bar 更新时，连 appendChild 都省了，直接对着缓存的引用赋值：

slots.date.textContent = formatTimestamp(kline.timestamp, ...)
slots.open.textContent = kline.open.toFixed(2)
slots.open.style.color = openDir > 0 ? upColor : downColor

没有 VNode Diff，没有 HTML 解析。十几次 textContent 赋值加上几个 style.color 修改，耗时暴降到 0.01ms。稳稳支撑高频交互下 200 FPS。

阶段六：v-if 重建引发的"幽灵节点"

开 PR 前发现一个 Bug：初始状态 Tooltip 正常，但只要一缩放图表，Tooltip 就只剩个空壳，文本全没了。

排查了半天，锅在模板里的 <template v-if="hoveredKLine && !isMobile">。

缩放时交互状态会短暂重置，hoveredKLine 变 null，触发 v-if 把整个 DOM 节点卸载。鼠标重新移入时，Vue 创建了一个全新的 div 赋给 tooltipContentRef。

但我们缓存的 _tooltipSlots 还死死指着那个已经被移出文档流的旧节点。_updateTooltipDOM 把文本写进了"幽灵节点"里，新容器自然是空的。

修法也不复杂：在 _TooltipSlots 里加个 container 字段记录构建时的父容器。每次更新前校验一下，对不上就清空重建。

if (!_tooltipSlots || _tooltipSlots.container !== el) {
  _tooltipSlots = null
  el.textContent = ''
  _tooltipSlots = _buildTooltipDOM(el, kline)
}

总结

阶段	跨 Bar 更新耗时	瓶颈
初始状态	~4.00ms+	Spread 拷贝 + VNode Diff + 强制重排
数据与测量层优化	~3.00ms	VNode 树遍历
Vue 框架内极限压榨	2.44ms	Vue flushJobs 调度
绕过 Vue + innerHTML	1.31ms	浏览器 HTML Parser
程序化 DOM + 引用缓存	~0.01ms	无（仅原生 DOM 属性赋值）

回头看，把高频更新的极简 UI 剥离出 Vue 的响应式系统，直接用原生 DOM API 加引用缓存，是解决这类帧率瓶颈最根本的手段。
很多开发者还将性能优化停留在池化、缓存、减少热点上，但其实在很多场景下，有必要绕开框架层，才是问题的最终解法。