React架构

React的定位

• 从官网看到React的理念：
  
• 制约快速响应的因素有:
  1. 当遇到大计算量的操作或者设备性能不足使页面掉帧，导致卡顿。
  2. 发送网络请求后，由于需要等待数据返回才能进一步操作导致不能快速响应。
     这两类场景可以概括为：
• CPU的瓶颈
• IO的瓶颈

React如何解决CPU瓶颈

• 主流浏览器刷新频率为60Hz，即每（1000ms / 60Hz）16.6ms浏览器刷新一次。在每16.6ms内，需要完成 执行JS–>布局–>绘制。当JS执行时间过长，超出了16.6ms，这次刷新就没有时间执行样式布局和样式绘制了，导致页面卡顿。
• 如何解决:
  在浏览器每一帧的时间中，预留一些时间给JS线程，React利用这部分时间更新组件(5ms),当预留的时间不够用时，React将线程控制权交还给浏览器使其有时间渲染UI，React则等待下一帧时间到来继续被中断的工作。此时我们的长任务被拆分到每一帧不同的task中，JS脚本执行时间大体在5ms左右，这样浏览器就有剩余时间执行样式布局和样式绘制，减少掉帧的可能性。开启Concurrent Mode模式才会有时间切片
  

React如何解决IO瓶颈

• 网络延迟是前端开发者无法解决的。如何在网络延迟客观存在的情况下，减少用户对网络延迟的感知？
• React给出的答案是将人机交互研究的结果整合到真实的 UI 中
• 研究表明，在屏幕之间切换时显示过多的中间加载状态会使切换的速度变慢。如果请求时间超过一个范围，再显示loading的效果
  
  

将同步的更新变为可中断的异步更新

例子:

• 同步更新：https://codesandbox.io/s/pensive-shirley-wkp46
• 异步更新：https://codesandbox.io/s/infallible-dewdney-9fkv9?file=/src/index.js
  当牺牲了列表的更新速度，React大幅提高了输入响应速度，使交互更自然
• 性能比较：https://codesandbox.io/s/concurrent-3h48s?file=/src/index.js

老的React15架构

分为两层

• Reconciler（协调器）—— 负责找出变化的组件
• Renderer（渲染器）—— 负责将变化的组件渲染到页面上

缺点：
由于递归执行，所以更新一旦开始，中途就无法中断。当层级很深时，递归更新时间超过了16ms，用户交互就会卡顿。

新的React16架构

分为三层：
Scheduler（调度器）—— 调度任务的优先级，高优先级任务优先进入Reconciler
Reconciler（协调器）—— 负责找出变化的组件
Renderer（渲染器）—— 负责将变化的组件渲染到页面上

• 如何解决中断更新时DOM渲染不完全的问题呢？
  Reconciler与Renderer不再是交替工作。当Scheduler将任务交给Reconciler后，Reconciler会为变化的虚拟DOM打上代表增/删/更新的标记，类似这样：
  
  
  整个Scheduler与Reconciler的工作都在内存中进行。只有当所有组件都完成Reconciler的工作，才会统一交给Renderer。