以我所主，为我所用

复杂可视化建模工具输入卡顿与 Signals 细粒度更新

13 min read

复杂可视化建模工具输入卡顿与 Signals 细粒度更新

一句话先定性

这类卡顿本质上不是“某个输入框慢”，而是高频局部变更被提升成了全局状态更新，导致 React 以过粗的粒度刷新了整棵画布组件树。

30 秒版本

我之前在一个 DDD 可视化建模工具里遇到过输入卡顿：画布上有几十到上百个节点，用户只是在右侧属性面板改一个字段名，输入框都会掉帧。
一开始以为是自动保存或接口慢，但用 Chrome Performance 和 React Profiler 看下来，主要时间耗在 React render/commit。根因是我们把整棵领域模型放在顶层 Context 里，一个深层字段变化会导致画布相关组件自顶向下刷新。
我们试过 React.memo、useMemo、useCallback，但在复杂嵌套模型里会变成自定义比较函数和依赖数组地狱。最后没有全盘重写，而是只把输入草稿、拖拽临时坐标这类高频热点状态抽出来，用 Preact Signals 做细粒度更新；真正的领域模型仍然在提交时回写到不可变数据树里。
结果是输入体验明显变顺，也减少了大量防御性 memo 代码。我的体会是：性能优化不能只靠缓存补丁，很多时候要先判断状态更新粒度是不是太粗。

完整回答模板

面试官如果问“你做过哪些有挑战的性能优化”，可以这样讲：

“我之前做过一个支持多人协作的领域建模工具，类似 DDD 可视化画布。画布上会有聚合根、实体、值对象等节点，数量一多，用户在右侧属性面板编辑某个节点字段时，输入框会出现明显卡顿。

一开始我们怀疑是自动保存造成的网络延迟，但录了一段 Chrome Performance 后发现，接口不是主要问题，主线程主要耗时集中在 React 的 render 和 commit 阶段。再结合 React Profiler 看，发现一次字段输入会带出大量画布节点、连线、属性面板的重新渲染。

根因是我们的领域模型是一棵比较深的不可变数据树，并且通过顶层 Context 往下传。这个设计对一致性很好，但副作用是：哪怕只改一个深层字段，也会生成新的根对象，导致订阅这个 Context 的组件大面积刷新。

我们一开始也按常规思路加过 React.memo、useMemo、useCallback。但这个场景里 props 很复杂，很多都是嵌套对象，最后不得不写大量自定义 areEqual，回调也到处包 useCallback。它确实能挡住一部分渲染，但维护成本很高，而且只要某个引用不稳定，优化就会失效。

后来我们换了思路：不是继续在 React 自顶向下刷新链路上打补丁，而是把高频、局部、短生命周期的状态从全局模型里拆出来。比如输入框里的草稿值、拖拽时的临时坐标，用 Preact Signals 管；领域模型、协同状态、历史记录仍然走原来的不可变数据流，只在 blur、debounce commit 或 drag end 时统一提交。

这样做之后，每次键盘输入不再触发整棵画布刷新，更新范围基本收敛到真正消费这个 Signal 的局部区域。输入卡顿明显消失，代码里为了防御重渲染写的 memo 样板也少了很多。

所以这次优化给我的经验是：性能问题不一定是某个组件太慢，也可能是状态响应模型太粗。先缩小更新边界，再决定要不要加缓存，这比一上来全局 memo 更可靠。”

排查链路

  1. 先排除网络假设
    看接口耗时、自动保存链路和资源瀑布图，确认不是请求慢导致输入阻塞。

  2. 用 Chrome Performance 看主线程
    如果一次输入后出现长任务，并且耗时集中在 scripting、render、commit，就说明问题更偏前端运行时。

  3. 用 React Profiler 看重渲染范围
    看一次输入到底触发了哪些组件更新。如果画布节点、边、右侧面板、工具栏都跟着刷，基本可以怀疑状态边界过大。

  4. 回到状态流检查根因
    重点看是否存在“大 Context / 大对象 / 深层不可变树”的组合：局部字段更新导致根引用变化，根引用变化导致订阅方全体更新。

为什么不直接堆 memo

React.memo、useMemo、useCallback 不是不能用，而是不能作为第一反应。

在复杂建模场景里，它们容易出现几个问题：

  • props 是深层领域对象，浅比较经常失效。
  • 自定义 areEqual 容易写得很重，甚至比较成本接近重新渲染成本。
  • 回调函数层层下传后，useCallback 会制造大量依赖数组维护成本。
  • 只要某个对象引用不稳定，整条 memo 链路就会被击穿。
  • 代码会从“表达业务”变成“防御 React 重渲染”。

更稳的顺序是：

先收缩状态更新边界，再做局部 memo；先减少需要做的工作，再缓存不得不做的工作。

Signals 的使用边界

这里不要把 Signals 讲成“替代 React 状态管理”。更准确的说法是：

Signals 只接管高频、局部、短生命周期的热点状态；权威领域模型仍然走原来的统一数据流。

适合放进 Signal 的状态：

  • 输入框草稿值
  • 拖拽过程中的临时坐标
  • hover、focus、selection 这类局部交互态
  • 不影响全局一致性的局部展示态

不适合放进 Signal 的状态：

  • 领域模型的最终权威数据
  • 需要协同同步的数据
  • 需要进入 undo/redo history 的变更
  • 影响节点、边、选择态一致性的聚合操作

关键架构取舍

1. 输入过程和提交过程分离

输入时更新局部 Signal，保持交互流畅；提交时再写回不可变领域模型。

// 伪代码：表达边界，不强调具体库 API
const draftName = signal(node.name)
 
function onInput(value: string) {
  draftName.value = value
}
 
function onCommit() {
  updateDiagramModel({
    nodeId: node.id,
    name: draftName.value,
  })
}

2. 临时状态和权威状态分离

拖拽过程中的位置可以是临时状态；拖拽结束后的最终位置才进入全局模型、协同同步和历史记录。

3. 局部优化不能破坏聚合一致性

画布这种场景里，真正的聚合根通常是整个 diagram，而不是单个 node。Signals 只是降低交互过程中的更新粒度，不能绕开 diagram 对 nodes、edges、selection、history 的一致性维护。这里可以和 聚合根与全局状态管理怎么讲 连起来讲。

严谨表述

如果用的是 React + @preact/signals-react，不要把话说成：

Signal 完全绕过虚拟 DOM，直接精准更新 DOM。

更稳的说法是：

我们没有再把每次输入都提升成顶层 React State，而是把高频局部状态放到 Signal 里，让更新范围限制在真正消费这个 Signal 的局部组件上，避免整棵画布因为 Context 根对象变化而连带刷新。

可以量化的结果口径

真实面试里最好补一组自己的数据。没有数据时不要硬编，可以这样表达：

  • 优化前：一次输入会触发大面积画布节点重渲染，React Profiler 里 commit 时间经常超过一帧预算。
  • 优化后：输入链路只更新属性面板里的局部消费方，画布主体不再被每个字符输入带着刷新。
  • 体验结果：输入延迟和掉帧明显减少，节点数量上去后仍然可编辑。
  • 工程结果：删除了一批防御性 memo / useCallback 样板，维护成本下降。

高频追问

为什么不用 Zustand、Jotai 或 Context Selector？

可以用。关键不在 Signals 这个具体库，而在细粒度订阅和局部更新。如果团队已有 Zustand，也可以通过 selector + shallow compare 收缩更新范围；如果用 useSyncExternalStore 也能做类似事情。我们当时选择 Signals，是因为它对局部高频状态的表达更轻，改动范围也更小。

会不会破坏 React 单向数据流？

不会，前提是边界要清楚。Signal 只承载交互过程中的临时态；真正影响业务一致性的提交，仍然通过统一 action 写回领域模型。也就是说，Signals 不是新的业务真相源，而是热点路径上的交互缓冲层。

协同编辑时怎么处理远端更新？

本地草稿和远端权威状态要分层。用户正在输入时，本地草稿优先保证输入体验；远端变更进入底层模型后，可以通过版本号、dirty 标记或冲突提示决定是否合并到草稿。不要让远端同步直接覆盖用户正在编辑的输入框。

这次优化的核心经验是什么？

不要把性能优化理解成“给组件加缓存”。真正要先问的是：这次用户操作为什么会影响这么大的范围？如果状态边界错了，memo 只是止痛药；把更新粒度改对，才是治病。

相关笔记

  • 交互卡顿怎么讲
  • 性能问题高频追问怎么答
  • 性能公共素材
  • React Fiber
  • 聚合根与全局状态管理怎么讲

Graph View