Odoo 里的 OWL 响应式为什么不等于“改了 state 就重渲染”：reactive、batched render 与 Scheduler 调度讲透

很多人刚接触 OWL，会形成一种很顺手、但不够准确的理解：

改了 state，组件就重渲染。

这句话不能说错，但如果你真的去读 Odoo 里的 addons/web/static/lib/owl/owl.js，会发现它省略了大量关键中间层。

真实发生的事情更像这样：

1. 组件在渲染时读取响应式数据；
2. 读取行为建立订阅关系；
3. 数据变化后，不是立刻同步重画，而是先进入批处理；
4. 批处理后的 render 会挂到 fiber；
5. 最终再由 Scheduler 统一调度，按帧把结果应用到 DOM。

也就是说，Odoo 里的 OWL 响应式真正解决的不是“会不会重渲染”，而是：

在一个复杂、深层、频繁变化的 Web Client 里，怎样让状态变化既灵敏，又不把渲染节奏搞炸。

一、useState 的关键不是 state，而是“当前组件订阅了谁”

在 owl.js 里，useState(state) 最重要的代码不是创建对象，而是：

• 先找到当前组件节点 getCurrent()；
• 给该节点绑定一个 batched 的 render 回调；
• 再把这个回调交给 reactive(state, render)。

这说明 useState 真正做的事不是“把对象变响应式”，而是：

把当前组件的渲染函数登记为这个状态对象的观察者。

所以响应式并不是“对象自己会渲染”，而是“组件在读取对象时，建立了自己与这份数据的关系”。

这个区别非常重要。

因为它意味着 Odoo / OWL 不是粗暴地“某对象一变，所有相关组件全刷”，而是尽量让更新只通知真正读过该数据的渲染回调。

二、reactive 的本质不是魔法代理，而是“读时订阅，写时通知”

源码里 reactive(target, callback) 暴露了 OWL 响应式最核心的心智模型。

虽然实现细节不少，但你抓住一句话就够了：

• 读属性时，收集依赖；
• 写属性时，通知回调。

这也是为什么很多时候“没读过的数据变化了，组件不一定更新”。

不是框架漏了，而是这个组件上一次渲染根本没对那块数据建立订阅。

从性能角度看，这比“整个 state 树任意变化都全量刷新”要精细得多。

三、为什么 useState 绑定的不是普通 render，而是 batched(render)

useState 里有个特别关键的细节：

render = batched(node.render.bind(node, false));

batched 的意思不是“晚点再说”，而是把同一微任务周期内的多次触发收束成一次调用。

这层非常重要，因为 Web Client 里常见的状态变化不是单发子弹，而是一串连锁反应：

• 一个输入更新本地 state；
• 触发派生计算；
• 某些 hook 又写别的状态；
• service 回来再补一次；
• 父子组件可能还互相联动。

如果每一次变化都同步 render，代价会很高：

• 同一轮逻辑里重复渲染；
• 中间态被无意义地刷到屏幕；
• 大量 patch 彼此覆盖。

batched 就是在这里帮系统止血：

先把密集变化压平，再交给渲染层。

四、Fiber 的价值不是“更高级”，而是把渲染变成可管理任务

在 OWL 里，渲染不是直接 component.render() 然后立刻 patch DOM 这么简单。

源码里会创建 fiber，把渲染工作挂到节点与应用实例上。

这背后最重要的意义是：

• 渲染可以被排队；
• 渲染可以被取消；
• 新渲染可以替换旧渲染；
• 渲染完成和应用到 DOM 可以分阶段处理。

这就是为什么源码里会有很多关于 fiber, root, current, appliedToDom, cancelledNodes 的状态判断。

如果没有这层，复杂 UI 里很容易出现这样的问题：

• 旧渲染还没落地，新状态又来了；
• 组件正在卸载，异步渲染却还想 patch；
• 父组件和子组件更新交错，最终应用顺序混乱。

Fiber 不是为了炫技，而是为了把“渲染”变成可调度、可中断、可收敛的任务单元。

五、Scheduler 真正管的是“什么时候把这些任务安全落地”

Scheduler 是另一段非常值得细看的源码。

它内部维护：

• tasks
• delayedRenders
• cancelledNodes
• processing
• frame

而且明确绑定 requestAnimationFrame。

这件事透露了一个核心设计取向：

OWL 不想在每次状态变更后立刻抢着 patch DOM，而是希望把 DOM 应用节奏收束到浏览器更适合刷新的时机。

这样做的好处非常直接：

1）减少无意义的中间帧

如果一连串状态更新最终只需要一个稳定结果，就没必要让用户看到中间态狂闪。

2）更容易收拢父子更新

多个 fiber 在同一帧内被处理，渲染关系更可控。

3）避免已销毁节点继续被 patch

scheduleDestroy()、cancelledNodes、状态检查，都是在保证已经不该活着的节点别再参与 DOM 落地。

六、为什么源码里还有 delayedRenders

这部分非常能体现 OWL 的谨慎。

某些渲染如果发生在不合适的阶段，比如当前已有更高层渲染正在进行，系统不会强行立刻递归下去，而是先放进 delayedRenders，再在 flush() 中处理。

这其实是在解决一个经典难题：

• 父组件渲染过程中，子组件又触发了自己的 render；
• 如果立刻执行，可能和当前渲染树打架；
• 如果彻底忽略，又会丢更新。

delayedRenders 的策略就是：

先记账，等合适时机再统一冲刷。

这让框架能在“响应及时”和“结构稳定”之间取得平衡。

七、为什么响应式更新不是同步 DOM 更新

很多前端初学者容易把这两件事混成一件：

• state 变化；
• DOM 变化。

但在 Odoo 的 OWL 里，中间至少还隔着：

• 依赖通知；
• batched 收束；
• fiber 渲染；
• scheduler 调度；
• patch 应用。

这条链路说明一个非常实用的判断：

如果你在调试某个“改了 state 但界面没立刻那样变”的问题，不要只盯着组件本身，要想想它卡在这条链路的哪一层。

有时是没订阅到，有时是批处理合并了，有时是旧 fiber 被取消了，有时只是还没到应用那一帧。

八、这套机制为什么特别适合 Odoo Web Client

因为 Odoo Web Client 的状态变化天然很碎，也很频繁：

• 列表与表单切换；
• 控件输入与 onchange；
• 服务返回后更新界面；
• 命令、通知、侧边栏、编辑器同时变化；
• 某些地方还有 iframe、overlay、懒组件。

如果这里用最朴素的“变一次刷一次”模式，很快就会出现：

• 渲染过密；
• 中间态抖动；
• 卸载后仍被异步更新；
• 父子 patch 顺序不好控。

OWL 这套 reactive + batched + fiber + scheduler 的组合，本质上就是为这种复杂前端环境准备的。

九、二开时最容易犯的几个误区

误区 1：把响应式理解成同步副作用

改了 state 后立刻去假设 DOM 已经完全稳定，往往会踩空。

误区 2：在渲染链中塞太多额外写操作

如果某些逻辑在 render / patch 周边又不断写 state，很容易制造不必要的连锁更新。

误区 3：以为“没更新”就一定是框架失效

很多时候只是没有建立订阅，或者更新被 batched / cancel 掉了。

误区 4：忽视销毁时机

组件已经走向卸载，但外部异步逻辑还在往回写，最后就会出现经典的“幽灵更新”。

十、结论

Odoo 里的 OWL 响应式，绝不只是“state 一变就重渲染”这么简单。

从 owl.js 能看得很清楚：

• reactive 负责读时订阅、写时通知；
• useState 把组件 render 绑定成观察回调；
• batched 负责把密集更新压成更少的 render；
• fiber 负责把渲染变成可管理任务；
• Scheduler 负责按更稳定的节奏把任务落到 DOM。

所以更准确的一句话应该是：

OWL 响应式不是“改 state 就刷屏”，而是“把状态变化收束成可调度的渲染任务，再在合适时机稳定落地”。

理解了这件事，你再做 Odoo 前端调优、调试卡顿、排查“为什么这次没马上重画”的问题时，视角会立刻清楚很多。