React的并发悖论

更新日期: 2023-04-20阅读: 1k标签: React

大家好,我卡颂。

当一个react应用逻辑变得复杂后,组件render花费的时间会显著增长。如果从组件render视图渲染期间消耗的时间过长,用户就会感知到页面卡顿。

为了解决这个问题,有两个方法:

  1. 组件render的过程从同步变为异步,这样render过程页面不会卡死。这就是并发更新的原理
  2. 减少需要render的组件数量,这就是常说的React性能优化

通常,对于不同类型组件,我们会采取以上不同的方法。比如,对于下面这样的有耗时逻辑的输入框,方法1更合适(因为并发更新能减少输入时的卡顿):

function ExpensiveInput({onChange, value}) {
  // 耗时的操作
  const cur = performance.now();
  while (performance.now() - cur < 20) {}

  return <input onChange={onChange} value={value}/>;
}

那么,能不能在整个应用层面同时兼顾这2种方式呢?答案是 —— 不太行。

这是因为,对于复杂应用,并发更新与性能优化通常是相悖的。就是本文要聊的 —— 并发悖论。


从性能优化聊起

对于一个组件,如果希望他非必要时不render,需要达到的基本条件是:props的引用不变。

比如,下面代码中Child组件依赖fn props,由于fn是内联形式,所以每次App组件render时引用都会变,不利于Child性能优化:

function App() {
  return <Child fn={() => {/* xxx */}}/>
}

为了Child性能优化,可以将fn抽离出来:

const fn = () => {/* xxx */}

function App() {
  return <Child fn={fn}/>
}

当fn依赖某些props或者state时,我们需要使用useCallback:

function App({a}) {
  const fn = useCallback(() => a + 1, [a]);
  return <Child fn={fn}/>
}

类似的,其他类型变量需要用到useMemo。

也就是说,当涉及到性能优化时,React的代码逻辑会变得复杂(需要考虑引用变化问题)。

当应用进一步复杂,会面临更多问题,比如:

  • 复杂的useEffect逻辑
  • 状态如何共享

这些问题会与性能优化问题互相叠加,最终导致应用不仅逻辑复杂,性能也欠佳。


性能优化的解决之道

好在,这些问题有个共同的解决方法 —— 状态管理。

上文我们聊到,对于性能优化,关键的问题是 —— 保持props引用不变。

在原生React中,如果a依赖b,b依赖c。那么,当a变化后,我们需要通过各种方法(比如useCallback、useMemo)保持b、c引用的稳定。

做这件事情本身(保持引用不变)对开发者来说就是额外的心智负担。那么,状态管理是如何解决这个问题的呢?

答案是:状态管理库自己管理所有原始状态以及派生状态。

比如:

  • 在Recoil中,基础状态类型被称为Atom,其他派生状态都是基于Atom组合而来
  • 在Zustand中,基础状态都是create方法创建的实例
  • 在Redux中,维护了一个全局状态,对于需要用到的状态通过selector从中摘出来

这些状态管理方案都会自己维护所有的基础状态与派生状态。当开发者从状态管理库中引入状态时,就能最大限度保持props引用不变。

比如,下例用Zustand改造上面的代码。由于状态a和依赖a的fn都是由Zustand管理,所以fn的引用始终不变:

const useStore = create(set => ({
  a: 0,
  fn: () => set(state => ({ a: state.a + 1 })),
}))


function App() {
  const fn = useStore(state => state.fn)
  return <Child fn={fn}/>
}


并发更新的问题

现在我们知道,性能优化的通用解决途径是 —— 通过状态管理库,维护一套逻辑自洽的外部状态(这里的外部是区别于React自身的状态),保持引用不变。

但是,这套外部状态最终一定会转化为React的内部状态(再通过内部状态的变化驱动视图更新),所以就存在状态同步时机的问题。即:什么时候将外部状态与内部状态同步?

在并发更新之前的React中,这并不是个问题。因为更新是同步、不会被打断的。所以对于同一个外部状态,在整个更新过程中都能保持不变。

比如,在如下代码中,由于List组件的render过程不会打断,所以list在遍历过程中是稳定的:

function List() {
  const list = useStore(state => state.list)
  return (
    <ul>
      {list.map(item => <Item key={item.id} data={item}/>}
    </ul>
  )
}

但是,对于开启并发更新的React,更新流程可能中断,不同的Item组件可能是在中断前后不同的宏任务中render,传递给他们的data props可能并不相同。这就导致同一次更新,同一个状态(例子中的list)前后不一致的情况。

这种情况被称为tearing(视图撕裂)。

可以发现,造成tearing的原因是 —— 外部状态(状态管理库维护的状态)与React内部状态的同步时机出问题。

这个问题在当前React中是很难解决的。退而求其次,为了让这些状态库能够正常使用,React专门出了个hook —— useSyncExternalStore。用于将状态管理库触发的更新都以同步的方式执行,这样就不会有同步时机的问题。

既然是以同步的方式执行,那肯定没法并发更新啦~~~


总结

实际上,凡是涉及到自己维护了一个外部状态的库(比如动画库),都涉及到状态同步的问题,很有可能无法兼容并发更新。

所以,你会更倾向下面哪种选择呢:

  1. 不care并发更新,以前React怎么用,现在就怎么用
  2. 根据项目情况,平衡并发更新与性能优化的诉求
作者:卡颂,来源:https://segmentfault.com/a/1190000043701654

链接: https://fly63.com/article/detial/12445

如何优雅的设计 React 组件

如今的 Web 前端已被 React、Vue 和 Angular 三分天下,尽管现在的 jQuery 已不再那么流行,但 jQuery 的设计思想还是非常值得致敬和学习的,特别是 jQuery 的插件化。

React深度编程:受控组件与非受控组件

受控组件与非受控组件在官网与国内网上的资料都不多,有些人觉得它可有可不有,也不在意。这恰恰显示React的威力,满足不同规模大小的工程需求。

React框架学习_关于React两种构建应用方式选择

一般在传统模式下,我们构建前端项目很简单。就是下载各种js文件,如JQuery、Echart等,直接放置在html静态文件。Webpack则是JavaScript中比较知名的打包工具。这两个构建工具构成了React应用快速搭建的基础。

Gatsby.js_一款基于React.js静态站点生成工具

Gatsby能快速的使用 React 生态系统来生成静态网站,可以结合React Component、Markdown 和服务端渲染来完成静态网站生成让他更强大。

React创建组件的三种方式及其区别

React推出后,出于不同的原因先后出现三种定义react组件的方式,殊途同归;具体的三种方式:函数式定义的无状态组件、es5原生方式React.createClass定义的组件、es6形式的extends React.Component定义的组件

react生命周期详解_深入理解React生命周期

React主要思想是通过构建可复用组件来构建用户界面,每个组件都有自己的生命周期,它规定了组件的状态和方法需要在哪个阶段改变和执行。所谓组件就是有限状态机,,表示有限个状态以及在这些状态之间的转移和动作行为的模型。

React + Webpack 构建打包优化

React 相关的优化:使用 babel-react-optimize 对 React 代码进行优化,检查没有使用的库,去除 import 引用,按需打包所用的类库,比如 lodash 、echarts 等.Webpack 构建打包存在的问题两个方面:构建速度慢,打包后的文件体积过大

react router中页面传值的三种方法

这篇文章主要介绍React Router定义路由之后如何传值,有关React和React Router 。react router中页面传值的三种方法:props.params、query、state

react 高阶组件的 理解和应用

react 高阶组件简单的理解是:一个包装了另一个基础组件的组件。高阶组件的两种形式:属性代理(Props Proxy)、反向继承 (Inheritance Inversion)

react中的refs属性的使用方法

React 支持一种非常特殊的属性 Ref ,你可以用来绑定到 render() 输出的任何组件上。这个特殊的属性允许你引用 render() 返回的相应的支撑实例( backing instance )。这样就可以确保在任何时间总是拿到正确的实例

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!