今天我就用最基础的方式重新跟大家分享一下什么是任务可中断。
首先，我们要明确的一个前提，是一个完整的函数执行是不可以中断的。因此如果你把一整个任务全部都放到一个函数中来执行，那么想要做到任务可中断是不可能的。
例如，现在我有一个任务，往父级元素中插入 10 万个子节点 <span>1</span>，然后我们可以随便写这样一个函数来完成这个逻辑。
btn.onclick = () => { let i = 0 for (; i < 100000; i++) { let span = document.createElement('span') span.innerText = 1 container.appendChild(span) }}然后这个时候，我们就发现一个问题，当我们点击之后，页面上并不会立即显示插入的内容，而是会卡顿一会儿，才会显示。
原因是因为 10 万个节点的插入逻辑是一个同步的过程，JS 逻辑的执行时间过长导致了浏览器迟迟无法执行渲染。
那么为了优化这种情况，我们可以考虑将渲染 10 万个节点这个大的任务，拆分成 10 万个渲染 1 个节点的小任务。
function task() { let span = document.createElement('span') span.innerText = 1 container.appendChild(span)}并将这 10 万个任务，放进一个数组中。
const taskQueue = Array.from({ length: 100000 }, () => task)执行这 100 万个任务，就通过遍历 taskQueue 的方式来执行，这样，我们就可以通过中断队列遍历的方式，来中断任务的执行。
在浏览器中，渲染引擎在每一帧都有机会渲染页面，那么页面的表现就不会卡顿。但是刚才我们的情况是，JS 执行时间过长，导致渲染引擎一直没有机会渲染，所以用户感受到的就是卡顿。
那么解决这个问题的原理，就是根据浏览器渲染频率，对 JS 要执行的任务进行拆分，JS 执行一部分，然后渲染引擎渲染一部分，完成之后，JS 再继续执行，渲染引擎再渲染。
通过这样间隔执行的方式，让用户感知不到卡顿的存在。
此时我们为了更好的观察效果，让每一个小任务的执行都阻塞 1ms。
function task() { const startTime = performance.now() let span = document.createElement('span') span.innerText = 1 while (performance.now() - startTime < 1) { // 阻塞 1 ms } container.appendChild(span)}然后把任务数量改成 1000。
const taskQueue = Array.from({ length: 1000 }, () => task)执行效果如下：
我们另外起一个按钮，专门用于执行一些插队任务。插队的逻辑非常简单，只需要往 taskQueue 中添加任务即可。不过插队任务的优先级更高一些，因此要通过 push 来添加，以确保任务能够更早的执行。
首先声明一个 highPriorityTask 函数用于创建优先级更高的任务。
function highPriorityTask() { const startTime = performance.now() let span = document.createElement('span') span.style.color = 'red' span.innerHTML = '<strong>插队任务</strong>' while (performance.now() - startTime < 1) { // 阻塞 1 ms } container.appendChild(span)}新增一个按钮，用于触发插队任务的执行。
pushBtn.onclick = function () { taskQueue.push(highPriorityTask)}我们来看一下执行效果，每当我点击插队任务按钮，就会执行一个优先级更高的任务。
代码非常的简单，不过理解可能需要稍微思考一下。因为 performWorkUnit 中递归在遍历队列 taskQueue，并且这个递归过程是一直处于中断 -> 恢复的过程中，因此，当遍历被中断后，在它恢复之前，我们可以往 taskQueue 中插入新的任务到队列头部，当它重新开始遍历时，新加入的任务就会被执行。
这里一个小的细节是，在事件循环的运行规则中，点击事件的回调会比 requestIdleCallback 更早执行。
这个逻辑就是 React 并发模式的底层原理。只不过在 React 中，同时兼容了同步更新与异步更新，并且设计了更加复杂的优先级机制，增加了更多场景的条件判断，导致源码看上去变得更加复杂了。
当然，React 由于为了兼容更多的场景，改写了任务中断的判断条件。因为在别的环境里，例如 node/React Native 等，不支持 requestIdleCallback，在这些场景之下，React 把中断策略改为 5ms 中断一次，然后利用 performance.now 或者 Date.now 来记录时间。
/* eslint-disable no-var */var getCurrentTime;var hasPerformanceNow = typeof performance === 'object' && typeof performance.now === 'function';if (hasPerformanceNow) { var localPerformance = performance; getCurrentTime = function () { return localPerformance.now(); };} else { var localDate = Date; var initialTime = localDate.now(); getCurrentTime = function () { return localDate.now() - initialTime; };function shouldYieldToHost() { var timeElapsed = getCurrentTime() - startTime; if (timeElapsed < frameInterval) { // 5ms // 主线程只被阻塞了很短时间; // smaller than a single frame. Don't yield yet. return false; } // 主线程被阻塞的时间不可忽视 return true;}并使用别的方式来替代 requestIdleCallback。
let schedulePerformWorkUntilDeadline;if (typeof localSetImmediate === 'function') { // Node.js and old IE. schedulePerformWorkUntilDeadline = () => { localSetImmediate(performWorkUntilDeadline); };} else if (typeof MessageChannel !== 'undefined') { // DOM and Worker environments. // We prefer MessageChannel because of the 4ms setTimeout clamping. const channel = new MessageChannel(); const port = channel.port2; channel.port1.onmessage = performWorkUntilDeadline; schedulePerformWorkUntilDeadline = () => { port.postMessage(null); };} else { // We should only fallback here in non-browser environments. schedulePerformWorkUntilDeadline = () => { // $FlowFixMe[not-a-function] nullable value // @ts-ignore localSetTimeout(performWorkUntilDeadline, 0); };}本文链接：http://www.28at.com/showinfo-26-87957-0.html从简单中窥见高端，彻底搞懂任务可中断机制与任务插队机制
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
