react源码分析：实现react时间分片

我们常说的调度，可以分为两大模块，时间分片和优先级调度

• 时间分片的异步渲染是优先级调度实现的前提
• 优先级调度在异步渲染的基础上引入优先级机制控制任务的打断、替换。

本节将从时间分片的实现剖析react的异步渲染原理，阅读本文你讲可以了解

1. 时间分片是什么
2. 为什么需要时间分片
3. 时间分片在react中是如何运行的
4. 时间分片的极简实现

什么是时间分片

上文提到过，时间分片其实就是一个固定而连续且有间隔的时间区间

固定：时间分片是工作时长是固定的
连续：分片之间是连续的，当前分片内有工作没做完，会留到下个分片继续
有间隔：在进入下一个分片前，会有一定时间的间隔

这些解释比较抽象，可以更加通俗去理解

固定：每天固定工作8小时
连续：每天都要上班
有间隔：明天上班前会休息一段时间

为什么需要时间分片

我们知道，react最重要，也是最耗时的任务是节点遍历。

设想一个页面上有一万个DOM节点，如果我们用同步的方式一个个遍历完需要花费多少时间。而且如果是同步遍历的话，遍历的过程中，JS线程一直会霸占主线程，导致阻塞了浏览器的其他线程，导致卡顿的情况出现。

换个思路解决这个遍历问题，能不能遍历一会，休息一会，休息的过程中就可以把主线程交还给渲染线程和事件线程，这样就能及时渲染节点和响应用户事件，避免造成卡顿。

为了实现遍历一会，休息一会，我们可以将整个过程分解为以下三个步骤

1. 分片开启
2. 分片中断、分片重启
3. 延迟执行

这三个步骤与时间分片的三个特性一一对应

实现分片开启 - 固定

时间分片是独立于React的节点遍历流程的，所以只需要把节点遍历的入口函数以回调函数的形式传入即可，这样就可以让时间分片来决定节点遍历执行时机。

// 节点遍历的入口函数
function Reconcile协调() {
    节点遍历()
}
function Schedule调度() {
    创建分片(Reconcile协调)
}
1
2
3
4
5
6
7

第一步，需要将时间分片要调度的函数抽象为一个任务对象

function 创建分片(需要被调度的函数) {
    const 新的任务 = {
        callback: 需要被调度的函数
    }
}
1
2
3
4
5

第二步，设定分片工作时长，为了方便后续，可以直接计算过期时间。分片工作时长一般为5ms，但Scheduler会根据任务优先级有所调整，这里为了更好理解，先默认5ms。

const taskQueue = []
function 创建分片(需要被调度的函数) {
    const 新的任务 = {
        callback: 需要被调度的函数,
        expirationTime: performance.now() + 5000
    }
    taskQueue.push(新的任务)
    发起异步调度()
}
1
2
3
4
5
6
7
8
9

每次分片的创建其实都是新一轮调度的开始，所以在末尾会发起异步调度

为什么用performance.now()而不用Date.now()

performance.now()返回当前页面的停留时间，Date.now()返回当前系统时间。但不同的是performance.now()精度更高，且比Date.now()更可靠

1. performance.now()返回的是微秒级的，Date.now()只是毫秒级
2. performance.now()一个恒定的速率慢慢增加的，它不会受到系统时间的影响。Date.now()受到系统时间影响，系统时间修改Date.now()也会改变

实现分片中断、重启 - 连续

分片中断

我们在第一章已经将React的虚拟DOM结构从树形结构优化成链表结构，所以能轻松使用while循环实现可中断的遍历

那么如果要将遍历任务和时间分片相结合，且实现分片中断功能的话，只需要在while循环出加入分片时间过期的校验即可

function 分片过期校验() {
    return (perfromance.now() - 分片开启时间) >= 5000
}
let 需要被遍历的幸运儿节点 = null
function 构建节点() {
    /** * ...在这里进行节点构建工作 */
    需要被遍历的幸运儿节点 = 需要被遍历的幸运儿节点.next
}
function 节点遍历() {
    while (需要被遍历的幸运儿节点 != null && !分片过期校验()) {
        构建节点()
    }
}
function Schedule调度() {
    创建分片(Reconcile协调)
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

分片重启

分片重启意思就是上一轮时间分片因为过期中断了，需要重新发起一轮时间分片。

实现的思路是，在上一轮分片结束之后判断是否还需要开启下一轮分片，需要的话则重新发起一轮异步调度即可，相关参考视频讲解：进入学习

function 分片过期校验() {
    return (perfromance.now() - 分片开启时间) >= 5000
}
function 分片事件循环() {
    let 栈顶任务 = taskQueue.peek()

    while (栈顶任务) {
        if (分片过期校验()) break
        const 栈顶任务回调 = 栈顶任务.callback()
        if (typeof 栈顶任务回调 == 'function') {
            // 当前任务还没有执行完，继续搞
            栈顶任务.callback = 栈顶任务回调
        } else {
            // 当前任务已执行完，弹出队列
            taskQueue.pop()
        }
        栈顶任务 = taskQueue.peek()
    }

    // 还有任务哦
    if (栈顶任务) return true
    return false
}

function 分片执行() {
    分片开启时间 = performance.now()
    var 是否还有任务未执行完毕
    try {
        是否还有任务未执行完毕 = 分片事件循环()
    } finally {
        // 分片重启
        if (是否还有任务未执行) 发起异步调度()
    }
}

function 发起异步调度() {
    // 这里实际上是异步执行，看下面有间隔
    分片执行()
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

重启的条件就是判断分片任务队列中是否还有任务，有的话就发起下一轮的时间分片

实现延迟执行 - 有间隔

有间隔的本质是延迟JS的执行，让浏览器有喘息的时间，去处理其他线程的任务，哪如何把主线程控制权交还给浏览器呢？？

可以使用异步特性发起下一轮时间分片，实现延迟执行

function 发起异步调度() {
    // 将主线程短暂的交还给浏览器
    setTimeout(() => {
        分片执行()
    }, 0)
}
1
2
3
4
5
6

为什么选择宏任务实现异步执行

微任务无法真正达到交还主线程控制权的要求。

因为一轮事件循环，是先执行一个宏任务，然后再清空微任务队列里面的任务，如果在清空微任务队列的过程中，依然有新任务插入到微任务队列中的话，还是把这些任务执行完毕才会释放主线程。所以微任务不合适。

时间分片异步执行方案的演进

为什么不是setTimeout？

因为setTimeout的递归层级过深的话，延迟就不是1ms，而是4ms，这样会造成延迟时间过长

为什么不是requestAnimationFrame？

requestAnimationFramed是在微任务执行完之后，浏览器重排重绘之前执行，执行的时机是不准确的。如果raf之前JS的执行时间过长，依然会造成延迟

为什么不是requestIdleCallback？

requestIdleCallback的执行时机是在浏览器重排重绘之后，也就是浏览器的空闲时间执行。其实执行的时机依然是不准确的，raf执行的JS代码耗时可能会过长

为什么是 MessageChannel？

MessageChannel的执行时机比setTimeout靠前

在React中，异步执行优先使用setImmediate，其次是MessageChannel，最后是setTimeout，都是根据浏览器对这些的特性支持程度决定的。

时间分片简单实现

下面会整合上面的所有代码，模拟出最简单的时间分片实现（不包含优先级机制）

Scheduler.js

const taskQueue = []
let 分片开启时间 = -1

// **时间分片核心**
const 分片过期校验 = () => {
    return (perfromance.now() - 分片开启时间) >= 5000
}
function 分片事件循环() {
    let 栈顶任务 = taskQueue.peek()

    while (栈顶任务) {
        // 每执行完一个任务，都要校验一下分片是否过期
        if (分片过期校验()) break
        const 栈顶任务回调 = 栈顶任务.callback()
        if (typeof 栈顶任务回调 == 'function') {
            // 当前任务还没有执行完，继续搞
            栈顶任务.callback = 栈顶任务回调
        } else {
            // 当前任务已执行完，弹出队列
            taskQueue.pop()
        }
        栈顶任务 = taskQueue.peek()
    }

    // 还有任务哦
    if (栈顶任务) return true
    return false
}

function 分片执行() {
    分片开启时间 = performance.now()
    var 是否还有任务未执行完毕
    try {
        是否还有任务未执行完毕 = 分片事件循环()
    } finally {
        // **时间分片核心：分片重启**
        if (是否还有任务未执行) 发起异步调度()
    }
}
// 实例化 MessageChannel
const channel = new MessageChannel()
const port2 = channel.port2
channel.port1.onmessage = 分片执行

function 发起异步调度() {
    // 向通道1发消息，通道1收到消息就会执行分片任务
    // **时间分片核心：延迟执行**
    port2.postMessage(null)
}
function 创建分片(需要被调度的函数) {
    // **时间分片核心：分片开启**
    const 新的任务 = {
        callback: 需要被调度的函数,
        expirationTime: performance.now() + 5000
    }
    taskQueue.push(新的任务)
    发起异步调度()
}
export default {
    创建分片,
    分片过期校验
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

ReactDOM.js

import * as Scheduler from './Scheduler'
const {
    创建分片,
    分片过期校验
} = Scheduler

let 需要被遍历的幸运儿节点 = null
function 构建节点() {
    /** * ...在这里进行节点构建工作 */
    需要被遍历的幸运儿节点 = 需要被遍历的幸运儿节点.next
}
function 节点遍历() {
    // **时间分片核心：分片中断**
    while (需要被遍历的幸运儿节点 != null && !分片过期校验()) {
        构建节点()
    }
}
function Schedule调度() {
    创建分片(Reconcile协调)
}
function 调度入口() {
    需要被遍历的幸运儿节点 = react应用根节点
    Schedule调度()
}
调度入口()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

这段时间分片的伪代码相对于react中源码的实现，少了很多逻辑判断，并且集中了起来，应该会相对好理解很多。

如果还是觉得有点晦涩，可以重点关注伪代码中标有时间分片核心注释的代码，结合上文提到的概念理解

总结

读完这篇文章估计你可能对时间分片的概念已经有所有了解了，是不是觉得react16的新特性之一时间分片，也并没有想象中的神秘。

总的下来，时间分片就是由简单的三个模块组成：

1. 分片开启
2. 分片中断、重启
3. 延迟执行

时间分片是Scheduler调度器两大特性中的一个，另一个是任务的优先级调度，接下来可能会花两到三篇的篇幅去讲解。在源码阅读的过程中，我觉得时间分片的实现已经非常惊艳了，没想到后面优先级调度的设计对我更是无可匹敌的冲击。