React 设计模式

三大模块

我们创建一个Holle World，看一下浏览器的调用栈。你会发现react执行了一大堆函数，我们将这些函数分成调度、协调、渲染三大模块，这三大模块就是接下来要研究的。

设计理念

在学习之前我们要将思路转变，我们作为开发者总是会去关心API上的事情，但是作为一个框架的开发人员，应该是重点关心设计理念。

如何设计，决定着这个框架的最终走向，这是十分重要的。

引用官网说的一句话：React是用 JavaScript 构建 快速响应 的大型应用程序。

那他是如何做到快速响应的？开发中是什么导致我们的应用不流畅呢？

可能来源于：大量的计算或者网络请求的延迟。总结起来就是：计算能力与网络延迟。

计算能力关乎到我们的CPU。网络延迟关乎到IO。这两个是我们的瓶颈。

React 解决CPU瓶颈的办法

主流浏览器的刷新频率是60HZ（也就是一帧），也就是16.6ms刷新一次。在这16.6ms中浏览器会依次执行：JavaScript脚本、样式布局、样式绘制。

我们想一下，如果JavaScript脚本执行时间超过16.6ms（也就是一帧），会发生什么情况？

答案是：在当前这一帧中就没有时间进行样式布局、样式绘制。会出现掉帧的情况，从而导致卡顿。比如，浏览器滚动不流畅，输入框输入的字符不能及时响应在页面上。

前端的解决办法大部分是使用防抖或节流的方式，进而限制一定时间内浏览器的响应变化。这种方式是治标不治本的办法。

React给出的方案：将 同步的更新 转变成 异步可中断的更新。

异步可中断的更新

如果某一部分的执行时间特别长，React 会中断自己的工作，并将控制权交给浏览器。等待下一帧自己预留的那部分时间到来之后，React 会继续之前被中断的工作。

这样，浏览器就会有时间进行样式布局、样式绘制。从而达到减少掉帧的可能性。

React 解决IO瓶颈的办法

文档上给出的是：将人机交互研究的结果整合到真实的UI中。比如，在屏幕之间切换时显示过多的中间加载状态会使切换的速度变慢。

新旧的架构对比

新的架构解决了老架构什么问题？新架构相对于老架构的优点是什么？

老的架构

老架构是分成两个部分：

• 决定渲染什么组件 ---- Reconclier（协调器）
• 将组件渲染到视图中 ---- Renderer（渲染器）

Reconclier(协调器)作用：负责本次更新哪些组件被渲染。Diff算法就是发生在Reconclier(协调器)中。

Diff算法中会将上次更新的组件与本次更新的组件做一个对比，最终只有变化的部分被渲染到视图中。

经过Diff算法决定渲染的组件会被交给Renderer(渲染器)，渲染到视图中。

不同的Renderer(渲染器)会将组件渲染到不同的数组环境的视图中。比如：

• ReactDom渲染器，会将组件渲染到DOM/SSR中。
• ReactNative渲染器，会将组件渲染为APP原生组件。
• ReactTest渲染器，会将组件渲染为纯JS对象，用于测试。
• ReactArt渲染器，会将组件渲染到canvas/svg上。

在React老的架构里，如果页面上的UI发生改变，首先会去执行Reconclier(协调器)，然后再去执行Renderer(渲染器)。这两个是交替且同步执行的。

上面这张图，我希望点击button按钮，左页面每个li变为2、4、6。同时不希望Renconclier(协调器)与Renderer(渲染器)同步执行。渲染器在渲染1变为2之后，去中断发生。

显然老的架构是无法支持的。

新的架构

由于老的架构无法中断发生，React16重写了架构。将原先的 同步更新 改为 异步可中断更新

由于新的架构是可中断的，React加入了一个模块对这些异步更新进行管理。如下三部分：

• 调度更新 ---- Scheduler(调度器)
• 决定需要更新什么组件 ---- Reconclier(协调器)
• 将组件更新到视图中 ---- Renderer(渲染器)

老的架构中，UI发生更新之后直接会交给Reconclier(协调器)处理。

新的架构中，UI发生更新会先交给Scheduler(调度器)进行优先级比较，优先级高的会交给Reconclier(协调器)进行处理。

在协调器采用Diff算法时，产生了更高优先级的更新 Reconclier(协调器)会中断，然后执行更高优先级的更新。

由于Scheduler(调度器)与Reconclier(协调器)都是在内存中，用户并不会感知到被中断的操作过程。

当某次更新完成了在协调器中的工作时，Reconclier(协调器)会通知Renderer(渲染器)，本次更新中有哪些组件需要进行UI渲染操作。最后会由Renderer(渲染器)来分别执行视图的渲染操作。

上面这张图是产生更新时，三部分是如何相互工作的。

Scheduler(调度器)：评定优先级，将当前评定的高优先级交给Reconclier(协调器)。

Reconclier(协调器)：接收到更新之后创建虚拟DOM，然后给要更新的虚拟DOM打上updata标记，最后交给Renderer(渲染器)。

Renderer(渲染器)：接收到通知，查看哪些虚拟DOM被标记了updata。对应的执行更新DOM操作。

总结

• 老架构如何运行的？有什么缺点？
• 新架构如何解决快速响应问题？
• 新架构的Scheduler(调度器)、Reconclier(协调器)、Renderer(渲染器)三部分如何配合完成可中断的异步更新的？
• Diff算法做了什么？

最后，感谢大家支持啦～～～～～～～～～