大家好，我卡颂。
React内部最难理解的地方就是「调度算法」，不仅抽象、复杂，还重构了一次。
可以说，只有React团队自己才能完全理解这套算法。
既然这样，那本文尝试从React团队成员的视角出发，来聊聊「调度算法」。
什么是调度算法
React在v16之前面对的主要性能问题是：当组件树很庞大时，更新状态可能造成页面卡顿，根本原因在于：更新流程是「同步、不可中断的」。
为了解决这个问题，React提出Fiber架构，意在「将更新流程变为异步、可中断的」。
最终实现的交互流程如下：
- 不同交互产生不同优先级的更新(比如onClick回调中的更新优先级最高，useEffect回调中触发的更新优先级一般)
- 「调度算法」从众多更新中选出一个优先级作为本次render的优先级
- 以步骤2选择的优先级对组件树进行render
在render过程中，如果又触发交互流程，步骤2又选出一个更高优先级，则之前的render中断，以新的优先级重新开始render。
本文要聊的就是步骤2中的「调度算法」。
expirationTime调度算法
「调度算法」需要解决的最基本的问题是：如何从众多更新中选择其中一个更新的优先级作为本次render的优先级?
最早的算法叫做expirationTime算法。
具体来说，更新的优先级与「触发交互的当前时间」及「优先级对应的延迟时间」相关：
- // MAX_SIGNED_31_BIT_INT为最大31 bit Interger
- update.expirationTime = MAX_SIGNED_31_BIT_INT - (currentTime + updatePriority);
例如，高优先级更新u1、低优先级更新u2的updatePriority分别为0、200，则
- MAX_SIGNED_31_BIT_INT - (currentTime + 0) > MAX_SIGNED_31_BIT_INT - (currentTime + 200)
-
- // 即
- u1.expirationTime > u2.expirationTime;
代表u1优先级更高。
expirationTime算法的原理简单易懂：每次都选出所有更新中「优先级最高的」。
如何表示“批次”
除此之外，还有个问题需要解决：如何表示「批次」?
「批次」是什么?考虑如下例子：
- // 定义状态num
- const [num, updateNum] = useState(0);
-
- // ...某些修改num的地方
- // 修改的方式1
- updateNum(3);
- // 修改的方式2
- updateNum(num => num + 1);
两种「修改状态的方式」都会创建更新，区别在于：
- 第一种方式，不需考虑更新前的状态，直接将状态num修改为3
- 第二种方式，需要基于「更新前的状态」计算新状态
由于第二种方式的存在，更新之间可能有连续性。
所以「调度算法」计算出一个优先级后，组件render时实际参与计算「当前状态的值」的是：
「计算出的优先级对应更新」 + 「与该优先级相关的其他优先级对应更新」
这些相互关联，有连续性的更新被称为一个「批次」(batch)。
expirationTime算法计算「批次」的方式也简单粗暴：优先级大于某个值(priorityOfBatch)的更新都会划为同一批次。
- const isUpdateIncludedInBatch = priorityOfUpdate >= priorityOfBatch;
expirationTime算法保证了render异步可中断、且永远是最高优先级的更新先被处理。
这一时期该特性被称为Async Mode。
IO密集型场景
Async Mode可以解决以下问题：
- 组件树逻辑复杂导致更新时卡顿(因为组件render变为可中断)
- 重要的交互更快响应(因为不同交互产生更新的优先级不同)
这些问题统称为CPU密集型问题。
在前端，还有一类问题也会影响体验，那就是「请求数据造成的等待」。这类问题被称为IO密集型问题。
为了解决IO密集型问题的，React提出了Suspense。考虑如下代码：
- const App = () => {
- const [count, setCount] = useState(0);
-
- useEffect(() => {
- const t = setInterval(() => {
- setCount(count => count + 1);
- }, 1000);
- return () => clearInterval(t);
- }, []);
-
- return (
- <>
-
loading...
