精读《Scheduling in React》

LeexMuller 发布于2019-08-23 16:56 / 766人阅读

摘要：调度系统，支持不同渲染优先级，对进行调度。调度带来的限制调度系统也存在两个问题。调度系统能力有限，只能在浏览器提供的能力范围内进行调度，而无法影响比如的渲染回收周期。精读关于调度系统的剖析，可以读深入剖析这篇文章，感谢我们团队的淡苍提供。

1. 引言

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

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

2. 概述

文章从 Dan 在 JSConf 提到的 Demo 说起：

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

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

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

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

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

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

长时间运行的任务造成页面卡顿，我们需要保证所有任务能在几毫秒内完成，这样才能保证页面的流畅。

不同任务优先级不同，比如响应用户输入的任务优先级就高于动画。这个很好理解。

React 调度机制

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

Concurrent： 将同步的渲染变成可拆解为多步的异步渲染，这样可以将超过 16ms 的渲染代码分几次执行。

Scheduler： 调度系统，支持不同渲染优先级，对 Concurrent 进行调度。当然，调度系统对低优先级任务会不断提高优先级，所以不会出现低优先级任务总得不到执行的情况。

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

Concurrent 的正式 API 会在 2019 Q2 发布，现在可以通过 API 方式调用：

ReactDOM.render(
  
    
  ,
  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 ;
}

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

如果 props.onChange(value) 可以在 16ms 内执行完，则与不使用 unstable_next 没有区别。

如果 props.onChange(value) 的执行时间过长，可能这个函数会在下次几次的 Render 中陆续执行，不会阻塞后续的高优先级任务。

调度带来的限制

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

调度系统只能有一个，如果同时存在两个调度系统，就无法保证调度正确性。

调度系统能力有限，只能在浏览器提供的能力范围内进行调度，而无法影响比如 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 模式编写组件是很重要的，因为：

Class Component 的生命周期概念阻碍了 React 调度系统对任务的拆分。

调度系统可能对 componentWillMount 重复调用，使得 Class Component 模式下很容易写出错误的代码。

Function Component 遵循了更严格的副作用分离，这使得 Concurrent 执行过程不会引发意外效果。

React.lazy

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

import OtherComponent from "./OtherComponent";

function MyComponent() {
  return (
    
      
    
  );
}

但如果使用了 import() 动态载入，可以使用 React.lazy 让动态引入的组件像普通组件一样被使用：

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

function MyComponent() {
  return (
    
      
    
  );
}

如果要加入 Loading，就可以配合 Suspense 一起使用：

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

function MyComponent() {
  return (
    Loading...

}> ); }

和 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, );

再提交队列，拿到当前队列的执行 id，通过这个 id 可以判断队列何时执行完毕。

myQueue.cancelTask(taskId);

必要的时候可以取消某个函数的执行。

4. 总结

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

笔者希望大家一起思考，这三种 API 会给前端开发带来什么样的改变？欢迎留言！

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

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

关注 前端精读微信公众号

GPU云服务器云服务器 Scheduling react _React React 源码

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/103529.html

精读《React 的多态性》

摘要：引言本周精读的文章是，看看作者是如何解释这个多态性含义的。读完文章才发现，文章标题改为的多态性更妥当，因为整篇文章都在说，而使用场景不局限于。更多讨论讨论地址是精读的多态性如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。 1 引言本周精读的文章是：surprising-polymorphism-in-react-applications，看看作者是如何解释这个多态性含...

tabalt 2019-08-22 18:27 评论0 收藏0
精读《Caches API》

摘要：引言这个是针对的。一般结合使用，因为请求级别的缓存与具有页面拦截功能的最配。本周精读的文章是，介绍了浏览器缓存接口的基本语法。包含任意命名空间，可以通过创建或访问。精读笔者利用实现了纯浏览器端的后端渲染。前端精读帮你筛选靠谱的内容。 1 引言 caches 这个 API 是针对 Request Response 的。caches 一般结合 Service Worker 使用，因为请求级...

Null 2019-08-23 14:42 评论0 收藏0
精读《Vue3.0 Function API》

摘要：拿到的都是而不是原始值，且这个值会动态变化。精读对于的与，笔者做一些对比。因此采取了作为优化方案只有当第二个依赖参数变化时才返回新引用。不需要使用等进行性能优化，所有性能优化都是自动的。前端精读帮你筛选靠谱的内容。 1. 引言 Vue 3.0 的发布引起了轩然大波，让我们解读下它的 function api RFC 详细了解一下 Vue 团队是怎么想的吧！首先官方回答了几个最受关注的...

voyagelab 2019-08-23 18:24 评论0 收藏0
精读《react-easy-state 源码》

摘要：会自动触发函数内回调函数的执行。因此利用并将依赖置为使代码在所有渲染周期内，只在初始化执行一次。同时代码里还对等公共方法进行了包装，让这些回调函数中自带效果。前端精读帮你筛选靠谱的内容。 1. 引言 react-easy-state 是个比较有趣的库，利用 Proxy 创建了一个非常易用的全局数据流管理方式。 import React from react; import { stor...

curlyCheng 2019-08-23 16:48 评论0 收藏0
精读《Function VS Class 组件》

摘要：未来可能成为官方之一。讨论地址是精读组件如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。前端精读帮你筛选靠谱的内容。 1. 引言为什么要了解 Function 写法的组件呢？因为它正在变得越来越重要。那么 React 中 Function Component 与 Class Component 有何不同？ how-are-function-components-di...

FWHeart 2019-08-26 13:38 评论0 收藏0