React Fiber技术解读：你需要知道面试官最关心的话题！

发表于 1年以前 | 总阅读数：889 次

关于 React Fiber 出来也有几年了，可最近面试多了才发现，还是有很多人一知半解，所以本文梳理了一下有关 Fiber、以及这个话题环环相扣，可以延伸的点，给大家面试复习、查缺补漏，如果你是面试官也可直接拿去提问。

React Fiber

说一下 React Fiber

是指时间分片嘛，可以把渲染工作切片，优化渲染性能的。

因为 React 是函数式编程嘛，单向数据流，需要手动 setState 来更新，所以当数据改变时会默认全部重新渲染整个组件树，而构建虚拟 DOM 则是采用同步递归的方式，如果组件很复杂且嵌套深，那么这个构建虚拟 DOM 的过程就需要很多时间，而这种任务默认要执行完才会把控制权交给浏览器，一旦执行时间很长，可能就会地把浏览器卡死。

虽然可以用 pureComponent/shouldComponentUpdate/useMemo/useCallback 等方法来进行控制部分更新或缓存，但也是治标不治本。而 fiber 是可以使渲染过程被中断，可以把控制权先交还给浏览器，让位高优先级的任务，等浏览器空闲时再恢复渲染，这样就不会显得卡顿，而是一帧一帧有规律的执行任务，看起来虽然有点慢，但是一直在慢慢执行的

就像一个房子，组件层级就像房子的楼层，但是每一层房子顶都破了很多个洞的，那几个方法就像一片瓦，都能盖一个小洞，但稍不注意少盖一个房间就会漏水，房间里的人(用户)就能感知到(卡)，而 fiber 就像在破洞下面放了根水管直接通到屋外，虽然看起来水管弯弯绕绕的，水落地的时间慢了(执行时间长了)，但房间里的人，就感觉不到漏水了(屋子还是个破屋子)

实在是因为 React 没办法在编译阶段优化更多了，所以采用这种方式来弥补伤害

那 React Fiber 是怎么实现的

主要是通过两个原生的 API 来实现的 requestAnimationFrame 和 requestIdleCallback

显示器每秒 60 帧我们看着才不会感觉到卡嘛，比如动画的时候，一帧的时间内布局和绘制结束，还有剩余时间，JS 就会拿到主线程使用权，如果 JS 某个任务执行过长，动画下一帧开始时 JS 还没有执行完，就会导致掉帧，出现卡顿。

所以就通过把 JS 任务分成更小的任务块，分到每一帧上的方式，一帧时间到先暂停 JS 执行，然后下一帧绘制任完成再把主线程交给 JS，在每一帧绘制之前调用 requestAnimationFrame；在每一帧空间阶段，就是一帧动画任务完成，下一帧还没到开始时间，这中间还有时间的话就调用 requetIdleCallback，执行它里面的任务

还有其他方式能实现吗

函数式编程嘛，generator 就可以控制函数的运行过程中断和恢复，就像这样：

// 任务列表
const tasks = []
function * run () {
    let task
    while(task = task.shift()) {
        // 如果有高优先级的任务
        if (hasHighPriorityTask()) {
            // 中断
            yield
        }
    }
}
// 中断后恢复
const iterator = run()
// 这样就恢复了
iterator.next()

为什么不直接用 generator

这个问题 React 开发者有在源码里回答过：

一是因为 React 是迭代的，而使用 generator + yield 的话需要把所有代码都包装成这个形式，非常麻烦，工作量很大
二是 generator 内部是有状态的，比如一个函数里有用到多个 yield 中断，就像 await 一样，有时候后面的会依赖前面的结果，可当后面的执行前，前面的又更新了，后面就无法拿到最新的值，这样就不可控了

所以就自己实现一个完全可控的