精读《Scheduling in React》

1. 引言

此次介绍的文章是 scheduling-in-react，简单来讲就是 React 的调度系统，为了获得更顺滑的用户体验。

毕竟前端作到最后，都是体验优化，前端带给用户的价值核心就在于此。

2. 概述

文章从 Dan 在 JSConf 提到的 Demo 提及：

这是一个测试性能的 Demo，随着输入框字符的增长，下方图表展现的数据量会急速提高。在 Synchronous 与 Debounced 模式下的效果都不尽如人意，只有 Concurrent 模式下看起来是顺畅的。

那么为何普通的 Demo 会很卡呢？

这就涉及到浏览器 Event Loop 规则了。

JS 是单线程的，浏览器同一时间只能作一件事情，而肉眼能识别的刷新频率在 60FPS 左右，这意味着咱们须要在 16ms 以内完成 Demo 中的三件事：响应用户输入，作动画，Dom 渲染。

然而目前几乎全部框架都使用同步渲染模式，这意味着若是一个渲染函数执行时间超过了 16ms，则不可避免的发生卡顿。

总结一下有两个主要问题：

1. 长时间运行的任务形成页面卡顿，咱们须要保证全部任务能在几毫秒内完成，这样才能保证页面的流畅。
2. 不一样任务优先级不一样，好比响应用户输入的任务优先级就高于动画。这个很好理解。

React 调度机制

为了解决这个问题，React16 经过 Concurrent（并行渲染） 与 Scheduler（调度）两个角度解决问题：

• Concurrent： 将同步的渲染变成可拆解为多步的异步渲染，这样能够将超过 16ms 的渲染代码分几回执行。
• Scheduler： 调度系统，支持不一样渲染优先级，对 Concurrent 进行调度。固然，调度系统对低优先级任务会不断提升优先级，因此不会出现低优先级任务总得不到执行的状况。

为了保证不产生阻塞的感受，调度系统会将全部待执行的回调函数存在一份清单中，在每次浏览器渲染时间分片间尽量的执行，并将没有执行完的内容 Hold 住留到下个分片处理。

Concurrent 的正式 API 会在 2019 Q2 发布，如今能够经过 <React.unstable_ConcurrentMode> API 方式调用：

ReactDOM.render(
  <React.unstable_ConcurrentMode>
    <App />
  </React.unstable_ConcurrentMode>,
  rootElement
);

只申明这个是不够的，由于咱们尚未申明各函数执行的优先级。咱们能够经过 npm i scheduler 包来申明函数的优先级：

import { unstable_next } from "scheduler";

function SearchBox(props) {
  const [inputValue, setInputValue] = React.useState();

  function handleChange(event) {
    const value = event.target.value;

    setInputValue(value);
    unstable_next(function() {
      props.onChange(value);
      sendAnalyticsNotification(value);
    });
  }

  return <input type="text" value={inputValue} onChange={handleChange} />;
}

在 unstable_next() 做用域下的代码优先级是 Normal，那么产生的效果是：

1. 若是 props.onChange(value) 能够在 16ms 内执行完，则与不使用 unstable_next 没有区别。
2. 若是 props.onChange(value) 的执行时间过长，可能这个函数会在下次几回的 Render 中陆续执行，不会阻塞后续的高优先级任务。

调度带来的限制

调度系统也存在两个问题。

1. 调度系统只能有一个，若是同时存在两个调度系统，就没法保证调度正确性。
2. 调度系统能力有限，只能在浏览器提供的能力范围内进行调度，而没法影响好比 Html 的渲染、回收周期。

为了解决这个问题，Chrome 正在与 React、Polymer、Ember、Google Maps、Web Standars Community 共同建立一个 浏览器调度规范，提供浏览器级别 API，可让调度控制更底层的渲染时机，也保证调度器的惟一性。

3. 精读

关于 React 调度系统的剖析，能够读 深刻剖析 React Concurrent 这篇文章，感谢咱们团队的 淡苍 提供。

简单来讲，一次 Render 通常涉及到许多子节点，而 Fiber 架构在 Render 阶段能够暂停，一个一个节点的执行，从而实现了调度的能力。

React 调度能力的限制

这意味着，若是你的 React 应用目前是流畅的，开启 Concurrent 并不会对你的应用带来性能体验上的提高，若是你的 React 应用目前是卡顿的，或者在某些场景下是卡顿的，那么 Concurrent 或许能够挽救你一下，带来一些改变。

正如《深刻剖析 React Concurrent》一文提到的，若是你的应用没有性能问题，就不要期望 React 调度能力有所帮助了。

这也是在说，若是一段代码逻辑不存在性能问题，就不须要使用 Concurrent 优化，由于这种优化是无效的。咱们须要能分辨哪些逻辑须要优化，哪些逻辑不要。

从如今开始尝试 Function Component

为了配合 React Schedule 的实现，学会使用 Function Component 模式编写组件是很重要的，由于：

1. Class Component 的生命周期概念阻碍了 React 调度系统对任务的拆分。
2. 调度系统可能对 componentWillMount 重复调用，使得 Class Component 模式下很容易写出错误的代码。
3. Function Component 遵循了更严格的反作用分离，这使得 Concurrent 执行过程不会引起意外效果。

React.lazy

与 Concurrent 一块儿发布的，还有 React 组件动态 import 与载入方案。正常的组件载入是这样的：

import OtherComponent from "./OtherComponent";

function MyComponent() {
  return (
    <div>
      <OtherComponent />
    </div>
  );
}

但若是使用了 import() 动态载入，可使用 React.lazy 让动态引入的组件像普通组件同样被使用：

const OtherComponent = React.lazy(() => import("./OtherComponent"));

function MyComponent() {
  return (
    <div>
      <OtherComponent />
    </div>
  );
}

若是要加入 Loading，就能够配合 Suspense 一块儿使用：

import React, { lazy, Suspense } from "react";
const OtherComponent = lazy(() => import("./OtherComponent"));

function MyComponent() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <OtherComponent />
    </Suspense>
  );
}

和 Concurrent 相似，React.lazy 方案也是一种对性能有益的组件加载方案。

调度分类

调度分 4 个等级：

• Immediate：当即执行，最高优先级。
• render-blocking：会阻塞渲染的优先级，优先级相似 requestAnimationFrame。若是这种优先级任务不能被执行，就可能致使 UI 渲染被 block。
• default：默认优先级，普通的优先级。优先级能够理解为 setTimeout(0) 的优先级。
• idle：好比通知等任务，用户看不到或者不在乎的。

目前建议的 API 相似以下：

function mytask() {
  ...
}

myQueue = TaskQueue.default("render-blocking")

先建立一个执行队列，并设置队列的优先级。

taskId = myQueue.postTask(myTask, <list of args>);

再提交队列，拿到当前队列的执行 id，经过这个 id 能够判断队列什么时候执行完毕。

myQueue.cancelTask(taskId);

必要的时候能够取消某个函数的执行。

4. 总结

随着 Hooks 的发布，即将到来的 Concurrent 与 Suspense 你是否准备好了呢？

笔者但愿你们一块儿思考，这三种 API 会给前端开发带来什么样的改变？欢迎留言！

讨论地址是：精读《Scheduling in React》 · Issue #146 · dt-fe/weekly

若是你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

special Sponsors

• DevOps 全流程平台

版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）