未来十年的技能
|
上层实现 现在，我们可以说：
那么基于该架构之上可以实现哪些有意思的功能?我们举几个例子： batchedUpdates 如果我们在一次事件回调中触发多次更新，他们会被合并为一次更新进行处理。
如下代码执行只会触发一次更新： 这样浏览器就有剩余时间执行样式布局和样式绘制，减少掉帧的可能性。 Fiber架构配合Scheduler实现了Concurrent Mode的底层刚需 —— “异步可中断的更新”。 架构运行策略 —— lane模型 到目前为止，通过Scheduler，React可以控制更新在Fiber架构中运行/中断/继续运行。 基于当前的架构，当一次更新在运行过程中被中断，过段时间再继续运行，这就是“异步可中断的更新”。 当一次更新在运行过程中被中断，转而重新开始一次新的更新，我们可以说：后一次更新打断了前一次更新。 这就是优先级的概念：后一次更新的优先级更高，他打断了正在进行的前一次更新。 多个优先级之间如何互相打断?优先级能否升降?本次更新应该赋予什么优先级? 这就需要一个模型控制不同优先级之间的关系与行为，于是lane模型诞生了。
你能感受到两者体验上的区别么?
事实上，点击“通用”后的交互是同步的，直接显示后续界面。 而点击“Siri与搜索”后的交互是异步的，需要等待请求返回后再显示后续界面。 但从用户感知来看，这两者的区别微乎其微。 这里的窍门在于：点击“Siri与搜索”后，先在当前页面停留了一小段时间，这一小段时间被用来请求数据。 当“这一小段时间”足够短时，用户是无感知的。如果请求时间超过一个范围，再显示loading的效果。 试想如果我们一点击“Siri与搜索”就显示loading效果，即使数据请求时间很短，loading效果一闪而过。用户也是可以感知到的。 为此，React实现了Suspense[4]、useDeferredValue[5]。 在源码内部，为了支持这些特性，同样需要将同步的更新变为可中断的异步更新。 Concurrent Mode自底向上 底层基础决定了上层API的实现，接下来让我们了解下，Concurrent Mode自底向上都包含哪些组成部分，才能实现上文提到的功能。 底层架构 —— Fiber架构 从上文我们了解到，为了解决CPU、IO瓶颈，最关键的一点是：实现异步可中断的更新。 基于这个前提，React花费2年时间重构完成了Fiber架构。 Fiber机构的意义在于，他将单个组件作为工作单元，使以组件为粒度的“异步可中断的更新”成为可能。 架构的驱动力 —— Scheduler 如果我们同步运行Fiber架构(通过ReactDOM.render)，则Fiber架构与重构前并无区别。 但是当我们配合时间切片，就能根据宿主环境性能，为每个工作单元分配一个可运行时间，实现“异步可中断的更新”。 于是，scheduler[6](调度器)产生了。 Scheduler能保证我们的长任务被拆分到每一帧不同的task中。
当我们为上文讲到的渲染3000个li的Demo开启Concurrent Mode： （编辑：济宁站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
