可视化搭建 - 自动批处理与冻结

黄子毅

发布于 2023-09-01 09:15:22

1360

发布于 2023-09-01 09:15:22

文章被收录于专栏：前端精读评论

性能在可视化搭建也是极为重要的，如何尽可能减少业务感知，最大程度的提升性能是关键。

其实声明式一定程度上可以说是牺牲了性能换来了可维护性，所以在一个完全声明式的框架下做性能优化还是非常有挑战的。我们采取了两种策略来优化性能，分别是自动批处理与冻结。

自动批处理

首先，框架内任何状态更新都不会立即触发响应，而是统一收集起来后，一次性触发响应，如下面的例子：

const divMeta: ComponentMeta = {
  // ...
  fetcher: ({ selector, setRuntimeProps, componentId }) => {
    const name = selector(({ props }) => props.name)
    const email = selector(({ props }) => props.email)
    fetch('...', {
      data: { name, email }
    }).then((res) => {
      setRuntimeProps(componentId, old => ({
        ...old ?? {},
        data: res.data
      }))
    })
  }
}

const App = () => {
  const { setProps } = useDesigner()
  const onClick = useCallback(() => {
    setProps('1', props => ({ ...props, name: 'bob' }))
    setProps('1', props => ({ ...props, email: '666@qq.com' }))
  }, [])
}

上面例子中，fetcher 通过 selector 监听了 props.name 与 props.email，当连续调用两次 setProps 分别修改 props.name 与 props.email 时，只会合并触发一次 fetcher 而不是两次，这种设计让业务代码减少了重复执行的次数，简化了业务逻辑复杂度。

另一方面，在自动批处理的背后，还有一个框架如何执行 selector 的性能优化点，即框架是否能感知到 fetcher 依赖了 props.name 与 props.email？如果框架知道，那么当比如 props.appId 或者其他 state. 状态变化时，根本不需要执行 fetcher 内的 selector 判断返回引用是否变化，这能减少巨大的碎片化堆栈时间。

一个非常有效的收集方式是利用 Proxy，将 selector 内用到的数据代理化，利用代理监听哪些函数绑定了哪些变量，并在这些变量变化时按需重新执行。

笔者用一段较为结构化的文字描述这背后的性能优化是如何发生的。

一、组件元信息声明式依赖了某些值

比如下面的代码，在 meta.fetcher 利用 selector 获取了 props.name 与 props.email 的值，并在这些值变化时重新执行 fetcher。

const divMeta: ComponentMeta = {
  // ...
  fetcher: ({ selector, setRuntimeProps, componentId }) => {
    const name = selector(({ props }) => props.name)
    const email = selector(({ props }) => props.email)
  }
}

在这背后，其实 selector 内拿到的 props 或者 state 都已经是 Proxy 代理对象，框架内部会记录这些调用关系，比如这个例子中，会记录组件 ID 为 1 的组件，fetcher 绑定了 props.name 与 props.email。

二、状态变化

当任何地方触发了状态变化，都不会立刻计算，而是在 nextTick 时机触发清算。比如：

setProps('1', props => ({ ...props, name: 'bob' }))
setProps('1', props => ({ ...props, email: '666@qq.com' }))

虽然连续触发了两次 setProps，但框架内只会在 nextTick 时机总结出发生了一次变化，此时组件 ID 为 1 的组件实例 props.name 与 props.email 发生了变化。

接着，会从内部 selector 依赖关系的缓存中找到，发现只有 fetcher 函数依赖了这两个值，所以就会精准的执行 fetcher 中两个 selector，执行结果发现相比之前的值引用变化了，最后判定需要重新执行 fetcher，至此响应式走完了一次流程。

当然在 fetcher 函数内可能再触发 setProps 等函数修改状态，此时会立刻进入判定循环直到所有循环走完。另外假设此次状态变化没有任何 meta 声明式函数依赖了，那么即便画布有上千个组件，每个组件实例绑定了十几个 meta 声明式函数，此时都不会触发任何一个函数的执行，性能不会随着画布组件增加而恶化。

冻结

冻结可以把组件的状态凝固，从而不再响应任何事件，也不会重新渲染。

const chart: ComponentMeta = {
  /** 默认 false */,
  defaultFreeze: true
}

或者使用 setFreeze 修改冻结状态:

const { setFreeze } = useDesigner()
// 设置 id 1 的组件为冻结态
setFreeze('1', true)

为什么要提供冻结能力？

当仪表盘内组件数量过多时，业务上会考虑做按需加载，或者按需查询。但因为组件间存在关联关系，可视化搭建框架（我们用 Designer 指代）在初始化依然会执行一些初始函数，比如 init，同时组件依然会进行一次初始化渲染，虽然业务层会做一些简化处理，比如提前 Return null，但组件数量多了之后想要扣性能依然还有优化空间。

所以 Designer 就提供了冻结能力，从根本上解决视窗外组件造成的性能影响。为什么可以根本解决性能影响呢？因为处于冻结态的组件：