React16源码解析(一)- 图解Fiber架构
React源码解析系列文章欢迎阅读：
React16源码解析(一)- 图解Fiber架构
React16源码解析(二)-建立更新
React16源码解析(三)-ExpirationTime
React16源码解析(四)-Scheduler
React16源码解析(五)-更新流程渲染阶段1
React16源码解析(六)-更新流程渲染阶段2
React16源码解析(七)-更新流程渲染阶段3
React16源码解析(八)-更新流程提交阶段
正在更新中...react
老的react架构从setState到render完成，整个过程是主要霸占主线程的。若是组件比较大，或者有些复杂的逻辑，长时间占用主线程，会致使一些input框输入操做、动画等得不到响应，从而表现出页面卡顿。算法
为了解决上述的问题，React引入了一个全新的异步渲染架构：Fiber。segmentfault
概述
这是React 核心算法的一次大的更新，重写了 React 的 reconciliation 算法。reconciliation 算法是用来更新而且渲染DOM树的算法。之前React 15.x的版本使用的算法称为“stack reconciliation”，如今称为“fiber reconciler”。api
fiber reconciler主要的特色是能够把更新流程拆分红一个一个的小的单元进行更新，而且能够中断，转而去执行高优先级的任务或者浏览器的动画渲染等，等主线程空闲了再继续执行更新。数组
另外的新功能：
一、render方法能够返回多元素（便可以返回数组）
二、支持异常边界处理异常；浏览器
Fiber Tree
为了达到上述的效果，react将底层更新单元的数据结构改为了链表结构。之前的协调算法是递归调用，经过react dom 树级关系构成的栈递归。而fiber是扁平化的链表的数据存储结构，经过child找子节点，return找父节点，sibling找兄弟节点。遍历从递归改成循环。数据结构
具体的结构参照我下面画的图：
架构
建立上面的fiber树对应的代码：dom
import React from 'react';
import ReactDOM from 'react-dom'
class List extends React.Component {
render () {
return (
[1,2,3].map((item)=>{
return <span>span</span>
})
)
}
}
class App extends React.Component {
render () {
return (
[<button>按钮</button>,<List/>,<div>div</div>]
);
}
}
ReactDOM.render(
<App />,
document.getElementById("root")
)
构建Fiber Tree
第一次渲染的时候会构建好这颗fiber树。如下是构建这颗fiber树的过程。
建立过程和更新过程实际上是一个过程，能够说建立过程是更新过程的一个子集，至关于每一个节点的更新都是新建一个fiber节点。
其中粉色节点表明更新完成的节点，当全部的节点都变成粉色说明整棵fiber树都已经准备好了。能够提交到真实dom树上去了。异步
1
建立一个RootFiber节点
建立RootFiber节点过程的详细源码解析欢迎阅读：
React16源码解析(二)-建立更新
2
构建/更新fiber树过程详细源码解析欢迎阅读：
React16源码解析(五)-更新流程渲染阶段1
React16源码解析(六)-更新流程渲染阶段2
React16源码解析(七)-更新流程渲染阶段3
沿着子节点不断的建立fiber子节点，若是发现子节点是一个数组，会把子节点都建立好，以后拿到第一个子节点再往下走。
这里图中第一个子节点button它已经没有子节点了，这个时候就会把这个节点是否有更新计算出来，算好更新以后就往回走了。我就称这个节点构建完成了。
注：橘色节点只是建立好了fiber尚未完成。
3
由于3号节点(button)没有子节点了，因此咱们向它的兄弟节点出发了。到达4号节点，又会以一样的方式遍历子节点。
4
当4号节点的子节点都完成以后，回到4号节点，再完成4号节点，由于4号节点存在兄弟节点，因此再向兄弟节点出发。
5
到达5号节点以后，5号节点再以一样的方式遍历子节点。
6
9号节点完成以后，就会一层层返回到root节点。由于返回的路上已经没有兄弟节点了。直到root节点完成，这颗fiber树就已经渲染好了，接下来就能够提交渲染树到真实的dom树了。
更新Fiber Tree
假设我如今想要更新7号节点。
以下代码：
import React from 'react';
import ReactDOM from 'react-dom'
class List extends React.Component {
render () {
const { list } = this.props;
return (
list.map((item)=>{
return <span>{item}</span>
})
)
}
}
class App extends React.Component {
constructor() {
super();
this.state = {
list:[1,2,3]
}
}
clickButton = () => {
this.setState({
list:[1,4,3]
})
}
render () {
return (
[<button onClick={this.clickButton}>按钮</button>,<List list={this.state.list}/>,<div>div</div>]
);
}
}
ReactDOM.render(
<App />,
document.getElementById("root")
)
点击按钮就会更新7号节点的内容，将 2 -> 4。
1
当遍历到7号节点时候，发现7号节点是须要更新的，由于它身上有个叫effectTag的标志，值为4表示的是要更新本节点。这个节点须要更新因此把7号节点记录在父节点的firstEffect链表上。如图所示：
2
当遍历到4号节点的时候，由于它身上firstEffect不为空，因此它会把他身上的firstEffect接到父节点的身上。如图所示：
3
遍历到2号节点时，一样的道理：
其实这里firstEffect链表后面连接的7号是一直指向7号节点的指针。在提交阶段(提交到dom树上)直接遍历root节点上的firstEffect链表就能够了。由于这上面记录了那些节点有更新，只须要更新咱们标记好的节点就能够啦。
可中断
通过上述过程，可能你们会产生疑问，说好的可中断呢？怎么一个字也没提呢？？？
别急，我如今一句话就能讲清了：
上面个人图中，个人每个步骤（实际状况步骤更多，我没画那么细）是能够不连续占用主线程的。
react把更新这颗fiber树切分红了好多个任务，每完成一小块任务，就会看看如今主线程是否有空闲，有空闲的话就继续下一个小任务，没有空闲那就把主线程让给浏览器或者更高优先级任务。那么这颗fiber树的更新就会被停滞，获得主线程有空了，在继续渲染。
那么问题又来，我怎么知道主线程何时有空？何时没空？
这个时候咱们想起了requestIdleCallback这个原始api。可是~ react并无用上requestIdleCallback。主要仍是由于浏览器的兼容性问题。因此采用了polyfill方案。
详细源码解析欢迎阅读：
React16源码解析(四)-Scheduler
React16源码解析(三)-ExpirationTime
注意：上面我构建的fiber树只是一个虚拟的dom结构，这个fiber树所有更新好了以后，就会一次性的提交到真实的dom树上，这个一次性的提交是不能够中断的。
提交阶段的详细源码解析欢迎阅读：
React16源码解析(八)-更新流程提交阶段
文章若有不妥，欢迎指正~