React各版本性能优化方案原理分析

前沿

开发动画复杂或是很重的项目 react真的会比原生js性能要好吗？
之前尝试用canvas开发动画时候发现绘制动画时候需要调用ctx.clearRect清除上一帧动画如果当前真动画计算量比较大导致清楚上一帧画面到绘制当前帧画面会有很长时间页面会白屏怎么办？
其实react很多设计思想完全可以用到我们平时的代码里面

一、前端框架对比 React vs Vue

vue属于编译时优化而react属于重运行时优化

1.vue 编译时优化

什么是编译时优化？

vue是模版语法我们使用模版的方式去编码虽然没有jsx那样动态但是v-if v-for是可枚举可控的我们在编译时可以做更多的预判使优化变得更方便下面是vue3做的优化

传统虚拟dom会按照div标签一级一级进行遍历计算因此性能就和模版大小呈正相关但是每个模版能变化的节点属实有限永远不会变化的节点我们没有必要浪费时间去检查因此diff阶段跳过静态节点

vue3.0有一条性能优化就是 complier 时的 transform 阶段解析 AST Element 打上的补丁标记。比如节点具有动态的不同属性都会被不同的patchflag标签然后 patchflag 再配合 block tree，就可以做到对不同节点的靶向更新。
主要分为两大类

当 patchFlag 的值大于 0 时，代表所对应的元素在 patchVNode 时或 render 时是可以被优化生成或更新的

当 patchFlag 的值小于 0 时，代表所对应的元素在 patchVNode 时，是需要被 full diff，即进行递归遍历 VNode tree 的比较更新过程。

能带patchFlag 的 Node 才被认为是动态的元素，会被追踪属性的修改

统计那个动态的部分最多只有三分之一，所以在编译的过程中发现那个比较小的动态部分，把它放到比较靠上的等级模块上，那么就可以称那个比较靠上的模块为block区块树，在这个动态变化的区块增加一个Array去追踪自身动态节点。那么意味着将来这个模块重新更新的时候，就不会再向下进行一层一层递归了，只做这个模块的动态部分的更新。

在3.0 里，渲染效率不再与模板大小成正相关，而是与模板中动态节点的数量成正相关。

2.React运行时优化

react的思路是js写法很灵活这就让编译时无法做过多的处理

const getName = (obj) => {
  return obj.a + obj.b
}
const obj = {a: 1, b: 2}

const element = (
  {getname(obj)}
)
ReactDOM.render(element, document.getElementById('root'))

因此React就要在运行时关注CPU性能的问题以及IO问题

CPU：主流浏览器的刷新频率一般是 60Hz，也就是每秒刷新 60 次，大概 16.6ms 浏览器刷新一次。由于 GUI 渲染线程和 JS 线程是互斥的，所以 JS 脚本执行和浏览器布局、绘制不能同时执行。
在这 16.6ms 的时间里，浏览器需要完成 JS 的执行，也需要完成样式的重排和重绘，如果 JS 某个任务时间过长超出了 16.6ms，这次刷新就没有时间执行样式布局绘制在页面上就会表现为卡顿
IO：如果组件需要等待一些长时间网络请求，如果网络延的话就需要减少用户对网络延迟的感知

二、React框架的优化历程

1、react15

组成部分

Reconciler：负责调用 render 生成虚拟 Dom 进行 Diff，找出变化后的虚拟 Dom
Renderer：负责接到 Reconciler 通知，将变化的组件渲染在当前宿主环境，比如浏览器，不同的宿主环境会有不同的 Renderer

优化点：半自动批处理

因为 setState 是同步的，当同时触发多次 setState 时浏览器会一直被JS线程阻塞，那么那么浏览器就会掉帧，导致页面卡顿，所以 React 才引入了批处理的机制，为了将同一上下文中触发的更新合并为一个更新

componentDidMount() {
    this.setState({val: this.state.val + 1});
    console.log(this.state.val);   
    this.setState({val: this.state.val + 1});
    console.log(this.state.val);   

    setTimeout(() => {
      this.setState({val: this.state.val + 1});
      console.log(this.state.val); 
      this.setState({val: this.state.val + 1});
      console.log(this.state.val);  
    }, 0);
  }
// 结果 0 0 2 3

 _processPendingState: function (props, context) {
  var inst = this._instance;
  var queue = this._pendingStateQueue;
  var replace = this._pendingReplaceState;
  this._pendingReplaceState = false;
  this._pendingStateQueue = null;

  if (!queue) {
   return inst.state;
  }
  ...

  var nextState = _assign({}, replace ? queue[0] : inst.state);
  for (var i = replace ? 1 : 0; i < queue.length; i++) {
   var partial = queue[i];

   _assign(nextState, typeof partial === 'function' ? partial.call(inst, nextState, props, context) : partial);
  }

  return nextState;
 },

可以看到不管执行几次setstate 只会拿到最后一次变更去更新

其实这里也存在一个bug 就是在setTimeout里面的setstate没有批处理这个在React18做了修复等下面会讲到

缺陷：React15的性能瓶颈：

为什么 react 早在几年前就提出了 fiber 方案：主要是因为 react 15 在 mount 或 diff 过程中，并没有考虑到组件树过于庞大的问题，由于这两个过程是从父到子的递归渲染，且浏览器的单线程限制 ui渲染线程和js线程互斥，在运行 JS 的时候，无法渲染 DOM，所以导致在组件树太庞大的情况下，会造成用户卡顿，也无法对页面进行任何操作。

当层级很深时，递归更新时间超过了 16ms

2、react16 Fiber

在 CPU 上，我们的主要问题是，在 JS 执行超过 16.6 ms 时，页面就会产生卡顿，那么 React 的解决思路，就是在浏览器每一帧的时间中预留一些时间给 JS 线程，React 利用这部分时间更新组件。当预留的时间不够用时，React 将线程控制权交还给浏览器让他有时间渲染UI，React 则等待下一帧再继续被中断的工作。Fiber就做到了可中断

浏览器帧的概念

某任务执行时间过长超过16ms 渲染就会推迟造成页面卡顿
浏览器大概一帧有10毫秒的空闲时间我们可以在这个空闲做一些事情

Fiber就利用了这一思想

Fiber大体思路

fiber是一个执行单元每执行完一个单元浏览器就会检查剩余多少时间没有时间就将控制权让出
通过fiber架构让协调过程变成可中断的适时让出cpu执行权提高响应速度

fiber工作单元

举例说明

五个元素先处理A1 比如一共10ms A1执行5ms 还有时间看是否存在下一单元看下一个是B1 执行B1 检查是否有剩余时间没时间或者没有下一个单元了执行权交还浏览器那一什么样的方式去停止他们再回来执行C1呢那就需要一个明确的顺序因此需要一个fiber数据结构

requestIdleCallback

requestIdleCallback使开发者在主事件循环上执行后台和低优先级工作不会影响延迟关键事件：动画和输入响应
正常帧执行完任务后没超过16ms 说明有时间空余就会执行requestIdleCallback里面的注册任务
requestAnimationFrame回调会在每一帧确定执行属于高优先级任务 requestIdleCallback不一定它属于低优先级任务

申请时间切片

举个

requestIdleCallback(myWork)
function sleep(duration) {
  let start = Date.now();
  while(start + duration> Date.now()) {

  }
}

// 一个任务队列
let tasks = [

  function t1() {
    console.log('执行任务1')
    sleep(20);
    console.log('结束任务1')
  },
  function t2() {
    console.log('执行任务2')
    sleep(20);
    console.log('结束任务2')
  },
  function t3() {
    console.log('执行任务3')
    sleep(20);
    console.log('结束任务3')
  },
]

// deadline是requestIdleCallback返回的一个对象
function myWork(deadline) {
  console.log(`当前帧剩余时间: ${deadline.timeRemaining()}`)
  // 查看当前帧的剩余时间是否大于0 && 是否还有剩余任务
  if (deadline.timeRemaining() > 0 && tasks.length) {
    // 在这里做一些事情
    const task = tasks.shift()
    task()
  }
  // 如果还有任务没有被执行，那就放到下一帧调度中去继续执行，类似递归
  if (tasks.length) {
  console.log(`当前帧剩剩余: ${deadline.timeRemaining()} 执行下次真`)

    requestIdleCallback(myWork)
  }
}

requestIdleCallback将任务分割成一个个小任务

由于兼容性和刷新帧率的问题，React 并没有直接使用 requestIdleCallback ，而是使用了 MessageChannel 模拟实现下面会详细讲解原理

核心原理

架构

Reconciler 的工作就是使用 Diff 算法对比生成 workInProgress Fiber ，这个阶段是可中断的
Renderer 的工作是把 workInProgress Fiber 转换成真正的 DOM 节点

一、调度器 - Scheduler

调度任务的优先级，高优任务优先进入 Reconciler 利用时间切片，就可以根据当前的宿主环境性能，为每个工作单元分配一个可运行时间，从而实现异步可中断的更新
Scheduler 就可以帮我们完成这件事情，我们可以看到，我们一次耗时很长的更新任务被拆分成一小段一小段的。这样浏览器就有剩余时间执行样式布局和样式绘制，减少掉帧的可能性

任务拆分

时间切片的本质，也就是模拟实现 requestIdleCallback 这个函数看下源码

调度任务

// 接收 MessageChannel 消息
const performWorkUntilDeadline = () => {
  if (scheduledHostCallback !== null) {
    const currentTime = getCurrentTime(); // 1. 获取当前时间
    deadline = currentTime + yieldInterval; // 2. 设置deadline
    const hasTimeRemaining = true;
    try {
      // 3. 执行回调, 返回是否有还有剩余任务
      const hasMoreWork = scheduledHostCallback(hasTimeRemaining, currentTime);
      if (!hasMoreWork) {
        // 没有剩余任务, 退出
        isMessageLoopRunning = false;
        scheduledHostCallback = null;
      } else {
        port.postMessage(null); // 有剩余任务, 发起新的调度
      }
    } catch (error) {
      port.postMessage(null); // 如有异常, 重新发起调度
      throw error;
    }
  } else {
    isMessageLoopRunning = false;
  }
  needsPaint = false; // 重置开关
};

const channel = new MessageChannel();
const port = channel.port2;
channel.port1.onmessage = performWorkUntilDeadline;

// 请求回调
requestHostCallback = function(callback) {
  // 1. 保存callback
  scheduledHostCallback = callback;
  if (!isMessageLoopRunning) {
    isMessageLoopRunning = true;
    // 2. 通过 MessageChannel 发送消息
    port.postMessage(null);
  }
};
// 取消回调
cancelHostCallback = function() {
  scheduledHostCallback = null;
};

时间切片(time slicing)相关: 执行时间分割, 让出主线程把控制权归还浏览器, 浏览器可以处理用户输入, UI 绘制等紧急任务
在 React 的 render 阶段，开启 Concurrent Mode 时，每次遍历前，也会通过 Scheduler 提供的 shouldYield 方法判断是否需要中断遍历，使浏览器有时间渲染
Fiber 架构配合 Scheduler 实现了 Concurrent Mode 的底层 — “异步可中断的更新

const localPerformance = performance;
// 获取当前时间
getCurrentTime = () => localPerformance.now();

// 时间切片周期, 默认是5ms(如果一个task运行超过该周期, 下一个task执行之前, 会把控制权归还浏览器)
let yieldInterval = 5;

let deadline = 0;
const maxYieldInterval = 300;
let needsPaint = false;
const scheduling = navigator.scheduling;
// 是否让出主线程
shouldYieldToHost = function() {
  const currentTime = getCurrentTime();
  if (currentTime >= deadline) {
    if (needsPaint || scheduling.isInputPending()) {
      // There is either a pending paint or a pending input.
      return true;
    }
    // There's no pending input. Only yield if we've reached the max
    // yield interval.
    return currentTime >= maxYieldInterval; // 在持续运行的react应用中, currentTime肯定大于300ms, 这个判断只在初始化过程中才有可能返回false
  } else {
    // There's still time left in the frame.
    return false;
  }
};

// 请求绘制
requestPaint = function() {
  needsPaint = true;
};

// 设置时间切片的周期
forceFrameRate = function(fps) {
  if (fps < 0 || fps > 125) {
    // Using console['error'] to evade Babel and ESLint
    console['error'](
      'forceFrameRate takes a positive int between 0 and 125, ' +
        'forcing frame rates higher than 125 fps is not supported',
    );
    return;
  }
  if (fps > 0) {
    yieldInterval = Math.floor(1000 / fps);
  } else {
    // reset the framerate
    yieldInterval = 5;
  }
};

任务队列管理

过上文的分析, 我们已经知道请求和取消调度的实现原理. 调度的目的是为了消费任务, 接下来就具体分析任务队列是如何管理与实现的.
在Scheduler.js维护了一个taskQueue任务队列管理就是围绕这个taskQueue展开
在unstable_scheduleCallback函数中(源码链接):

1.创建任务

// 省略部分无关代码
function unstable_scheduleCallback(priorityLevel, callback, options) {
  // 1. 获取当前时间
  var currentTime = getCurrentTime();
  var startTime;
  if (typeof options === 'object' && options !== null) {
    // 从函数调用关系来看, 在v17.0.2中,所有调用 unstable_scheduleCallback 都未传入options
    // 所以省略延时任务相关的代码
  } else {
    startTime = currentTime;
  }
  // 2. 根据传入的优先级, 设置任务的过期时间 expirationTime
  var timeout;
  switch (priorityLevel) {
    case ImmediatePriority:
      timeout = IMMEDIATE_PRIORITY_TIMEOUT;
      break;
    case UserBlockingPriority:
      timeout = USER_BLOCKING_PRIORITY_TIMEOUT;
      break;
    case IdlePriority:
      timeout = IDLE_PRIORITY_TIMEOUT;
      break;
    case LowPriority:
      timeout = LOW_PRIORITY_TIMEOUT;
      break;
    case NormalPriority:
    default:
      timeout = NORMAL_PRIORITY_TIMEOUT;
      break;
  }
  var expirationTime = startTime + timeout;
  // 3. 创建新任务
  var newTask = {
    id: taskIdCounter++,
    callback, // callback: 传入的回调函数
    priorityLevel, // priorityLevel: 优先级等级
    startTime,
    expirationTime, // expirationTime: task的过期时间, 优先级越高 expirationTime = startTime + timeout 越小
    sortIndex: -1,
  };
  if (startTime > currentTime) {
    // 省略无关代码 v17.0.2中不会使用
  } else {
    newTask.sortIndex = expirationTime;
    // 4. 加入任务队列
    push(taskQueue, newTask);
    // 5. 请求调度
    if (!isHostCallbackScheduled && !isPerformingWork) {
      isHostCallbackScheduled = true;
      requestHostCallback(flushWork);
    }
  }
  return newTask;
}

其实维护的队列就是一个小顶堆数组 用O(1)的复杂度就能找到优先级更高的任务

生命周期方法：是最高优先级、同步执行的。
受控用户输入：比如输入框内输入文字，同步执行。
交互事件：比如动画requestAnimationFrame，高优先级执行。
其他数据请求、使用了suspense、transition 这样的更新，是低优先级执行的。

注意⚠️：这个优先级的机制有别于Fiber链表构建中的优先级机制

实际上是 React 的 Scheduler 的优先级机制，在 React 内部，Scheduler 是一个独立包，它只负责任务的调度，甚至不关心这个任务具体是干什么，所以 Scheduler 内部的优先级机制也是独立于 React 的
React 内部也有一套自己的优先级机制，在Fiber链表中哪些 Fiber 以及哪些 Update 对象，是高优先级的。
在 React16 中，Fiber 和 Update 的优先级和任务的优先级是类似。React 会根据不同的操作优先级给每个 Fiber 节点的 Update 增加一个 expirationTime 由于某些问题，React 已经在 Fiber 中不再使用 expirationTime 去表示优先级下面会介绍

2.消费任务：

创建任务之后, 最后请求调度requestHostCallback(flushWork)(创建任务源码中的第 5 步), flushWork函数作为参数被传入调度中心内核等待回调. requestHostCallback函数在上文调度内核中已经介绍过了, 在调度中心中, 只需下一个事件循环就会执行回调, 最终执行flushWork

// 省略无关代码
function flushWork(hasTimeRemaining, initialTime) {
  // 1. 做好全局标记, 表示现在已经进入调度阶段
  isHostCallbackScheduled = false;
  isPerformingWork = true;
  const previousPriorityLevel = currentPriorityLevel;
  try {
    // 2. 循环消费队列
    return workLoop(hasTimeRemaining, initialTime);
  } finally {
    // 3. 还原全局标记
    currentTask = null;
    currentPriorityLevel = previousPriorityLevel;
    isPerformingWork = false;
  }
}

flushWork中调用了workLoop. 队列消费的主要逻辑是在workLoop函数中, 这就是React 工作循环一文中提到的任务调度循环.

// 省略部分无关代码
function workLoop(hasTimeRemaining, initialTime) {
  let currentTime = initialTime; // 保存当前时间, 用于判断任务是否过期
  currentTask = peek(taskQueue); // 获取队列中的第一个任务
  while (currentTask !== null) {
    if (
      currentTask.expirationTime > currentTime &&
      (!hasTimeRemaining || shouldYieldToHost())
    ) {
      // 虽然currentTask没有过期, 但是执行时间超过了限制(毕竟只有5ms, shouldYieldToHost()返回true). 停止继续执行, 让出主线程
      break;
    }
    const callback = currentTask.callback;
    if (typeof callback === 'function') {
      currentTask.callback = null;
      currentPriorityLevel = currentTask.priorityLevel;
      const didUserCallbackTimeout = currentTask.expirationTime <= currentTime;
      // 执行回调
      const continuationCallback = callback(didUserCallbackTimeout);
      currentTime = getCurrentTime();
      // 回调完成, 判断是否还有连续(派生)回调
      if (typeof continuationCallback === 'function') {
        // 产生了连续回调(如fiber树太大, 出现了中断渲染), 保留currentTask
        currentTask.callback = continuationCallback;
      } else {
        // 把currentTask移出队列
        if (currentTask === peek(taskQueue)) {
          pop(taskQueue);
        }
      }
    } else {
      // 如果任务被取消(这时currentTask.callback = null), 将其移出队列
      pop(taskQueue);
    }
    // 更新currentTask
    currentTask = peek(taskQueue);
  }
  if (currentTask !== null) {
    return true; // 如果task队列没有清空, 返回ture. 等待调度中心下一次回调
  } else {
    return false; // task队列已经清空, 返回false.
  }
}

workLoop就是一个大循环, 虽然代码也不多, 但是非常精髓, 在此处实现了时间切片(time slicing)和fiber树的可中断渲染. 这 2 大特性的实现, 都集中于这个while循环.

可中断渲染原理

每一次while循环的退出就是一个时间切片, 深入分析while循环的退出条件:
1.队列被完全清空: 这种情况就是很正常的情况, 没有遇到任何阻碍.
2.执行超时: 在消费taskQueue时, 在执行task.callback之前, 都会检测是否超时。如果某个task.callback执行时间太长(如: fiber树很大, 或逻辑很重)也会造成超时

在时间切片的基础之上, 如果单个task.callback执行时间就很长(假设 200ms). 就需要task.callback自己能够检测是否超时, 所以在 fiber 树构造过程中, 每构造完成一个单元, 都会检测一次超时(源码链接), 如遇超时就退出fiber树构造循环, 并返回一个新的回调函数(就是此处的continuationCallback)并等待下一次回调继续未完成的fiber树构造.

function workLoopConcurrent() {
  // Perform work until Scheduler asks us to yield
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
}

二、双缓存

canvas开发动画时候发现绘制动画时候需要调用ctx.clearRect清除上一帧动画如果当前帧动画计算量比较大导致清除上一帧画面到绘制当前帧画面会有很长时间页面会白屏
什么是双缓存：这种在内存中构建并直接替换的技术
React使用“双缓存”来完成Fiber树的构建与替换——对应着DOM树的创建与更新。
在React中最多会同时存在两棵Fiber树。当前屏幕上显示内容对应的Fiber树称为current Fiber树，正在内存中构建的Fiber树称为workInProgress Fiber树。

function App() {
  const [num, add] = useState(0);
  return (
     add(num + 1)}>{num}
  )
}

ReactDOM.render(, document.getElementById('root'));

mount时

在首次渲染的时候，会创建fiberRoot和rootFiber,fiberRoot是整个应用的根节点,rootFiber是组件的根节点。

接下来进入render阶段，根据组件返回的JSX在内存中依次创建Fiber节点并连接在一起构建Fiber树，被称为workInProgress Fiber树。（下图中右侧为内存中构建的树，左侧为页面显示的树）
在构建workInProgress Fiber树时会尝试复用current Fiber树中已有的Fiber节点内的属性，在首屏渲染时只有rootFiber存在对应的current fiber（即rootFiber.alternate）

目前current只有一个根因此虚拟树复用了根既用alternate连接

渲染完成之后，workInProgress树会赋值给current树

update时

点击p节点触发状态改变，这会开启一次新的render阶段并构建一棵新的workInProgress Fiber 树
更新复用currentFiber的alternate属性（这个决定是否复用的过程就是Diff算法，后面章节会详细讲解）也就是第一次渲染成功的fiber，如果一直没用变化他将一直复用currentFiber的alternate

可以得出双缓存的结论：

currtentFiber.alternate===workInProgress

workInProgress.alternate===currtentFiber

没变化的复用alternate

Reconciler 的工作就是使用 Diff 算法对比 current Fiber 和 React Element ，生成 workInProgress Fiber ，这个阶段是可中断的，Renderer 的工作是把 workInProgress Fiber 转换成真正的 DOM 节点。

三、生命周期的改变

在新的 React 架构中，一个组件的渲染被分为两个阶段：

第一个阶段也就是fiber构建的阶段是可以被 React 打断的，一旦被打断，这阶段所做的所有事情都被废弃，当 React 处理完紧急的事情回来会重新渲染这个组件，这时候第一阶段的工作会重做一遍
第二个阶段叫做 commit 阶段，一旦开始就不能中断，也就是说第二个阶段的工作会直接做到这个组件的渲染结束

两个阶段的分界点，就是 render 函数。render 函数之前的所有生命周期函数（包括 render)都属于第一阶段，之后的都属于第二阶段。开启 Concurrent Mode 之后， render 之前的所有生命周期都有可能会被打断，或者重复调用比如如下生命周期：componentWillMount componentWillReceiveProps componentWillUpdate

如果我们在这些生命中期中引入了副作用，被重复执行，就可能会给我们的程序带来不可预知的问题，所以到了 React v16.3，React 干脆引入了一个新的生命周期函数 getDerivedStateFromProps，这个生命周期是一个静态方法，在里面根本不能通过 this 访问到当前组件，输入只能通过参数，对组件渲染的影响只能通过返回值。

    static getDerivedStateFromProps(nextProps, prevState) {
        if (nextProps.info!== prevState.info) {
            return ({
                info: nextProps.info
            })
        }
        return null;
    }

image.png

四、 React16缺陷

在 expirationTime 最开始被设计的时候，React 体系中还没有 Suspense 异步渲染的概念。假如现在有这样的场景: 有 3 个任务, 其优先级 A > B > C，正常来讲只需要按照优先级顺序执行就可以。
但是现在有这样的情况：A 和 C 任务是 CPU 密集型，而 B 是IO密集型（Suspense 会调用远程 api, 算是 IO 任务），即 A(cpu) > B(IO) > C(cpu)，在这种情况下呢，高优先级 IO 任务会中断低优先级 CPU 任务，这显然，是不合理的看下17版本如何解决

3、React17

1.多版本共存

17版本之前的react 如果存在多版本嵌套如果页面上有多个 React 版本，他们都将在顶层注册事件处理器。这会破坏 e.stopPropagation()：如果嵌套树结构中阻止了事件冒泡，但外部树依然能接收到它。这会使不同版本 React 嵌套变得困难重重

回顾react事件的实现方式

react实现了自己的一套事件机制并绑定到document上也就是自己的合成事件当我们触发一个事件的时候这样可以抹平各个浏览器的兼容性问题

这样就会存在一个问题再写react事件的时候需要绑定this 不然this会丢失其实原因并不怪react 而是js函数和this工作原理导致的事件处理的那个 props——onClick 接收到了函数，却不知道执行上下文

const obj = {
  name: 'obj',
  func() {
    console.log(this)
  }
}

obj.func()  // {name: "obj", func: ƒ}

如果把func提取出来执行，那么func在模块化或严格模式中打印的就是undefined

const func = obj.func;

func();   // undefined

  render() {
    return (
      
    );
  }

this.handleClick 中的 handleClick 被提取出来，放在一个事件池中之后被触发，这个时候，this 早已经不是指向那个组件了

React 17 React 会把事件 attach 到 React 渲染树的根 DOM 容器中

const rootNode = document.getElementById('root'); 
ReactDOM.render(, rootNode);

绑定在根DOM容器上这样就有效将嵌套的React版本隔离开来事件不会相互影响

2.新的优先级算法lanes

但是现在有这样的情况：A 和 C 任务是 CPU 密集型，而 B 是IO密集型（Suspense 会调用远程 api, 算是 IO 任务），即 A(cpu) > B(IO) > C(cpu)，在这种情况下呢，高优先级 IO 任务会中断低优先级 CPU 任务

那么使用 expirationTime ，它是以某一优先级作为整棵树的优先级更新标准，而并不是某一个具体的组件，这时我们的需求是需要把任务B 从一批任务中分离出来，先处理 cpu 任务 A 和 C ，如果通过 expirationTime 很难表示批的概念，也很难从一批任务里抽离单个任务，这时呢，我们就需要一种更细粒度的优先级

Lane类型被定义为二进制变量, 利用了位掩码的特性, 在频繁运算的时候占用内存少, 计算速度快.

越低优先级的 lanes 占用的位越多。比如 InputDiscreteLanes占了2个位，TransitionLanes 占了9个位。原因在于：越低优先级的更新越容易被打断（如果当前优先级的所有赛道都被占有了，则把当前优先级下降一个优先级），导致积压下来，所以需要更多的位。相反，最高优的同步更新的 SyncLane 不需要多余的 lanes。

4、React18 Concurrent Rendering 并发渲染机制

在 React 18 版本中，ReactDOM.createRoot() 替代了通常作为程序入口的 ReactDOM.render() 方法。

这个方法主要是防止 React 18 的不兼容更新导致你的应用程序崩溃

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
const container = document.getElementById('root');
// Create a root.
const root = ReactDOM.createRoot(container);
// Render the top component to the root.
root.render();

批处理的优化

半自动批处理：

在v18之前，只有事件回调、生命周期回调中的更新会批处理，比如上例中的onClick。
而在promise、setTimeout等异步回调中不会批处理

export function batchedUpdates(fn: A => R, a: A): R { 
  const prevExecutionContext = executionContext; 
  executionContext |= BatchedContext; 
  try { 
    return fn(a); 
  } finally { 
    executionContext = prevExecutionContext; 
    // If there were legacy sync updates, flush them at the end of the outer 
    // most batchedUpdates-like method. 
    if (executionContext === NoContext) { 
      resetRenderTimer(); 
      flushSyncCallbacksOnlyInLegacyMode(); 
    } 
  } 
}

可以看到，传入一个回调函数fn，此时会通过「位运算」为代表当前执行上下文状态的变量executionContext增加BatchedContext状态拥有这个状态位代表当前执行上下文需要批处理。
在fn执行过程中，其获取到的全局变量executionContext都会包含BatchedContext 最终fn执行完后，进入try...finally逻辑，将executionContext恢复为之前的上下文。
说白了 batchedUpdates是同步调用的等到执行异步的部分批处理早已执行完，executionContext中已经不包含BatchedContext。此时触发的更新不会走批处理逻辑。

为了弥补「半自动批处理」的不灵活，ReactDOM中导出了unstable_batchedUpdates方法供开发者手动调用。

onClick() { 
  setTimeout(() => { 
    ReactDOM.unstable_batchedUpdates(() => { 
      this.setState({a: 3}); 
      this.setState({a: 4}); 
    }) 
  }) 
}

全自动批处理：

v18实现「自动批处理」的关键在于两点：
1.增加调度的流程
2.不以全局变量executionContext为批处理依据，而是以更新的优先级为依据

举个


  componentDidMount() {
    this.setState({val: this.state.val + 1});
    console.log(this.state.val);   
    this.setState({val: this.state.val + 1});
    console.log(this.state.val);   
    setTimeout(() => {
      this.setState({val: this.state.val + 1});
      console.log(this.state.val);    
      this.setState({val: this.state.val + 1});
      console.log(this.state.val);  
    }, 0);
  }

看下调度流程部分源码

//调度流程
function ensureRootIsScheduled(root, currentTime) { 
 
  // 获取当前所有优先级中最高的优先级 
  var nextLanes = getNextLanes(root, root === workInProgressRoot ? workInProgressRootRenderLanes : NoLanes); 
  // 本次要调度的优先级 
  var newCallbackPriority = getHighestPriorityLane(nextLanes);  
  // 已经存在的调度的优先级 
  var existingCallbackPriority = root.callbackPriority; 
  if (existingCallbackPriority === newCallbackPriority) { 
    return; 
  } 
  // 调度更新流程 
  newCallbackNode = scheduleCallback(schedulerPriorityLevel, performConcurrentWorkOnRoot.bind(null, root)); 
 
  root.callbackPriority = newCallbackPriority; 
  root.callbackNode = newCallbackNode; 
}

节选后的调度流程大体是：
1.获取当前所有优先级中最高的优先级
2.将步骤1的优先级作为本次调度的优先级
3.看是否已经存在一个调度
4.如果已经存在调度，且和当前要调度的优先级一致，则return
5.不一致的话就进入调度流程
可以看到，调度的最终目的是在一定时间后执行performConcurrentWorkOnRoot，正式进入更新流程。

第一次执行完this.setState创造的update数据结构如下：

lane为1

在v18，不同场景下触发的更新拥有不同优先级，如上例子中事件回调中的this.setState会产生同步优先级的更新，这是最高的优先级(lane为1)

第二次执行this.setState创造的update数据结构如下：

lane为16，代表Normal(即一般优先级) 注意⚠️ 此update对象挂载在fiber节点上 `enqueueUpdate(fiber, update);`

第一次调用this.setState，进入「调度流程」后，不存在existingCallbackPriority 所以会执行调度：

第二次调用this.setState，进入「调度流程」后，已经存在existingCallbackPriority，即第一次调用产生的。

此时比较两者优先级：由于两个更新都是在onClick中触发，拥有同样优先级，所以return。
按这个逻辑，即使多次调用this.setState，如：

onClick() { 
  this.setState({a: 1}); 
  this.setState({a: 2}); 
  this.setState({a: 3}); 
}

只有第一次调用会执行调度，后面几次执行由于优先级和第一次一致会return。
当一定时间过后，第一次调度的回调函数performConcurrentWorkOnRoot会执行，进入更新流程。
由于每次执行this.setState都会创建update并挂载在fiber上所以即使只执行一次更新流程，还是能将状态更新到最新

react的setstate和hooks的setstate对比不知道大家平时开发的时候有没有对两者的原理区别产生过好奇

 const updateQueue = fiber.updateQueue;
 if (updateQueue === null) {
   // Only occurs if the fiber has been unmounted.
   return;
 }

 const sharedQueue: SharedQueue = (updateQueue: any).shared;
 const pending = sharedQueue.pending;
 if (pending === null) {
   // This is the first update. Create a circular list.
   update.next = update;
 } else {
   update.next = pending.next;
   pending.next = update;
 }
 sharedQueue.pending = update;
}

hooks的setstate（usestate的第二个方法参数）

function dispatchAction(
  fiber: Fiber,
  queue: UpdateQueue,
  action: A,
) {
  // 1. 创建update对象
  const eventTime = requestEventTime();
  const lane = requestUpdateLane(fiber); // 确定当前update对象的优先级
  const update: Update = {
    lane,
    action,
    eagerReducer: null,
    eagerState: null,
    next: (null: any),
  };
  // 2. 将update对象添加到当前Hook对象的updateQueue队列当中
  const pending = queue.pending;
  if (pending === null) {
    update.next = update;
  } else {
    update.next = pending.next;
    pending.next = update;
  }
  queue.pending = update;
  // 3. 请求调度, 进入reconcier运作流程中的`输入`环节.
  scheduleUpdateOnFiber(fiber, lane, eventTime); // 传入的lane是update优先级
}

可以发现两者的思想确实是一样的都是将所有更新挂在一个链表上只是挂载的地方不一样

startTransition属性：

什么是过度任务？

第一类紧急更新任务。比如一些用户交互行为，按键，点击，输入等。
第二类就是过渡更新任务。比如 UI 从一个视图过渡到另外一个视图。

1.startTransition 依赖于 concurrent Mode 渲染并发模式

传统 legacy 模式

import ReactDOM from 'react-dom'
/* 通过 ReactDOM.render  */
ReactDOM.render(
    ,
    document.getElementById('app')
)

v18 concurrent Mode并发模式

import ReactDOM from 'react-dom'
/* 通过 createRoot 创建 root */
const root =  ReactDOM.createRoot(document.getElementById('app'))
/* 调用 root 的 render 方法 */
root.render()

这种模式诞生的场景是数据量大，DOM 元素节点多的场景，一次更新带来的变化可能是巨大的，所以频繁的更新，执行 js 事务频繁调用，浏览器要执行大量的渲染工作，所以给用户感觉就是卡顿。
举一个很常见的场景：就是有一个 input 表单。并且有一个大量数据的列表，通过表单输入内容，对列表数据进行搜索，过滤。那么在这种情况下，就存在了多个并发的更新任务

2.startTransition的使用

我们希望输入框状态改变更新优先级要大于列表的更新的优先级。这个时候我们的主角就登场了。用 startTransition 把两种更新区别开。

export default function App(){
    const [ value ,setInputValue ] = React.useState('')
    const [ isTransition , setTransion ] = React.useState(false)
    const [ query ,setSearchQuery  ] = React.useState('')
    const handleChange = (e) => {
        /* 高优先级任务 —— 改变搜索条件 */
        setInputValue(e.target.value)
        if(isTransition){ /* transition 模式 */
            React.startTransition(()=>{
                /* 低优先级任务 —— 改变搜索过滤后列表状态  */
                setSearchQuery(e.target.value)
            })
        }else{ /* 不加优化，传统模式 */
            setSearchQuery(e.target.value)
        }
    }
    return 
        
        
       
    
}

可以看到input里面更新的无比慢严重卡顿

看下使用startTranstion后的效果

使用startTranstion后将渲染列表放置低优先级这样就优先渲染input里面的更新了

3.为什么不用setTimeout

startTransition 的处理逻辑和 setTimeout 有一个很重要的区别，setTimeout 是异步延时执行，而 startTransition 的回调函数是同步执行的。在 startTransition 之中任何更新，都会标记上 transition，React 将在更新的时候，判断这个标记来决定是否完成此次更新所以 Transition 可以理解成比 setTimeout 更早的更新
对于渲染并发的场景下，setTimeout 仍然会使页面卡顿。因为超时后，还会执行 setTimeout 的任务，它们与用户交互同样属于宏任务，所以仍然会阻止页面的交互。那么 transition 就不同了，在 conCurrent mode 下，startTransition 是可以中断渲染的，所以它不会让页面卡顿，React 让这些任务，在浏览器空闲时间执行，所以上述输入 input 内容时，startTransition 会优先处理 input 值的更新，之后才是列表的渲染

4.实现原理

同步可中断的 setTimeout是宏任务晚于startTransition执行这样的方法执行是脱离了事务的，react 管控不到，所以就没法 batch 了。

// 源码实现
import ReactCurrentBatchConfig from './ReactCurrentBatchConfig';

export function startTransition(scope: () => void) {
 const prevTransition = ReactCurrentBatchConfig.transition;
 ReactCurrentBatchConfig.transition = 1;
 try {
   scope();
 } finally {
   ReactCurrentBatchConfig.transition = prevTransition;
 }
}

和batchedUpdates源码很类似设置开关的方式开关就是transition = 1 代表这是一个低优先级的过渡更新

useTranstion过度属性

上面介绍了 startTransition ，又讲到了过渡任务，本质上过渡任务有一个过渡期，在这个期间当前任务本质上是被中断的，那么在过渡期间，应该如何处理呢，或者说告诉用户什么时候过渡任务处于 pending 状态，什么时候 pending 状态完毕。

import  {  useTransition  }  from  'react' ; 
const  [ isPending ,  startTransition ]  =  useTransition ( ) ;

第一个是，当处于过渡状态的标志——isPending。
第二个是一个方法，可以理解为上述的 startTransition。可以把里面的更新任务变成过渡任务。
源码其实也就是实现了一个自定义hook

使用

可以看到能够准确捕获到过渡期间的状态

实现原理

function mountTransition(): [(() => void) => void, boolean] {
  const [isPending, setPending] = mountState(false);

  const start = startTransition.bind(null, setPending);
  mountRef(start);
  return [start, isPending];
}

function startTransition(setPending, callback) {
  const priorityLevel = getCurrentPriorityLevel();
  if (decoupleUpdatePriorityFromScheduler) {
    const previousLanePriority = getCurrentUpdateLanePriority();
    ...
    runWithPriority(
      priorityLevel < UserBlockingPriority
        ? UserBlockingPriority
        : priorityLevel,
      () => {
        setPending(true);
      },
    );


    setCurrentUpdateLanePriority(DefaultLanePriority);

    runWithPriority(
      priorityLevel > NormalPriority ? NormalPriority : priorityLevel,
      () => {
        const prevTransition = ReactCurrentBatchConfig.transition;
        ReactCurrentBatchConfig.transition = 1;
        try {
          setPending(false);
          callback();
        } finally {
          if (decoupleUpdatePriorityFromScheduler) {
            setCurrentUpdateLanePriority(previousLanePriority);
          }
          ReactCurrentBatchConfig.transition = prevTransition;
        }
      },
    );
  } 
...
}

从上面可以看到，useTranstion 本质上就是 useState + startTransition 。
通过 useState 来改变 pending 状态。在 mountTransition 执行过程中，会触发两次 setPending ，一次在 transition = 1 之前，一次在之后。一次会正常更新 setPending(true) ，一次会作为 transition 过渡任务更新 setPending(false); ，所以能够精准捕获到过渡时间。

Vue 的整体 diff 策略与 React 对齐，虽然缺乏时间切片能力，但这并不意味着 Vue 的性能更差，因为在 Vue 3 初期引入过，后期因为收益不高移除掉了。除了高帧率动画，在 Vue 中其他的场景几乎都可以使用防抖和节流去提高响应性能。