关于前端:阿里三面灵魂一击有react-fiber为什么不需要vue-fiber呢

提到 react fiber，大部分人都晓得这是一个 react 新个性，看过一些网上的文章，大略能说出“纤程”“一种新的数据结构”“更新时调度机制”等关键词。

但如果被问：

有 react fiber，为什么不须要 vue fiber 呢；
之前递归遍历虚构 dom 树被打断就得从头开始，为什么有了 react fiber 就能断点复原呢；

本文将从两个框架的响应式设计为切入口讲清这两个问题，不波及艰涩源码，不论有没有应用过 react，浏览都不会有太大阻力。

无论你罕用的是 react，还是 vue，“响应式更新”这个词必定都不生疏。

响应式，直观来说就是视图会自动更新。如果一开始接触前端就间接上手框架，会感觉这是天经地义的，但在“响应式框架”入世之前，实现这一性能是很麻烦的。

上面我将做一个工夫显示器，用原生 js、react、vue 别离实现：

原生 js：

想让屏幕上内容变动，必须须要先找到 dom（document.getElementById）, 而后再批改 dom（clockDom.innerText）。

<div id="root">
    <div id="greet"></div>
    <div id="clock"></div>
</div>
<script>
    const clockDom = document.getElementById('clock');
    const greetDom = document.getElementById('greet');
    setInterval(() => {clockDom.innerText = ` 当初是：${Util.getTime()}`
        greetDom.innerText = Util.getGreet()}, 1000);
</script>

有了响应式框架，所有变得简略了

react：

对内容做批改，只须要调用 setState 去批改数据，之后页面便会从新渲染。

<body>
    <div id="root"></div>
    <script type="text/babel">
        function Clock() {const [time, setTime] = React.useState()
            const [greet, setGreet] = React.useState()
            setInterval(() => {setTime(Util.getTime())
                setGreet(Util.getGreet())
            }, 1000);
            return ( 
                <div>
                    <div>{greet}</div>
                    <div> 当初是：{time}</div>
                </div>
            )
        }
        ReactDOM.render(<Clock/>,document.getElementById('root'))
    </script>
</body>

vue：

咱们一样不必关注 dom，在批改数据时, 间接 this.state=xxx 批改，页面就会展现最新的数据。

<body>
    <div id="root">
        <div>{{greet}}</div>
        <div> 当初是：{{time}}</div>
    </div>
    <script>
        const Clock = Vue.createApp({data(){
                return{
                    time:'',
                    greet:''
                }
            },
            mounted(){setInterval(() => {this.time = Util.getTime();
                    this.greet = Util.getGreet();}, 1000);
            }
        })
        Clock.mount('#root')
    </script>
</body>

上文提到批改数据时，react 须要调用 setState 办法，而 vue 间接批改变量就行。看起来只是两个框架的用法不同罢了，但响应式原理正在于此。

从底层实现来看批改数据：在 react 中，组件的状态是不能被批改的，setState没有批改原来那块内存中的变量，而是去新开拓一块内存；
而 vue 则是间接批改保留状态的那块原始内存。

所以常常能看到 react 相干的文章里常常会呈现一个词 ”immutable”，翻译过去就是不可变的。

数据批改了，接下来要解决视图的更新：react 中，调用 setState 办法后，会自顶向下从新渲染组件，自顶向下的含意是，该组件以及它的子组件全副须要渲染；而 vue 应用Object.defineProperty（vue@3 迁徙到了 Proxy）对数据的设置（setter）和获取（getter）做了劫持，也就是说，vue 能精确晓得视图模版中哪一块用到了这个数据，并且在这个数据批改时，通知这个视图，你须要从新渲染了。

所以当一个数据扭转，react 的组件渲染是很耗费性能的——父组件的状态更新了，所有的子组件得跟着一起渲染，它不能像 vue 一样，准确到以后组件的粒度。

为了佐证，我别离用 react 和 vue 写了一个 demo，性能很简略：父组件嵌套子组件，点击父组件的按钮会批改父组件的状态，点击子组件的按钮会批改子组件的状态。

为了更好的比照，直观展现渲染阶段，没用应用更风行的 react 函数式组件，vue 也用的是不常见的 render 办法：

class Father extends React.Component{
    state = {fatherState:'Father-original state'}
    changeState = () => {console.log('-----change Father state-----')
        this.setState({fatherState:'Father-new state'})
    }
    render(){console.log('Father:render')
        return ( 
            <div>
                <h2>{this.state.fatherState}</h2>
                <button onClick={this.changeState}>change Father state</button>
                <hr/>
                <Child/>
            </div>
        )
    }
}
class Child extends React.Component{
    state = {childState:'Child-original state'}
    changeState = () => {console.log('-----change Child state-----')
        this.setState({childState:'Child-new state'})
    }
    render(){console.log('child:render')
        return ( 
            <div>
                <h3>{this.state.childState}</h3>
                <button onClick={this.changeState}>change Child state</button>
            </div>
        )
    }
}
ReactDOM.render(<Father/>,document.getElementById('root'))

下面是应用 react 时的成果，批改父组件的状态，父子组件都会从新渲染：点击change Father state，不仅打印了Father:render，还打印了child:render。
（戳这里试试在线 demo）

 const Father = Vue.createApp({data() {
        return {fatherState:'Father-original state',}
    },
    methods:{changeState:function(){console.log('-----change Father state-----')
            this.fatherState = 'Father-new state'
        }
    },
    render(){console.log('Father:render')
        return Vue.h('div',{},[Vue.h('h2',this.fatherState),
            Vue.h('button',{onClick:this.changeState},'change Father state'),
            Vue.h('hr'),
            Vue.h(Vue.resolveComponent('child'))
        ])
    }
})
Father.component('child',{data() {
        return {childState:'Child-original state'}
    },
    methods:{changeState:function(){console.log('-----change Child state-----')
            this.childState = 'Child-new state'
        }
    },
    render(){console.log('child:render')
        return Vue.h('div',{},[Vue.h('h3',this.childState),
            Vue.h('button',{onClick:this.changeState},'change Child state'),

        ])
    }
})
Father.mount('#root')

下面应用 vue 时的成果，无论是批改哪个状态，组件都只从新渲染最小颗粒：点击change Father state，只打印Father:render，不会打印child:render。

（戳这里试试在线 demo）

首先须要强调的是，上文提到的“渲染”“render”“更新“都不是指浏览器真正渲染出视图。而是框架在 javascript 层面上，调用本身实现的 render 办法，生成一个一般的对象，这个对象保留了实在 dom 的属性，也就是常说的虚构 dom。本文会用组件渲染和页面渲染对两者做辨别。

每次的视图更新流程是这样的：

组件渲染生成一棵新的虚构 dom 树；
新旧虚构 dom 树比照，找出变动的局部；（也就是常说的 diff 算法）
为真正扭转的局部创立实在 dom，把他们挂载到文档，实现页面重渲染；

因为 react 和 vue 的响应式实现原理不同，数据更新时，第一步中 react 组件会渲染出一棵更大的虚构 dom 树。

下面说了这么多，都是为了不便讲清楚为什么须要 react fiber：在数据更新时，react 生成了一棵更大的虚构 dom 树，给第二步的 diff 带来了很大压力——咱们想找到真正变动的局部，这须要破费更长的工夫。js 占据主线程去做比拟，渲染线程便无奈做其余工作，用户的交互得不到响应，所以便呈现了 react fiber。

react fiber 没法让比拟的工夫缩短，但它使得 diff 的过程被分成一小段一小段的，因为它有了“保留工作进度”的能力。js 会比拟一部分虚构 dom，而后让渡主线程，给浏览器去做其余工作，而后持续比拟，顺次往返，等到最初比拟实现，一次性更新到视图上。

上文提到了，react fiber 使得 diff 阶段有了被保留工作进度的能力，这部分会讲清楚为什么。

咱们要找到前后状态变动的局部，必须把所有节点遍历。

在老的架构中，节点以树的模式被组织起来：每个节点上有多个指针指向子节点。要找到两棵树的变动局部，最容易想到的方法就是深度优先遍历，规定如下：

从根节点开始，顺次遍历该节点的所有子节点；
当一个节点的所有子节点遍历实现，才认为该节点遍历实现；

如果你零碎学习过数据结构，应该很快就能反馈过去，这不过是深度优先遍历的后续遍历。依据这个规定，在图中标出了节点实现遍历的程序。

这种遍历有一个特点，必须一次性实现。假如遍历产生了中断，尽管能够保留当下进行中节点的索引，下次持续时，咱们确实能够持续遍历该节点上面的所有子节点，然而没有方法找到其父节点——因为每个节点只有其子节点的指向。断点没有方法复原，只能从头再来一遍。

以该树为例：

在遍历到节点 2 时产生了中断，咱们保留对节点 2 的索引，下次复原时能够把它上面的 3、4 节点遍历到，然而却无奈找回 5、6、7、8 节点。

在新的架构中，每个节点有三个指针：别离指向第一个子节点、下一个兄弟节点、父节点。这种数据结构就是 fiber，它的遍历规定如下：

从根节点开始，顺次遍历该节点的子节点、兄弟节点，如果两者都遍历了，则回到它的父节点；
当一个节点的所有子节点遍历实现，才认为该节点遍历实现；

依据这个规定，同样在图中标出了节点遍历实现的程序。跟树结构比照会发现，尽管数据结构不同，然而节点的遍历开始和实现程序截然不同。不同的是，当遍历产生中断时，只有保留下以后节点的索引，断点是能够复原的——因为每个节点都放弃着对其父节点的索引。

同样在遍历到节点 2 时中断，fiber 构造使得剩下的所有节点仍旧能全副被走到。

这就是 react fiber 的渲染能够被中断的起因。树和 fiber 尽管看起来很像，但实质上来说，一个是树，一个是链表。

这种数据结构之所以被叫做 fiber，因为 fiber 的翻译是纤程，它被认为是协程的一种实现模式。协程是比线程更小的调度单位：它的开启、暂停能够被程序员所管制。具体来说，react fiber 是通过 requestIdleCallback 这个 api 去管制的组件渲染的“进度条”。

requesetIdleCallback是一个属于宏工作的回调，就像 setTimeout 一样。不同的是，setTimeout 的执行机会由咱们传入的回调工夫去管制，requesetIdleCallback 是受屏幕的刷新率去管制。本文不对这部分做深入探讨，只须要晓得它每隔 16ms 会被调用一次，它的回调函数能够获取本次能够执行的工夫，每一个 16ms 除了 requesetIdleCallback 的回调之外，还有其余工作，所以能应用的工夫是不确定的，但只有工夫到了，就会停下节点的遍历。

应用办法如下：

const workLoop = (deadLine) => {
    let shouldYield = false;// 是否该让出线程
    while(!shouldYield){console.log('working')
        // 遍历节点等工作
        shouldYield = deadLine.timeRemaining()<1;}
    requestIdleCallback(workLoop)
}
requestIdleCallback(workLoop);

requestIdleCallback 的回调函数能够通过传入的参数 deadLine.timeRemaining() 查看当下还有多少工夫供本人应用。下面的 demo 也是 react fiber 工作的伪代码。

但因为兼容性不好，加上该回调函数被调用的频率太低，react 理论应用的是一个 polyfill(本人实现的 api)，而不是 requestIdleCallback。

当初，能够总结一下了：React Fiber 是 React 16 提出的一种更新机制，应用链表取代了树，将虚构 dom 连贯，使得组件更新的流程能够被中断复原；它把组件渲染的工作分片，到时会被动让出渲染主线程。

首先放一张在社区广为流传的比照图，别离是用 react 15 和 16 实现的。这是一个宽度变动的三角形，每个小圆形两头的数字会随工夫扭转，除此之外，将鼠标悬停，小圆点的色彩会发生变化。

（戳这里是 react15-stack 在线地址|这里是 react16-fiber）

实操一下，能够发现两个特点：

应用新架构后，动画变得晦涩，宽度的变动不会卡顿；
应用新架构后，用户响应变快，鼠标悬停时色彩变动更快；

看到到这里先略微停一下，这两点都是 fiber 带给咱们的吗——用户响应变快是能够了解的，但应用 react fiber 能带来渲染的减速吗？

动画变晦涩的根本原因，肯定是一秒内能够取得更多动画帧。然而当咱们应用 react fiber 时，并没有缩小更新所须要的总工夫。

为了不便了解，我把刷新时的状态做了一张图：

下面是应用旧的 react 时，取得每一帧的工夫点，上面是应用 fiber 架构时，取得每一帧的工夫点，因为组件渲染被分片，实现一帧更新的工夫点反而被推后了，咱们把一些工夫片去解决用户响应了。

这里要留神，不会呈现“一次组件渲染没有实现，页面局部渲染更新”的状况，react 会保障每次更新都是残缺的。

但页面的动画的确变得晦涩了，这是为什么呢？

我把该项目标代码仓库 down 下来，看了一下它的动画实现：组件动画成果并不是间接批改 width 取得的，而是应用的 transform:scale 属性搭配 3D 变换。如果你据说过硬件加速，大略晓得为什么了：这样设置页面的从新渲染不依赖上图中的渲染主线程，而是在 GPU 中间接实现。也就是说，这个渲染主线程线程只用保障有一些工夫片去响应用户交互就能够了。

-<SierpinskiTriangle x={0} y={0} s={1000}>
+<SierpinskiTriangle x={0} y={0} s={1000*t}>
    {this.state.seconds}
</SierpinskiTriangle>

批改一下我的项目代码中 152 行，把图形的变动改为宽度 width 批改，会发现即应用 react fiber，动画也会变得相当卡顿，所以这里的晦涩次要是 CSS 动画的功绩。（内存不大的电脑审慎尝试，浏览器会卡死）

咱们当初曾经晓得了 react fiber 是在补救更新时“无脑”刷新，不够准确带来的缺点。这是不是能阐明 react 性能更差呢？

并不是。孰优孰劣是一个很有争议的话题，在此不做评估。因为 vue 实现精准更新也是有代价的，一方面是须要给每一个组件配置一个“监视器”，治理着视图的依赖收集和数据更新时的公布告诉，这对性能同样是有耗费的；另一方面 vue 能实现依赖收集得益于它的模版语法，实现动态编译，这是应用更灵便的 JSX 语法的 react 做不到的。

在 react fiber 呈现之前，react 也提供了 PureComponent、shouldComponentUpdate、useMemo,useCallback 等办法给咱们，来申明哪些是不须要连带更新子组件。

回到结尾的几个问题，答案不难在文中找到：

react 因为先天的有余——无奈准确更新，所以须要 react fiber 把组件渲染工作切片；而 vue 基于数据劫持，更新粒度很小，没有这个压力；
react fiber 这种数据结构使得节点能够回溯到其父节点，只有保留下中断的节点索引，就能够复原之前的工作进度；

如果这篇文章对你有帮忙，给我点个赞呗～这对我很重要

（点个在看更好！>3<）

关于前端:阿里三面灵魂一击有react-fiber为什么不需要vue-fiber呢

什么是响应式

react、vue 的响应式原理

不同响应式原理的影响

fiber 是什么

fiber 是一种新的数据结构

fiber 是纤程

react fiber 带来的变动

react 不如 vue？

结语