react历次版本迭代重要想办理的是两类导致网页卡顿的题目，分别是cpu麋集型任务和io麋集型任务导致的卡顿题目，react18提出的并发特性(Concurrent Rendering)就是为了办理上述题目。
Concurrent Rendering
什么是concurrent
简单体验一下
concurrent不算是个奇怪概念，react很早之前就开始为其铺路，早在v16/v17就引入了fiber架构和实行性的concurrent Mode，开启后整个应用会开启并发更新模式，但这将带来较大的breaking changes。因此react18提出了Concurrent Rendering的概念，即没有并发模式，只有并发特性，也就是说并发特性只是个可选项。默认情况下整个应用仍利用同步更新（legacy模式），在利用了并发特性后相干的更新再开启并发更新，不消的话就没有breaking changes。
concurrent带来的变动可以概括为以下两点：
时间分片
该模式下当更新任务的render过程无法在欣赏器的一帧内完成时，会被分为多个task举行可中断的更新，以此来包管欣赏器每一帧都有空余时间举行绘制，可以说时间分片是concurrent的实现根本。
更新优先级
该模式下更新任务会带有优先级，低优先级任务的实行将让位于高优先级任务。
这句话有两层寄义，反面会有详细示例分析
- 同一上下文中的高优先级任务将优先实行
- 差异上下文中的高优先级任务将打断正在实行的低优先级任务
什么是优先级
legacy模式下没有优先级的概念，因此全部任务都是同步实行。而开启并发特性后齐备活动的根本就是任务的优先级。
在react应用中我们大概在差异上下文中触发setState，如点击/输入变乱，异步接口回调，react18中也大概在concurrentAPI中触发等等。在react18中差异上下文中触发的setState的优先级是不一样的。react利用lane模子来形貌优先级，该模子利用31位二进制来表示优先级, 位数越小（值越小）则优先级越高。
以下是项目中最常见的几类任务的优先级
// 离散变乱优先级，比方：点击变乱，input输入，focus等触发的更新任务，优先级最高export const DiscreteEventPriority: EventPriority = SyncLane;// 一连变乱优先级，比方：滚动变乱，拖动变乱等export const ContinuousEventPriority: EventPriority = InputContinuousLane;// 默认变乱优先级，比方：异步接口回调中触发的更新任务export const DefaultEventPriority: EventPriority = DefaultLane;渲染模式对比
连合performance对比下legacy与conurrent这两种渲染模式
Legacy Mode
所谓legacy模式，即传统的react渲染模式，我们利用reactDOM.render创建的react应用都是利用这种模式，下面以一个demo为例分析。
渲染模式对比示例demo 在demo中用一个定时器延伸1000ms模拟接口哀求，另一个定时器延伸1040ms模拟触发一次点击变乱，可以显着看到列表渲染和点击变乱的更新结果先后展示在视图中，分析：
可以看到列表哀求触发的更新和点击变乱触发的更新先后举行render，而列表更新的整个过程处于一个宏任务中且耗时200多ms，欣赏器每16ms革新一次，因此导致render的过程中欣赏器的每一帧都没偶然间绘制，反应到真实场景中将使得用户感到点击操纵卡顿。
总结：legacy模式下的全部更新都是同步调治，没有优先级之分。
legacy下的更新调治流程
Concurrent Rendering
将上述demo开启并发特性观察结果，可以看到固然点击变乱在时序上是后触发的，但其更新结果却优先提交到了视图。分析：
留意到点击变乱触发时已经处于接口数据的render过程中，随后点击变乱触发的更新打断了正在举行的render而优先实行，提交到视图后继续举行接口数据的render。
总结：
- 开启并发特性后更新任务将带有优先级，click变乱的更新优先级高于接口哀求的更新优先级，因而前者会打断后者的render过程优先实行。
- 当更新的render流程过于耗时而高出欣赏器一帧的时间时，更新任务将被分割为多个task举行可中断的更新，每个task的实行时间不高出16ms（time slice）。这使得欣赏器的每一帧中有空余时间举行绘制，点击变乱的更新可以优先出现到视图中。
- 渲染阶段（commit）是不可被打断的。
并发模式带来的上风是显然易见的，他使得欣赏器在任何情况下都有空余时间绘制，使得在差异性能的装备上告急任务都能优先render并提交到视图。
concurrent下的更新调治流程图
怎样开启Concurrent Rendering
react18提供了新的根结点创建方式：ReactDOM.createRoot()。利用此API创建的react应用将启用react18全部新特性。
import React from 'react';// 留意这里ReactDOM是从client引入import ReactDOM from 'react-dom/client';import App from './contest';ReactDOM.createRoot(document.getElementById('root')).render(<App />);出于兼容性思量，传统的ReactDOM.renderAPI也会继续保存，利用ReactDOM.render创建的react18应用的体现与react17完全一致。
Concurrent Render API
下面是react18新引入的用于开启并发特性的API，只有用到这些API时才会开启并发更新。
startTransition
这是react18新引入的一个API，它答应我们以一个过渡优先级（ TransitionLane）来调治一次更新。可以称这类更新为过渡任务。过渡任务拥有较低的优先级，它带来的影响可以从以下两方面分析：
1.过渡任务的实行过程将开启时间分片
开启时间分片后，当任务耗时过长时可以包管每一帧都能空出时间交给欣赏器绘制，使得试图不卡顿。
Time Slice示例demo
2.过渡任务的由于优先级较低，因此将让位于其他高优先级任务。
高优先级任务优先实行示例demo
以下称setA(20000)为任务A，setB(1)为任务B
对于任务A，当我们不消startTransition调治时，可以显着看出a b以及列表是同时展示出来的，这是由于effect中的两次更新由于优先级一致因此被归并更新，同步实行。当利用startTransition调治时显着看到b优先变为1，这是由于任务A优先级低于任务B，因此优先实行任务B。即同一上下文中高优先级任务将优先实行。
与setTimeout的区别
上述demo看起来似乎用setTimeout也能到达雷同结果，究竟上此API与setTimeout最紧张的区别是处于transtions状态的任务是可以中断渲染的，是可以被高优先级任务打断的。对于渲染并发的场景下，setTimeout 仍然会使页面卡顿，由于超时后，setTimeout 的任务还是会实行且不可被打断，仍然会壅闭页面交互。
将demo改造下，startTransition改为setTimeout，并在200ms后模拟触发一次点击变乱（任务C）。由于点击变乱处于setTimeout中因此在任务队列中它会排在任务A之后，而列表的渲染时间显着多于200ms，因此当任务C实行时肯定还处于任务A的render过程中。而我们可以看到任务C的更新结果末了展示的，这也印证了setTimeout中的更新任务一旦开始就是不可被打断的。
末了将任务A还原为startTransition调治，可以看到任务B，任务C先后提交，任务A末了提交。我们知道点击变乱的优先级高于过渡优先级，因此任务C可以打断任务A的render过程优先实行，这实在就是范例的高优先级任务打断低优先级任务的实行。
与节省防抖的区别
节省防抖办理的是也是频仍触发渲染的题目，但是还是会存在一些题目。好比100ms防抖，当列表渲染非常快时，远远小于100ms，但是却必要等候到100ms后才会开始实行更新。而节省则无法办理更新耗时过长的题目。好比列表渲染必要耗时1s，那么在这1s内用户仍旧无法举行交互，实在与setTimeout的题目是雷同的，而trasntions任务在过渡期间理论上是可以多次被高优先级任务打断的。
useTransition
startTransition可以调治一个过渡任务，过渡任务有一个过渡期，可以以为过渡任务的更新在被提交到视图之前都属于过渡期，而用户无法感知当前是否处于过渡期。为了办理这个题目，React 提供了一个带有 isPending 状态的 hook：useTransition 。useTransition 实行后返回一个数组，数组有两个状态值：
- 当处于过渡状态的标记—isPending。
- startTransition，可以把内里的更新任务酿成过渡任务，等同于与上述的startTransitionAPI。
import { useTransition } from 'react' const [ isPending , startTransition ] = useTransition ()那么当任务处于过渡状态的时，isPending 为 true，可以作为用户等候的 UI 出现。好比：
{ isPending && <Spinner/> }useTransition示例demo
useDefferedValue
useDeferredValue 的实现结果也雷同于startTransition。
const [a, setA] = useState(0);const deferredA = useDeferredValue(a);useDeferredValue实质上是基于原始state生产一个新的state（DeferredValue），当对原始state举行setState时，DeferredValue的值会通过过渡任务得到，因此视图中利用DeferredValue就会得到和startTransitionAPI一样的结果，究竟上这两个API相称于从两个角度实现过渡任务，本质上是一样的。
useDeferredValue示例demo
其他变动
Automatic Batching
legacy模式下，除合成变乱&生命周期外，在其他的变乱回调中（异步方法，原生变乱等）的多次setState不会批量处置惩罚，即每次setState都会render一次。
legacy模式下的batchUpdate示例demo
每次setState后我们可以通过ref拿到最新的dom属性，在legacy模式下可以利用ReactDom.unstable_batchedUpdates欺压批量更新，而在react18应用中任何变乱回调中的多次setState都会归并处置惩罚。
Automatic Batching示例demo
这是由于新版batchedUpdate的实现基于更新优先级，只要更新的优先级一致那么更新将归并。
flushSync
特殊情况必要立刻获取更新结果时可以利用react18新提供的flushSync。
transitions与Suspense配合办理io瓶颈（不稳固）
Suspense 是 React 提供的一种异步处置惩罚机制，在v16/v17中，Suspense重要是配合React.lazy举行组件层面的code spliting，而未来react渴望徐徐将Suspense用于全部的异步操纵场景，现在已有相干API/库举行支持。
Suspense处置惩罚异步操纵示例demo
demo中险些看不到异步代码，完全用同步的思维获取接口数据且不会用带async/await这种语法糖。我们以为数据是已经存在的，我们做的只是读数据而非拉数据。
上述demo的实行流程如下：
- 首次调用userResource.read，会创建一个promise（即fetchUser的返回值）。
- 由于是同步调用因此取不到数据，此时userResource中会将这个promise throw出去。
- React内部会catch这个promise（handleEfrror），离User组件近来的先人Suspense组件渲染fallback
renderRootConcurrent
// renderRootConcurrentdo { try { workLoopConcurrent(); break; } catch (thrownValue) { handleError(root, thrownValue); } } while (true);
- promsie resolve或reject时重新触发一次调治，此时再调用userResource.read会返回resolve/reject的结果（即fetchUser哀求的数据），利用该数据继续render
这里关键是userResource的实现，现在react有一个专门提供createReouceAPI的库react-cache，但现在还处于实行阶段无法用于生产情况，下面简单分析下实现原理。
const cache = {};export function createResource(fetch) { const resource = { read: params => { // 这里临时用id做个缓存 react-cache内部有一套单独的缓存清理算法 if (!cache[params]) { const promise = fetch(params); let suspender = promise.then( r => { cache[params].status = 'resolved'; cache[params].result = r; }, e => { cache[params].status = 'rejected'; cache[params].result = e; } ); cache[params] = { promise: suspender, status: 'pending', result: null, }; throw suspender; } else { if (cache[params].status === 'resolved') { return cache[params].result; } throw cache[params].promise; } }, }; return resource;}react18新增的concurrentAPI可以配合suspense利用，当startTranstion调治的更新任务触发恣意一个suspense组件挂起时，将导致当前组件进入pending状态，此时只要关联了suspense的变动就会被‘停息’提交，直到在内存中构建完成后才会被会提交。此特性一样寻常用于接口返回较快且有loading的页面，可以在制止闪耀题目的同时，使得在视图切换前仍然可以保持相应。
github交互示例
将上述demo改造下
transitions+Suspense处置惩罚异步示例demo
现在suspense处置惩罚异步场景相干的库尚不稳固，推测此特性反面大概由路由库集成并袒露相干api给用户。
移除inUnmount告诫
一样寻常开发中常常遇到这个告诫，它的本意是制止由于未及时清理effect hook中的订阅而导致的内存走漏题目
useEffect(() => { function handleChange() { setState(store.getState()); } store.subscribe(handleChange); return () => store.unsubscribe(handleChange);}, []);但一样寻常开发中更多的告诫场景是在已卸载的组件中举行setState
async function handleSubmit() { setLoading(true); // 在我们等候时组件大概会卸载 await post('/some-api'); setLoading(false);}现实上这里并没有现实的内存走漏，promise在resolve之后就会被接纳。对于这种告诫我们一样寻常的实践是手动判断isUnmount，但这现实上只是克制了告诫，并没有办理实诘责题且会增长代码复杂度，因此是没有须要的。react此次更新旨在剔除业务代码中全部的isUnmount判断。
组件卸载后setState会不会有其他副作用？
react触发的任何更新最终都通过scheduleUpdateOnFiber举行调治，当触发更新所在组件已卸载时不继续举行调治流程，因此不会产生其他副作用。
// scheduleUpdateOnFiber // 当内部获取不到根fiber节点时就不再继续调治更新 const root = markUpdateLaneFromFiberToRoot(fiber, lane); if (root === null) { return null; }markUpdateLaneFromFiberToRoot
function markUpdateLaneFromFiberToRoot(){ let node = sourceFiber; // fiber.return代表父节点，若当前fiber对应dom已卸载则fiber.return为null let parent = sourceFiber.return; while (parent !== null) { // 方法内部会向上遍历到根fiber节点 } // 当遍历结果不是根fiber时会返回null if (node.tag === HostRoot) { const root: FiberRoot = node.stateNode; return root; } else { return null; }}答应组件返回undefined
React 17 中如果组件在 render 中返回了 undefined，React 会在运行时抛错。
用于三方库的API
以下API一样寻常用于三方库的开发，通常不会用于现实业务开发当中。
useInsertionEffect
这个Hook实行机遇在 DOM 天生之后，useLayoutEffect实行之前，此时无法访问DOM节点的引用。一样寻常用于办理 CSS-in-JS 库在渲染中动态注入样式的性能题目。
useSyncExternalStore
此API一样寻常用于第三方状态管理库如redux/mobx，它们在控制状态时大概并非直接利用react的 state，而是本身在外部维护了一个store对象，脱离了react的管理，此时若利用concurrentAPI则大概出现兼容性题目，useExternalStore就是为了办理这种题目，根本实现原理是将render过程欺压变为同步的不可中断的更新。
SSR
更多信息可见Upgrading to React 18 on the server、New Suspense SSR Architecture in React 18
升级指南
官方升级指南
收益点
理论上任何由cpu麋集型任务导致的卡顿题目都可以思量是否可用并发特性优化。
兼容性
只要不消concurrentAPI那么体现将与旧版本一致。
redux/mobx兼容性
正常用没题目（同步更新），但不能利用concurrentAPI调治store的更新操纵。
startTransition调治mobx更新示例demo
更新开始后，有 10 个 ShowText 节点必要render， 每个节点render时必要耗时 20ms 以上，这就导致每个 ShowText render竣事以后都必要中断让出主线程。在和谐中断时，修改 store 状态，后续的 ShowText 节点在恢复 render 时，会利用修改以后的 store 状态导致末了出现状态不一致的情况，因此在现实业务中非常情况下大概会出题目。
这是由于demo中脱离react state而在外部单独维护数据源，而concurrent是react内部状态的处置惩罚机制，因此外部数据是无法处置惩罚更新中断的题目（内容扯破题目），redux中体现也是云云，不外最新的react-redux8.0.0中已经利用useSyncExternalStoreAPI办理了此题目。
多次render带来的影响
不安全生命周期
在高优先级打断低优先级的case中，低优先级任务究竟上render了两次，而
componentWillReceiveProps、componentWillMount、componentWillUpdate 这几个生命周期钩子都是在render时触发的，方法内部都可以修改state，当组件重复render时，不合法的操纵会引来额外的副作用，因此react将这几个生命周期方法界说为 unsafe_xxxxx，在并发模式下大概有题目，现在项目中没有用到这几个钩子。
饥饿题目
低优先级任务的render过程多次被高优先级任务打断而得不到实行的征象称为饥饿题目。react通过逾期时间来办理饥饿题目，差异优先级对应差异的逾期时间。当低优先级任务不绝未实行而高出期期时间时该任务会被视为逾期任务，其优先级会被提升为同步优先级，会立刻实行。
饥饿题目示例demo
重复render题目
由于这种case只有在利用concurrentAPI时才有大概出现，因此在开启concurrent时需确认组件中是否有在effect之外处置惩罚的特殊逻辑，即组件每次render都会实行的逻辑。
高优先级打断低优先级任务导致组件重复render示例demo
关于batchUpdates
必要清除项目中是否存在强行在两次setState中立刻取值的case，react18中此场景必要连合flushSync利用
不支持IE11
Concurrent模式下的任务调治流程
末了简单分析下concurrentMode下的任务更新调治流程。
concurrentMode下的任务更新可以概括为异步可中断的更新，这种基于更新任务的优先级来统筹调治的模式的架构根本是fiber tree，它使得render过程中可以中断。
function workLoopConcurrent() { // 当wip构造完成或时间切片用尽时克制工作 while (workInProgress !== null && !shouldYield()) { performUnitOfWork(workInProgress); }}workLoopConcurrent 都会判断本次和谐对应的优先级和上一次时间片到期中断的和谐的优先级是否一样。如果一样，分析没有更高优先级的更新产生，可以继续前次未完成的和谐；如果不一样，分析有更高优先级的更新进来，此时要清空之前已开始的和谐过程，从根节点开始重新和谐。等高优先级更新处置惩罚完成以后，再次从根节点开始处置惩罚低优先级更新。
而调治的核心逻辑则重要泉源于schduler模块，schduler是一个独立于react的专门用于任务调治的库。react应用每产生一个更新任务都会通过schduler模块袒露的API（scheduleCallback）来注册一个更新任务，此逻辑重要在ensureRootIsScheduled中完成：
function ensureRootIsScheduled(root: FiberRoot, currentTime: number) { // 得到当前正在调治的fiber节点 const existingCallbackNode = root.callbackNode; const nextLanes = getNextLanes( root, root === workInProgressRoot ? workInProgressRootRenderLanes : NoLanes, ); // 得到当前根fiber节点下最高优先级的lane const newCallbackPriority = returnNextLanesPriority(); if (nextLanes === NoLanes) { return; } if (existingCallbackNode !== null) { // 当本次调治的优先级与正在调治的优先级一致时则不继续调治 auto batch const existingCallbackPriority = root.callbackPriority; if (existingCallbackPriority === newCallbackPriority) { return; } // 若不一致，分析本次的调治优先级肯定高于正在调治的优先级，取消当前的调治 cancelCallback(existingCallbackNode); } // 注册调治任务 let newCallbackNode; if (newCallbackPriority === SyncLanePriority) { // 同步优先级 举行同步调治 将在本轮变乱循环同步实行 newCallbackNode = scheduleSyncCallback( performSyncWorkOnRoot.bind(null, root), ); } else if (newCallbackPriority === SyncBatchedLanePriority) { newCallbackNode = scheduleCallback( ImmediateSchedulerPriority, performSyncWorkOnRoot.bind(null, root), ); } else { const schedulerPriorityLevel = lanePriorityToSchedulerPriority( newCallbackPriority, ); // 非同步优先级，利用schduler举行异步调治 newCallbackNode = scheduleCallback( schedulerPriorityLevel, performConcurrentWorkOnRoot.bind(null, root), ); } // 更新标记 root.callbackPriority = newCallbackPriority; root.callbackNode = newCallbackNode;}schduler内部维护一个队列（taskQueue）来管理全部被调治的任务，通过messageChannel来实现异步调治，此过程在unstable_scheduleCallback中完成。每次调治都会从taskQueue中取出最高优先级的任务实行，实行过程中大概由于切片用尽或任务队列已清空而中断，再次回到队列消费的逻辑。此过程在workLoop中完成。 |
