⚡ 30 秒速记
- 当前树代表已提交内容，工作树计算下一版
- 优先级决定哪些更新先处理
- 工作单元之间可以让出并重新调度
- 渲染中断不把半完成结果交给页面
- 过渡更新区分紧急输入与昂贵展示
并发渲染是让多种更新在时间上交错安排，而不是让多个线程同时改页面。 当前树继续支撑已显示内容，工作树计算候选结果，调度器根据优先级决定继续、让出或重做。输入等紧急工作因此有机会先被处理，完成后再提交一致结果。实际应用要区分哪些状态必须立即反馈、哪些展示可以稍后更新，同时保持渲染纯净，避免重复计算带来外部副作用。
版本校准： 原理文章中的代码代表特定实现与写作时间。应用到当前项目时，应先确认浏览器、框架或工具的主版本，再区分稳定的规范语义、可变化的内部实现和项目自身约束。
通过对整个 ReactDOM.render 所触发的渲染链路进行了分析和串联，我们已经把 Fiber 架构在实现层面的大部分要点都过了一遍。刚讲过的这部分知识，一方面相对来说复杂度比较高，需要一些耐心反复地理解和消化；另一方面，本讲接下来要讲解的内容，也和它存在着较强的依赖关系，因此对这些前置知识的把握就显得尤为重要。
下面我说几个函数，帮你检验一下自己的学习效果：
performSyncWorkOnRootworkLoopSyncperformUnitOfWorkbeginWorkcompleteWorkcompleteUnitOfWorkreconcileChildFibers
本讲我将带你去认识 Fiber 架构最迷人的那一面——Concurrent 模式（异步渲染）下的“时间切片”和“优先级”实现。
# current 树 与 workInProgress 树：“双缓冲”模式在 Fiber 架构下的实现
# 什么是“双缓冲”模式
“双缓冲”模式其实是一种在游戏领域由来已久的经典设计模式。为了帮助你快速理解它，这里我先举一个生活中的例子：假如你去看一场总时长只有 1 个小时的话剧，这场话剧中场不休息，需要不间断地演出。
按照剧情的需求，半个小时处需要一次转场。所谓转场，就是说话剧舞台的灯光、布景、氛围等全部要切换到另一种风格里去。在不中断演出的情况下，想要实现转场，怎么办呢？场务工作做得再快，也要十几二十分钟，这对一场时长 1 小时的话剧来说，实在太漫长了。观众也无法接受这样的剧情“卡顿”体验。
有一种解法，那就是准备两个舞台来做这场戏，当第一个舞台处于使用中时，第二个舞台的布局已经完成。这样当第一个舞台的表演结束时，只需要把第一个舞台的灯光灭掉，第二个舞台的灯光亮起，就可以做到剧情的无缝衔接了。
事实上，在真实的话剧中，我们也确实常常看到这样的画面——演员从舞台的左侧走到了右侧，灯光一切换，就从卧室（左侧舞台）走到了公园（右侧舞台）；又从公园（右侧舞台）走到了办公室（左侧舞台）。左侧舞台的布景从卧室变成了办公室，这个过程正是在演员利用右侧舞台表演时完成的。
