# React Reconciler - Fiber 创建 > React 从 16 开始，对底层架构做了一次重构，和 15 不同，渲染 vdom 的时候一改以往的递归执行，引入了一个新的概念，叫做 Fiber，虽然最后渲染到页面的时候还是递归，但是 Fiber 的递归是可以中断的，根据优先级由浏览器优先执行任务，保证在大量视图需要更新的时候，浏览器仍然能保证快速的响应 在 React 中，视图的更新使用了双缓存的方式，也就是说在 React 运行时，同时有着两棵 Fiber 树，一颗是当前视图上的 Fiber 树，叫 current，另外一棵是存在内存当中的下一次视图更新时用的叫做 workInProgress，React 在构建时会创建整个 app 唯一的根 Fiber 节点，叫做 FiberRootNode，这个节点上有一个 current 指针，指向的是当前正在页面上显示的 Fiber 树也就是 current，当 workInProgress 递归生成完毕，指针会立即指向 workInProgress ，而旧的 current 就会在下一次渲染中变成 workInProgress ，就这样循环交替完成页面的递归渲染 ## 首屏渲染 ### createWorkInProgress React 的首屏渲染时会交由 createWorkInProgress 函数生成一个 WorkInProgress Fiber 节点，这个节点就是 FiberNode，createWorkInProgress 接收两个参数，分别是 current 和 pendingProps，这里的 pendingProps 是组件的属性 因为传入的是 current Fiber 树，所以 createWorkInProgress 内会从 current 的 alternate 取出中取出与之链接的 WorkInProgress Fiber 节点，并对其做空值判断，因为对于首屏渲染而言，WorkInProgress 是不存在的，所以会走到不存在 WorkInProgress 的逻辑，在这里也就是调用 createFiber 函数，这个函数会更加传递的参数 new 一个 Fiber 的实例，其内部并没有什么复杂的逻辑，而是对 Fiber 节点的属性进行了初始化，createFiber 返回之后，会对返回的 FiberNode 节点进行赋值，复用 current FiberNode 节点的内容，并对它们各自的 alternate 进行赋值，双向链接 createWorkInProgress 之后，Fiber 的操作就会交由 beginWork 和 completeWork 开始正式的递归 ### beginWork > beginWork 执行在递归节点的 Fiber 创建之前，主要是为传入的 Fiber 节点根据类型创建第一个子 Fiber 节点 首先会对 current 做空值判断，因为对于首屏渲染而言，当前传入的 current Fiber 节点是 FiberNode，所以是存在的，会进入 current !== null 的逻辑，然后会判断当前 Fiber 节点是否发生变化，然后赋值 didReceiveUpdate 做更新标识，判断的条件如下： 1. 新旧 props 是否相同 2. Context 是否发生变化 3. Fiber 节点 type 是否发生变化 在本次首屏渲染中，以上的条件都为否，会进入后续条件判断，在后续的条件判断中主要是为了应付一些特殊的场景，例如错误边界和 legacy 模式，具体可以看到官方留下的代码注释，在我们现在的场景下，最终会走到 didReceiveUpdate 为 false 的情况下，也就是当前 Fiber 并没有变化，因为在之前的 createWorkInProgress 中 WorkFiberProgress 被赋值上了 current Fiber 的同名属性，所以它们会是相同的两个 FIber 节点，在这里的代码可以看到：beginWork 中还有对优先值 lanes 的一些处理，在这里先不展开，后续再补充 最后会走入 switch 环节，这了主要根据传入的 WorkInProgress Fiber 节点的类型进入不同的处理逻辑，这也是 beginWork 最主要的任务：为当前 WorkInProgress Fiber 节点创建它的第一个 Fiber 子节点，其内部根据 Fiber 的 tag 不同有对应的： - updateClassComponent 处理 Class Component - updateHostComponent 处理 Host Component - updateSuspenseComponent 处理 Suspense Component 本次的是首屏渲染，传入的 WorkInProgress Fiber 为 FiberNode，所以会进入 HostRoot 的 case，执行 updateHostRoot 方法 ### updateHostRoot updateHostRoot 函数中首先会执行 pushHostRootContext 方法，这个方法和 Context 相关，现在暂且不谈 在 updateHostRoot 逻辑一开始，它会将 current 和 WorkInProgress 传递给 cloneUpdateQueue 这个函数，这个函数会将 Fiber 中的 queue 属性进行 clone，除非它们已经是 clone 之后的属性，那么具体是怎么做的判断是否是 clone 过的属性呢？其实很简单，它只是使用了 === 三个等于判断属性的引用是否相同，也就是说这个函数实际上做的是清除引用，保证在之后对 WorkInProgress 的操作不会影响到 current Fiber 树，判断两个 Fiber 树的 updateQueue 属性的引用完全相同，那么就会创建一个新的对象并重复赋值达到清除应用的目的，最后赋值给 WorkInProgress Fiber 节点 之后，再把 WorkInProgress Fiber 节点交给 processUpdateQueue 函数，这个函数主要是处理更新队列，在这里先不展开，TODO 再往后是一些针对服务端渲染的一些处理逻辑，服务端渲染也不是这次讨论的目的，也先跳过 最终调用 reconcileChildren 为 FIber 创建一个子 Fiber 节点并返回 至此一个节点的 beginWork 流程就走完了，下一次会根据是否存在子 Fiber 节点判断是执行当前 WorkInProgress Fiber 节点的 completeWork ，还是继续对子节点执行 beginWork ### completeWork > completeWork 执行在递归节点的 Fiber 创建之后，主要是为创建好的 Fiber 节点插入内容和插入真实 DOM 树 函数开始，会执行 popTreeContext 并传入 workInProgress，这个函数应该也和 Context 相关，然后进入到 swtich 逻辑，根据 WorkInProgress Fiber 节点的 tag 属性的不同进入不同的 case 逻辑，这里和 beginWork 基本上类似 React 的遍历顺序是从父到子，最终再从子回到父，所以首屏渲染中首先进入 completeWork 的 WorkInProgress 不一定会是 FiberNode ，在这里是 HostComponent 进入到 HostComponent 的 case 之后，又执行了一遍 popTreeContext，官方的注释也写明似乎是有一些考虑在 在 HostComponent 的 case 中，会判断 current 和 WorkInProgress.stateNode 是否为空，在首屏渲染的 completeWork 节点，这里都是空的，所以进入为空的逻辑：先检查当前 Fiber 节点是否存在 props 属性，最后调用 createInstance 创建一个 DOM 实例 createInstance 会调用 createElement 方法创建一个 DOM 实例，并调用 precacheFiberNode 和 updateFiberProps 方法，这两个方法都是在插入属性，一个在当前 WorkInProgress Fiber 节点上插入 DOM，一个是在 DOM 上插入 props，最后将处理好的 DOM 返回 ### appendAllChildren 函数首先会判断 WorkInProgress 的 child 属性是否为空，如果不为空就进入 while 循环，因为这里是首屏渲染的第一次 completeWork 所以进入到一定是最小的子组件，不会存在 child 属性，所以会跳过循环，也就会跳过插入逻辑，回到 completeWork 的调用栈中 然后回到 completeWork 的调用栈，它会将处理完毕的 DOM 示例插入到 WorkInProgress 的 stateNode 属性中，然后会调用 inalizeInitialChildren ，这个函数会为创建的 DOM 元素，插入已有的 props，内部也根据 Fiber 节点的 tag 区分不同的处理逻辑，还有对 props 是否合法的校验，甚至根据 props 的属性也做了不同逻辑的处理，最后会返回一个 Boolean 用于判断是否进入 markUpdate 逻辑，这个函数会把 ### 第一次触发更新 ### 第二次触发更新 ### 后续触发更新