共计 8795 个字符,预计需要花费 22 分钟才能阅读完成。
render 阶段的入口
render 阶段的次要工作是构建 Fiber 树和生成 effectList,在第 5 章中咱们晓得了 react 入口的两种模式会进入 performSyncWorkOnRoot 或者 performConcurrentWorkOnRoot,而这两个办法别离会调用 workLoopSync 或者 workLoopConcurrent
//ReactFiberWorkLoop.old.js
function workLoopSync() {while (workInProgress !== null) {performUnitOfWork(workInProgress);
}
}
function workLoopConcurrent() {while (workInProgress !== null && !shouldYield()) {performUnitOfWork(workInProgress);
}
}
这两函数的区别是判断条件是否存在 shouldYield 的执行,如果浏览器没有足够的工夫,那么会终止 while 循环,也不会执行前面的 performUnitOfWork 函数,天然也不会执行前面的 render 阶段和 commit 阶段,这部分属于 scheduler 的知识点,咱们在第 15 章解说。
- workInProgress:新创建的 workInProgress fiber
- performUnitOfWork:workInProgress fiber 和会和曾经创立的 Fiber 连接起来造成 Fiber 树。这个过程相似深度优先遍历,咱们暂且称它们为‘捕捉阶段’和‘冒泡阶段’。伪代码执行的过程大略如下
function performUnitOfWork(fiber) {if (fiber.child) {performUnitOfWork(fiber.child);//beginWork
}
if (fiber.sibling) {performUnitOfWork(fiber.sibling);//completeWork
}
}
render 阶段整体执行流程
用 demo_0 看视频调试
- 捕捉阶段
从根节点 rootFiber 开始,遍历到叶子节点,每次遍历到的节点都会执行 beginWork,并且传入以后 Fiber 节点,而后创立或复用它的子 Fiber 节点,并赋值给 workInProgress.child。 - 冒泡阶段
在捕捉阶段遍历到子节点之后,会执行 completeWork 办法,执行实现之后会判断此节点的兄弟节点存不存在,如果存在就会为兄弟节点执行 completeWork,当全副兄弟节点执行完之后,会向上‘冒泡’到父节点执行 completeWork,直到 rootFiber。 - 示例,demo_0 调试
function App() {
return (
<>
<h1>
<p>count</p> xiaochen
</h1>
</>
)
}
ReactDOM.render(<App />, document.getElementById("root"));
当执行完深度优先遍历之后造成的 Fiber 树:
图中的数字是遍历过程中的程序,能够看到,遍历的过程中会从利用的根节点 rootFiber 开始,顺次执行 beginWork 和 completeWork,最初造成一颗 Fiber 树,每个节点以 child 和 return 相连。
留神:当遍历到只有一个子文本节点的 Fiber 时,该 Fiber 节点的子节点不会执行 beginWork 和 completeWork,如图中的‘chen’文本节点。这是 react 的一种优化伎俩
beginWork
beginWork 次要的工作是创立或复用子 fiber 节点
function beginWork(
current: Fiber | null,// 以后存在于 dom 树中对应的 Fiber 树
workInProgress: Fiber,// 正在构建的 Fiber 树
renderLanes: Lanes,// 第 12 章在讲
): Fiber | null {
// 1.update 时满足条件即可复用 current fiber 进入 bailoutOnAlreadyFinishedWork 函数
if (current !== null) {
const oldProps = current.memoizedProps;
const newProps = workInProgress.pendingProps;
if (
oldProps !== newProps ||
hasLegacyContextChanged() ||
(__DEV__ ? workInProgress.type !== current.type : false)
) {didReceiveUpdate = true;} else if (!includesSomeLane(renderLanes, updateLanes)) {
didReceiveUpdate = false;
switch (workInProgress.tag) {// ...}
return bailoutOnAlreadyFinishedWork(
current,
workInProgress,
renderLanes,
);
} else {didReceiveUpdate = false;}
} else {didReceiveUpdate = false;}
//2. 依据 tag 来创立不同的 fiber 最初进入 reconcileChildren 函数
switch (workInProgress.tag) {
case IndeterminateComponent:
// ...
case LazyComponent:
// ...
case FunctionComponent:
// ...
case ClassComponent:
// ...
case HostRoot:
// ...
case HostComponent:
// ...
case HostText:
// ...
}
}
相干参考视频解说:进入学习
从代码中能够看到参数中有 current Fiber,也就是以后实在 dom 对应的 Fiber 树,在之前介绍 Fiber 双缓存机制中,咱们晓得在首次渲染时除了 rootFiber 外,current 等于 null,因为首次渲染 dom 还没构建进去,在 update 时 current 不等于 null,因为 update 时 dom 树曾经存在了,所以 beginWork 函数中用 current === null 来判断是 mount 还是 update 进入不同的逻辑
- mount:依据 fiber.tag 进入不同 fiber 的创立函数,最初都会调用到 reconcileChildren 创立子 Fiber
-
update:在构建 workInProgress 的时候,当满足条件时,会复用 current Fiber 来进行优化,也就是进入 bailoutOnAlreadyFinishedWork 的逻辑,能复用 didReceiveUpdate 变量是 false,复用的条件是
- oldProps === newProps && workInProgress.type === current.type 属性和 fiber 的 type 不变
- !includesSomeLane(renderLanes, updateLanes) 更新的优先级是否足够,第 15 章解说
reconcileChildren/mountChildFibers
创立子 fiber 的过程会进入 reconcileChildren,该函数的作用是为 workInProgress fiber 节点生成它的 child fiber 即 workInProgress.child。而后持续深度优先遍历它的子节点执行雷同的操作。
//ReactFiberBeginWork.old.js
export function reconcileChildren(
current: Fiber | null,
workInProgress: Fiber,
nextChildren: any,
renderLanes: Lanes
) {if (current === null) {
//mount 时
workInProgress.child = mountChildFibers(
workInProgress,
null,
nextChildren,
renderLanes,
);
} else {
//update
workInProgress.child = reconcileChildFibers(
workInProgress,
current.child,
nextChildren,
renderLanes,
);
}
}
reconcileChildren 会辨别 mount 和 update 两种状况,进入 reconcileChildFibers 或 mountChildFibers,reconcileChildFibers 和 mountChildFibers 最终其实就是 ChildReconciler 传递不同的参数返回的函数,这个参数用来示意是否追踪副作用,在 ChildReconciler 中用 shouldTrackSideEffects 来判断是否为对应的节点打上 effectTag,例如如果一个节点须要进行插入操作,须要满足两个条件:
- fiber.stateNode!==null 即 fiber 存在实在 dom,实在 dom 保留在 stateNode 上
- (fiber.effectTag & Placement) !== 0 fiber 存在 Placement 的 effectTag
var reconcileChildFibers = ChildReconciler(true);
var mountChildFibers = ChildReconciler(false);
function ChildReconciler(shouldTrackSideEffects) {function placeChild(newFiber, lastPlacedIndex, newIndex) {
newFiber.index = newIndex;
if (!shouldTrackSideEffects) {// 是否追踪副作用
// Noop.
return lastPlacedIndex;
}
var current = newFiber.alternate;
if (current !== null) {
var oldIndex = current.index;
if (oldIndex < lastPlacedIndex) {
// This is a move.
newFiber.flags = Placement;
return lastPlacedIndex;
} else {
// This item can stay in place.
return oldIndex;
}
} else {
// This is an insertion.
newFiber.flags = Placement;
return lastPlacedIndex;
}
}
}
在之前心智模型的介绍中,咱们晓得为 Fiber 打上 effectTag 之后在 commit 阶段会被执行对应 dom 的增删改,而且在 reconcileChildren 的时候,rootFiber 是存在 alternate 的,即 rootFiber 存在对应的 current Fiber,所以 rootFiber 会走 reconcileChildFibers 的逻辑,所以 shouldTrackSideEffects 等于 true 会追踪副作用,最初为 rootFiber 打上 Placement 的 effectTag,而后将 dom 一次性插入,进步性能。
export const NoFlags = /* */ 0b0000000000000000000;
// 插入 dom
export const Placement = /* */ 0b00000000000010;
在源码的 ReactFiberFlags.js 文件中,用二进制位运算来判断是否存在 Placement, 例如让 var a = NoFlags, 如果须要在 a 上减少 Placement 的 effectTag,就只有 effectTag | Placement 就能够了
bailoutOnAlreadyFinishedWork
//ReactFiberBeginWork.old.js
function bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes) {
//...
if (!includesSomeLane(renderLanes, workInProgress.childLanes)) {return null;} else {cloneChildFibers(current, workInProgress);
return workInProgress.child;
}
}
如果进入了 bailoutOnAlreadyFinishedWork 复用的逻辑,会判断优先级第 12 章介绍,优先级足够则进入 cloneChildFibers 否则返回 null
completeWork
completeWork 次要工作是解决 fiber 的 props、创立 dom、创立 effectList
//ReactFiberCompleteWork.old.js
function completeWork(
current: Fiber | null,
workInProgress: Fiber,
renderLanes: Lanes,
): Fiber | null {
const newProps = workInProgress.pendingProps;
// 依据 workInProgress.tag 进入不同逻辑,这里咱们关注 HostComponent,HostComponent,其余类型之后在讲
switch (workInProgress.tag) {
case IndeterminateComponent:
case LazyComponent:
case SimpleMemoComponent:
case HostRoot:
//...
case HostComponent: {popHostContext(workInProgress);
const rootContainerInstance = getRootHostContainer();
const type = workInProgress.type;
if (current !== null && workInProgress.stateNode != null) {
// update 时
updateHostComponent(
current,
workInProgress,
type,
newProps,
rootContainerInstance,
);
} else {
// mount 时
const currentHostContext = getHostContext();
// 创立 fiber 对应的 dom 节点
const instance = createInstance(
type,
newProps,
rootContainerInstance,
currentHostContext,
workInProgress,
);
// 将后辈 dom 节点插入刚创立的 dom 里
appendAllChildren(instance, workInProgress, false, false);
// dom 节点赋值给 fiber.stateNode
workInProgress.stateNode = instance;
// 解决 props 和 updateHostComponent 相似
if (
finalizeInitialChildren(
instance,
type,
newProps,
rootContainerInstance,
currentHostContext,
)
) {markUpdate(workInProgress);
}
}
return null;
}
从简化版的 completeWork 中能够看到,这个函数做了一下几件事
- 依据 workInProgress.tag 进入不同函数,咱们以 HostComponent 举例
- update 时(除了判断 current===null 外还须要判断 workInProgress.stateNode===null),调用 updateHostComponent 解决 props(包含 onClick、style、children …),并将解决好的 props 赋值给 updatePayload, 最初会保留在 workInProgress.updateQueue 上
- mount 时 调用 createInstance 创立 dom,将后辈 dom 节点插入刚创立的 dom 中,调用 finalizeInitialChildren 解决 props(和 updateHostComponent 解决的逻辑相似)
之前咱们有说到在 beginWork 的 mount 时,rootFiber 存在对应的 current,所以他会执行 mountChildFibers 打上 Placement 的 effectTag,在冒泡阶段也就是执行 completeWork 时,咱们将子孙节点通过 appendAllChildren 挂载到新创建的 dom 节点上,最初就能够一次性将内存中的节点用 dom 原生办法反馈到实在 dom 中。
在 beginWork 中咱们晓得有的节点被打上了 effectTag 的标记,有的没有,而在 commit 阶段时要遍历所有蕴含 effectTag 的 Fiber 来执行对应的增删改,那咱们还须要从 Fiber 树中找到这些带 effectTag 的节点嘛,答案是不须要的,这里是以空间换工夫,在执行 completeWork 的时候遇到了带 effectTag 的节点,会将这个节点退出一个叫 effectList 中, 所以在 commit 阶段只有遍历 effectList 就能够了(rootFiber.firstEffect.nextEffect 就能够拜访带 effectTag 的 Fiber 了)
effectList 的指针操作产生在 completeUnitOfWork 函数中,例如咱们的利用是这样的
function App() {const [count, setCount] = useState(0);
return (
<>
<h1
onClick={() => {setCount(() => count + 1);
}}
>
<p title={count}>{count}</p> xiaochen
</h1>
</>
)
}
那么咱们的操作 effectList 指针如下(这张图是操作指针过程中的图,此时遍历到了 app Fiber 节点,当遍历到 rootFiber 时,h1,p 节点会和 rootFiber 造成环状链表)
rootFiber.firstEffect===h1
rootFiber.firstEffect.next===p
造成环状链表的时候会从触发更新的节点向上合并 effectList 直到 rootFiber,这一过程产生在 completeUnitOfWork 函数中,整个函数的作用就是向上合并 effectList
//ReactFiberWorkLoop.old.js
function completeUnitOfWork(unitOfWork: Fiber): void {
let completedWork = unitOfWork;
do {
//...
if (
returnFiber !== null &&
(returnFiber.flags & Incomplete) === NoFlags
) {if (returnFiber.firstEffect === null) {returnFiber.firstEffect = completedWork.firstEffect;// 父节点的 effectList 头指针指向 completedWork 的 effectList 头指针}
if (completedWork.lastEffect !== null) {if (returnFiber.lastEffect !== null) {
// 父节点的 effectList 头尾指针指向 completedWork 的 effectList 头指针
returnFiber.lastEffect.nextEffect = completedWork.firstEffect;
}
// 父节拍板的 effectList 尾指针指向 completedWork 的 effectList 尾指针
returnFiber.lastEffect = completedWork.lastEffect;
}
const flags = completedWork.flags;
if (flags > PerformedWork) {if (returnFiber.lastEffect !== null) {
//completedWork 自身追加到 returnFiber 的 effectList 结尾
returnFiber.lastEffect.nextEffect = completedWork;
} else {
//returnFiber 的 effectList 头节点指向 completedWork
returnFiber.firstEffect = completedWork;
}
//returnFiber 的 effectList 尾节点指向 completedWork
returnFiber.lastEffect = completedWork;
}
}
} else {
//...
if (returnFiber !== null) {
returnFiber.firstEffect = returnFiber.lastEffect = null;// 重制 effectList
returnFiber.flags |= Incomplete;
}
}
} while (completedWork !== null);
//...
}
最初生成的 fiber 树如下
而后 commitRoot(root); 进入 commit 阶段