关于javascript:可视化搭建-自动批处理与冻结

性能在可视化搭建也是极为重要的，如何尽可能减少业务感知，最大水平的晋升性能是要害。

其实申明式肯定水平上能够说是就义了性能换来了可维护性，所以在一个齐全申明式的框架下做性能优化还是十分有挑战的。咱们采取了两种策略来优化性能，别离是主动批处理与解冻。

主动批处理

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

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 就提供了解冻能力，从根本上解决视窗外组件造成的性能影响。为什么能够基本解决性能影响呢？因为处于解冻态的组件：

• 前置性。通过 defaultFreeze 在组件元信息初始化设置为 false，那么所有初始化逻辑都不会执行。
• 不会响应任何状态变更，连内置的 selector 执行都会间接跳过，齐全屏蔽了这个组件的存在，能够让 Designer 外部调度逻辑大大提效。
• 不会触发重渲染。如果组件初始化就设置为解冻，那么初始化渲染也不会执行。

怎么应用解冻能力？

倡议对立把所有组件 defaultFreeze 设置为 true，而后找一个中央监听滚动或者视窗的变动，通过 setFreeze 响应式的把视窗内组件冻结，把移除视窗的组件解冻。

特地留神，如果有组件联动，解冻了触发组件会导致联动生效，因而业务最好把那些 即使不在视窗内，也要作用联动 的组件放弃冻结状态。

总结

总结一下，首先因为申明式代码中批改状态的中央很扩散，甚至执行机会都交由框架外部管制，因而手动 batch 必定是不可行的，基于此失去了更不便，性能全方面优化了的主动 batch。

其次是业务层面的优化，当组件在视窗外后，对其所有响应监听都能够进行，所以咱们想到定义出解冻的概念，让业务自行决定哪些组件处于解冻态，同时解冻的组件从元信息的所有回调函数，到渲染都会齐全进行，能够说，画布即使存在一万个解冻状态的组件，也仅仅只有内存耗费，齐全能够做到 0 CPU 耗费。

探讨地址是：精读《主动批处理与解冻》· Issue #484 · dt-fe/weekly

如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。

关注 前端精读微信公众号

<img width=200 src=”https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg”>

版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）