一文读懂React组件渲染核心原理

引言

相信大家对 React 都已经非常熟悉了，像 React，Vue 这样的现代前端框架已经是我们日常开发离不开的工具了，这篇文章主要是从源码的角度剖析 React 的核心渲染原理。我们将从用户编写的组件代码开始，一步一步分析 React 是如何将它们变成真实 DOM ，这个过程主要可以分成两个阶段：render 阶段和 commit 阶段。文章的核心内容也正是对这两个阶段的分析。

专业从事成都网站制作、网站设计、外贸网站建设,高端网站制作设计,小程序开发,网站推广的成都做网站的公司。优秀技术团队竭力真诚服务，采用HTML5+CSS3前端渲染技术，自适应网站建设，让网站在手机、平板、PC、微信下都能呈现。建站过程建立专项小组，与您实时在线互动，随时提供解决方案，畅聊想法和感受。

一、前置知识

声明式渲染

『声明式渲染』，顾名思义，就是让使用者只需要「声明或描述」我需要渲染的东西是什么，然后就把具体的渲染工作交给机器去做，与之相对的是『命令式渲染』。

『命令式渲染』则是由用户去一步一步地命令机器下一步该怎么做。

举个简单的例子：

如果我们需要在网页上渲染一个有三个节点的列表，命令式的做法是手动操作 dom，首先创建一个容器节点，再利用循环每次先创建一个新节点，填充内容，然后将新节点新增到容器节点下，最后再将容器节点新增到 body 标签下：

 
 
 
 
  
  
  
  const list = [1,2,3];
  
  
  
  const container = document.createElement('div');
  
  
  
  for (let i = 0; i < list.length; i ++) {
  
  
  
      const newDom = document.createElement('div');
  
  
  
      newDom.innerHTML = list[i];
  
  
  
      container.appendChild(newDom);
  
  
  
  }
  
  
  
  document.body.appendChild(container);

而声明式的做法应该是：

 
 
 
 
  
  
  
  const list = [1,2,3];
  
  
  
  const container = document.createElement('div');
  
  
  
  
  
  
  
  const Demo = () =>
  
  
  
  (
  
  
  
      {list.map((item) => {item}
)}

)

ReactDom.render(, container);

可以看到在这个例子中，声明式写法以 HTML 语法直接告诉机器，我需要的视图应该是长这个样子，然后具体的 DOM 操作全部交由机器去完成。开发者只需要专注于业务逻辑的实现。

这便是声明式渲染。

声明式渲染是现代前端框架的比较普遍的设计思路。

JSX 和 ReactElement

相信大家最初学 React 的时候都有这样的疑问，为什么我们能够以类似 HTML 的语法编写组件，这个东西又是怎么转换成 JavaScript 语法的?答案就是 Babel。根据官网介绍，这种语法被称为 JSX，是一个 JavaScript 的语法扩展。能够被 Babel 编译成 React.createElement 方法。举个例子：

通过查阅源码我们可以看到「React.createElement」方法。

 
 
 
 
  
  
  
  export function createElement(type, config, children) {
  
  
  
    let propName;
  
  
  
  
  
  
  
    // Reserved names are extracted
  
  
  
    const props = {};
  
  
  
  
  
  
  
    let key = null;
  
  
  
    let ref = null;
  
  
  
    let self = null;
  
  
  
    let source = null;
  
  
  
    ...
  
  
  
    return ReactElement(
  
  
  
      type,
  
  
  
      key,
  
  
  
      ref,
  
  
  
      self,
  
  
  
      source,
  
  
  
      ReactCurrentOwner.current,
  
  
  
      props,
  
  
  
    );
  
  
  
  }
  
  
  
  
  
  
  
  const ReactElement = function(type, key, ref, self, source, owner, props) {
  
  
  
    const element = {
  
  
  
      // This tag allows us to uniquely identify this as a React Element
  
  
  
      $typeof: REACT_ELEMENT_TYPE,
  
  
  
  
  
  
  
      // Built-in properties that belong on the element
  
  
  
      type: type,
  
  
  
      key: key,
  
  
  
      ref: ref,
  
  
  
      props: props,
  
  
  
  
  
  
  
      // Record the component responsible for creating this element.
  
  
  
      _owner: owner,
  
  
  
    };
  
  
  
    ...
  
  
  
    return element;
  
  
  
  }

可以看到 React 是使用了 element 这种结构来代表一个节点，里面就只有简单的 6 个字段。我们可以看个实际的例子，下面 Count 组件对应的 element 数据结构：

 
 
 
 
  
  
  
  function Count({count, onCountClick}) {
  
  
  
    return  { onCountClick()}}>
  
  
  
    count: {count}

}

可以看到，element 结构只能反映出 jsx 节点的层级结构，而组件里的各种状态或者返回 jsx 等都是不会记录在 element 中。

目前我们知道，我们编写的 jsx 会首先被处理成 element 结构。

jsx -> element

那 React 又是如何处理 element 的，如刚刚说的，element 里包含的信息太少，只靠 element 显然是不足以映射到所有真实 DOM 的，因此我们还需要更精细的结构。

Fiber 树结构

Fiber 这个单词相信大家多多少少都有听过，它是在 React 16 被引入，关于 Fiber 如何实现任务调度在这篇文章不会涉及，但是 Fiber 的引入不仅仅带来了任务调度方面的能力，整个 React 实现架构也因此重构了一遍，而我们之前经常提到的虚拟 DOM 树在新的 React 架构下被称为 Fiber 树，上面提到的每个 element 都有一个所属的 Fiber。

首先我们先看看源码中 Fiber 的构造函数：

 
 
 
 
  
  
  
  function FiberNode(
  
  
  
    tag: WorkTag,
  
  
  
    pendingProps: mixed,
  
  
  
    key: null | string,
  
  
  
    mode: TypeOfMode,
  
  
  
  ) {
  
  
  
    // Instance
  
  
  
    this.tag = tag;            // 标识节点类型，例如函数组件、类组件、普通标签等
  
  
  
    this.key = key;
  
  
  
    this.elementType = null;  // 标识具体 jsx 标签名
  
  
  
    this.type = null;        // 类似 elementType
  
  
  
    this.stateNode = null;  // 对应的真实 DOM 节点
  
  
  
  
  
  
  
    // Fiber
  
  
  
    this.return = null;    // 父节点
  
  
  
    this.child = null;     // 第一个子节点
  
  
  
    this.sibling = null;   // 第一个兄弟节点
  
  
  
    this.index = 0;
  
  
  
  
  
  
  
    this.ref = null;
  
  
  
  
  
  
  
    this.pendingProps = pendingProps;  // 传入的 props
  
  
  
    this.memoizedProps = null;    
  
  
  
    this.updateQueue = null;   // 状态更新相关
  
  
  
    this.memoizedState = null;
  
  
  
    this.dependencies = null;
  
  
  
  
  
  
  
    this.mode = mode;
  
  
  
  
  
  
  
    // Effects
  
  
  
    this.flags = NoFlags;
  
  
  
    this.subtreeFlags = NoFlags;
  
  
  
    this.deletions = null;
  
  
  
  
  
  
  
    this.lanes = NoLanes;
  
  
  
    this.childLanes = NoLanes;
  
  
  
  
  
  
  
    this.alternate = null;
  
  
  
    ...
  
  
  
  }

可以看到 Fiber 节点中的属性很多，其中不仅仅包含了 element 相关的实例信息，还包含了组成 Fiber 树所需的一些“指针”，组件内部的状态(memorizedState)，用于操作真实 DOM 的副作用(effects)等等。

我们以上面的 Count 组件为例看一下它对应的 Fiber 结构：

这里我们先主要介绍一下与形成 Fiber 树相关的三个属性：child, sibling 和 return。他们分别指向 Fiber 的第一个子 Fiber，下一个兄弟 Fiber 和父 Fiber。

以下面的 jsx 代码为例：

总结一下，我们编写的 jsx 首先会形成 element ，然后在 render 过程中每个 element 都会生成对应的 Fiber，最终形成 Fiber 树。

下面我们正式介绍一下 render 的过程，看看 Fiber 是如何生成并形成 Fiber 树的。

二、渲染(render)过程

核心流程

通常 React 运行时会有两个 Fiber 树，一个是根据当前最新组件状态构建出来的，另一个则是上一次构建出来的 Fiber 树，当然如果是首次渲染就没有上一次的 Fiber 树，这时就只有一个了。简单来说，render 过程就是 React 「对比旧 Fiber 树和新的 element」然后「为新的 element 生成新 Fiber 树」的一个过程。

从源码中看，React 的整个核心流程开始于「performSyncWorkOnRoot」函数，在这个函数里会先后调用「renderRootSync」函数和「commitRoot」函数，它们两个就是分别就是我们上面提到的 render 和 commit 过程。来看 renderRootSync 函数，在「renderRootSync」函数里会先调用「prepareFreshStack」，从函数名字我们不难猜出它主要就是为接下来的工作做前置准备，初始化一些变量例如 workInProgress(当前正在处理的 Fiber 节点) 等，接着会调用「workLoopSync」函数。(这里仅讨论传统模式，concurrent 模式留给 Fiber 任务调度分享)，而在「workLoopSync」完成之后，「renderRootSync」也基本上完成了，接下来就会调用 commitRoot 进入 commit 阶段。

因此整个 render 过程的重点在「workLoopSync」中，从「workLoopSync」简单的函数定义里我们可以看到，这里用了一个循环来不断调用「performUnitOfWork」方法，直到 workInProgress 为 null。

而「performUnitOfWork」函数做的事情也很简单，简单来说就是为传进来的 workInProgress 生成下一个 Fiber 节点然后赋值给 workInProgress。通过不断的循环调用「performUnitOfWork」，直到把所有的 Fiber 都生成出来并连接成 Fiber 树为止。

现在我们来看「performUnitOfWork」具体是如何生成 Fiber 节点的。

前面介绍 Fiber 结构的时候说过，Fiber 是 React 16 引入用于任务调度提升用户体验的，而在此之前，render 过程是递归实现的，显然递归是没有办法中断的，因此 React 需要使用循环来模拟递归过程。

「performUnitOfWork」正是使用了「beginWork」和「completeUnitOfWork」来分别模拟这个“递”和“归”的过程。

render 过程是深度优先的遍历，「beginWork」函数则会为遍历到的每个 Fiber 节点生成他的所有子 Fiber 并返回第一个子 Fiber ，这个子 Fiber 将赋值给 workInProgress，在下一轮循环继续处理，直到遍历到叶子节点，这时候就需要“归”了。

「completeUnitOfWork」就会为叶子节点做一些处理，然后把叶子节点的兄弟节点赋值给 workInProgress 继续“递”操作，如果连兄弟节点也没有的话，就会往上处理父节点。

同样以上面的 Fiber 树例子来看，其中的 Fiber 节点处理顺序应该如下：

beginWork

在介绍概览的时候说过，React 通常会同时存在两个 Fiber 树，一个是当前视图对应的，一个则是根据最新状态正在构建中的。这两棵树的节点一一对应，我们用 current 来代表前者，我们不难发现，当首次渲染的时候，current 必然指向 null。实际上在代码中也确实都是通过这个来判断当前是首次渲染还是更新。

开发过程中我们常常希望利用 React 非首次渲染的优化策略来提升性能，如下代码，B 组件是个纯展示组件且内部没有依赖任何 Demo 组件的数据，因此有些同学可能会想当然认为当 Demo 重新渲染时这个 B 组件是符合 React 优化条件的。但结果是，每次 Demo 重新渲染都会导致 B 组件重新渲染。每次渲染时 B 组件的 props 看似没发生变化，但由于 Demo 重新执行后会生成全新的 B 组件(下面会介绍)，所以新旧 B 组件的 props 肯定也是不同的。

那有什么办法可以保持住 B 组件不变吗，答案是肯定的，我们可以把 B 组件放到 Demo 组件外层，这样一来，B 组件是在 App 组件中生成并作为 props 传入 Demo 的，因为不管 Demo 组件状态怎么变化都不会影响到 App 组件，因此 App 和 B 组件就只会在首次渲染时会执行一遍，也就是说 Demo 获取到的 props.children 的引用一直都是指向同一个对象，这样一来 B 组件的 props 也就不会变化了。

通过上面的解析我们知道，当不走优化逻辑时「beginWork」使用大量的 switch...case 来分别处理不同类型的组件，下来我们以我们熟悉的 Function Component 为例。

「核心就是通过调用函数组件，得到组件的返回的 element。」

类似地，对于类组件，则是调用组件实例的 render 方法得到 element。

得到组件返回的 element(s) 之后，下一步就是为他们生成 Fiber，我们查看源码可以看到，不论是函数组件或是类组件或是普通组件，最后返回的 element(s) 都会作为参数传入到「reconcileChildren」中。

介绍「reconcileChildren」之前我们先用一张图总结一下「beginWork」的大致流程：

经过上一步得到 workInProgress 的 children 之后，接下来需要为这些 children element 生成 Fiber ，这就是「reconcileChildFibers」函数做的事情，这也是我们经常提到的 diff 的过程。

这个函数里主要分两种情况处理，如果是 newChild(即 children element)是 object 类型，则进入单节点 diff 过程(「reconcileSingleElement」)，如果是数组类型，则进入多节点 diff 过程(「reconcileChildrenArray」)。

本着尽可能复用旧节点的原则，在单节点 diff 在这里，我们会遍历旧节点，对每个遍历到的节点会做一下两个判断：

从源码我们可以看到，在「reconcileChildrenArray」中，出现了两个循环。

可以看到第一轮循环只要碰到新旧的 key 不一样时就会跳出循环，换句话说，第一轮循环里做的事情都是基于 key 相同，主要就是「更新」的工作。

在执行第二轮循环之前，先把剩下的旧节点和他们对应的 key 或者 index 做成映射，方便查找。

第二轮循环沿用了第一轮循环的 newIdx 变量，说明第二轮循环是在第一轮循环结束的地方开始再次遍历剩下的 newChildren。

第二轮循环主要调用了「updateFromMap」来处理节点，在这里需要用 newChild 的 key 去 existingChildren 中找对应的 Fiber。

不管是复用还是新增，「updateFromMap」都会返回一个 newFiber，然后我们需要为这个 newFiber 更新一下它的位置(index)，但是仅仅更新这个 Fiber 的 index 还不够，因为这个 Fiber 有可能是复用的，如果是复用的就意味着它已经有对应的真实 DOM 节点了，我们还需要复用它的真实 DOM，因此需要对应更新这个 Fiber 的 flag，但是真的需要对每个 Fiber 都去设置 flag 吗，我们举个例子：

如果按照我们刚刚说的做法，这里的 a, b, c 都会被打上 flag，这样一来，在 commit 阶段，这三个 DOM 都会被移动，可是我们知道，这里显然只需要移动一个节点即可，退一万步说我们移动两个节点也比移动所有节点要来的聪明。

其实在这个问题上主要就是我们得区分一下到底哪个节点才是移动了的，这就需要一个参照点，我们要保证在参照点左边都是已经排好顺序了的。而这个参照点就是 lastPlacedIndex。有了它，我们在遍历 newChildren 的时候可能会出现下面两种情况：

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联