React中的调和 (Stack Reconciler or Fiber Reconciler)

本文是结合实践中和学习技术文章总结出来的笔记(个人使用),如有雷同纯属正常((✿◠‿◠))

喜欢的话点个赞,谢谢!

React的渲染流程15.x跟16.x,17,18之后是不同的,这里拆开来讲讲为啥两个大版本之间的巨大差异

React15下的Stack Reconciler

当下React15几乎已经无人问津了,但是为了了解当前热门的 Fiber Reconciler 之前还是要了解一下Stack Reconciler,了解Fiber变革的原因更能直达核心

Stack Reconciler是什么

Reconciler翻译过来是是调和/协调,引用官方文档的一句话:

Virtual DOM 是一种编程概念。在这个概念里，UI 以一种理想化的，或者说“虚拟的”表现形式被保存于内存中，并通过如 ReactDOM 等类库使之与“真实的” DOM 同步。这一过程叫作协调（调和）。

简单的说就是将虚拟DOM映射到真实DOM的这一过程, 我们大家所熟悉的diff算法就是这个Reconciler中的一环,

diff算法是找不同的过程,而Reconciler是使一致的过程,它只是使一致过程中的一个环节。diff算法具体是什么这里不做多讲解了,上一章我们已经讲过了,需要的小伙伴可以点击React diff算法 与虚拟DOM(React笔记之三)-CSDN博客

Stack Reconciler的调和过程

在 React 16 之前，React 的渲染和更新阶段依赖的是如下图所示的两层架构：

生命周期中render阶段到commit阶段的过程:

从上图看出,我们更新J节点的时候需要进行深层次的递归计算,这个过程的致命性在于他是同步的不可被打断的。当处理更加庞大的虚拟DOM节点树的时候,Stack Reconciler的调和过程会非常长,这意味着Javascript会超时占用主线程不放,进而导致页面渲染卡顿/卡死,页面交互无反应等问题。这也是Stack Reconciler所面临的困局,导致React团队重写了Reconciler过程

React16 Fiber Reconciler

前面已经讲过Stack Reconciler了,它是一个同步递归的过程,会超时占用主线程。那么Fiber Reconciler是如何解决这个问题的呢?

Fiber架构应用的目的,官方说是为了增量渲染,所谓的增量渲染就是把大的任务拆分成不同的小任务,然后将其以时间切片(不同的渲染帧)的方式分散开来。真正的目的是为了让任务可中断、可恢复,并且赋予不同任务不同的优先级来达到最优的渲染效果,提高用户的体验。

在 React 16 之后，React 的渲染和更新阶段依赖的是如下图所示的三层架构：

对比React15多出了一个Scheduler(优先级调度器),调度器的作用是,每次触发更新的时候调度更新的优先级。

比如有一个更新任务B抵达调度器,调度器将其塞入Reconciler层,此时又有一个更新任务A抵达,调度器发现A的优先级高于B,那么就会暂停B的更新,优先更新A,等A执行完了之后,再将中断的B重新加入Reconciler层,继续它的渲染流程

React16生命周期中render阶段到commit阶段的过程:

可以清晰的看出,原来的React15生命周期render阶段跟React16最大的不同就在于改写了Reconciler 层和增加了一个优先级调度器Scheduler

总结:本笔记主要是总结了一下React15版本与React16版本下的Reconciler 过程的变化,主要还是为了了解一下Fiber架构的核心特性: 可中断、可恢复、任务拆分