避免事件循环阻塞主线程的技巧有哪些？

来到golang学习网的大家，相信都是编程学习爱好者，希望在这里学习文章相关编程知识。下面本篇文章就来带大家聊聊《避免事件循环阻塞主线程的方法有哪些？》，介绍一下，希望对大家的知识积累有所帮助，助力实战开发！

避免JavaScript主线程阻塞的核心策略包括：1. 使用Web Workers处理计算密集型任务，通过独立线程执行复杂计算，避免影响主线程；2. 优化异步I/O操作，利用Promise和async/await确保网络请求等任务不阻塞主线程；3. 任务切片与调度，将大任务拆分为小块，通过setTimeout、Promise.then或requestIdleCallback分批执行；4. 合理使用requestAnimationFrame确保动画逻辑与浏览器绘制同步。主线程阻塞会导致页面卡顿、用户交互无响应、动画掉帧等问题，影响应用的响应性和用户体验。Web Workers虽能解决CPU密集型任务的性能瓶颈，但无法直接访问DOM，数据通信需序列化，且创建销毁有成本，不适合频繁与DOM交互的任务。其他策略如任务切片和requestIdleCallback可“欺骗”事件循环，让主线程保持响应，适用于不同优先级和性质的任务。

避免JavaScript主线程被长时间任务阻塞的核心策略，就是将那些耗时或可能耗时的操作从主线程剥离出去，或者将其分解成小块，在合适的时机分批执行，从而让主线程保持响应，不至于卡顿。这就像是把一个大包裹拆成几个小包裹，分几次送达，而不是一次性堵住整个通道。

解决方案

要有效避免主线程阻塞，我们通常会采取以下几种方式：

• 利用Web Workers处理计算密集型任务： 这是最直接也最彻底的方法。当你有大量数据处理、复杂计算或图像处理等CPU密集型任务时，可以将其放入Web Worker中执行。Web Worker运行在一个独立于主线程的全局环境中，它有自己的事件循环，因此在Worker中进行的任何耗时操作都不会影响到主线程的UI渲染和事件响应。虽然它不能直接访问DOM，但可以通过postMessage与主线程通信，传递数据和结果。
• 优化异步I/O操作： 对于网络请求（如fetch或XMLHttpRequest）或文件读写等I/O密集型任务，JavaScript本身就是异步的。关键在于正确使用Promise、async/await来组织代码，确保这些操作在等待结果时不会阻塞主线程。这些操作的等待时间是交给浏览器底层处理的，而不是占用JS主线程。
• 任务切片与调度： 对于那些无法完全放到Web Worker中，但又相对耗时的任务（比如处理一个很大的数组、复杂的DOM操作），可以将其分解成多个小任务，利用事件循环的机制，在每个小任务执行完毕后，将控制权交还给主线程，让浏览器有机会进行渲染和处理用户输入。这通常通过setTimeout(0)、Promise.resolve().then()或requestIdleCallback来实现。
• 合理使用requestAnimationFrame： 如果你的任务涉及到动画或需要与浏览器绘制同步，requestAnimationFrame是首选。它确保你的回调函数在浏览器下一次重绘之前执行，这对于平滑的动画至关重要。虽然它本身不会避免阻塞，但结合任务切片，可以确保动画逻辑在不阻塞UI的情况下执行。

为什么主线程阻塞是个大问题，它到底影响了什么？

说实话，我们日常开发中遇到的“页面卡顿”、“鼠标点击没反应”、“动画掉帧”等等，绝大多数都和JavaScript主线程被阻塞脱不开关系。你想想看，浏览器里跑JavaScript的这个主线程，它可不光是执行你的业务逻辑代码，它还得负责渲染页面、处理用户交互（比如点击、滚动、输入）、执行动画，甚至还有网络请求的回调等等。

如果你的某段JS代码运行时间太长，比如超过50毫秒，那么这个主线程就会被“霸占”住。在这段时间里，它就没空去管用户的点击事件，没空去重新绘制你页面的新状态，更别提流畅的动画了。结果就是，用户看到的是一个“死掉”的页面，鼠标点半天没反应，动画卡住不动，整个体验就崩了。这不仅仅是用户感受上的慢，更是直接导致应用失去响应性，用户会觉得你的产品“不好用”、“卡顿”。在我看来，这是一个非常严重的性能问题，直接关系到用户对产品的评价。

Web Workers真的能解决所有性能瓶颈吗？它有什么局限？

Web Workers确实是解决CPU密集型任务阻塞主线程的“核武器”，因为它直接开辟了一个新的线程来跑JS代码，这听起来太棒了，简直是性能优化的万金油。但要说它能解决所有性能瓶颈，那就有点言过其实了，它有自己明确的适用场景和局限性。

首先，Web Worker最大的优点就是能让那些复杂的计算、大数据处理、图片编解码等耗时操作在后台默默进行，不占用主线程资源。这对于提升应用的响应速度和用户体验是革命性的。比如，你可以在Worker里处理一个G级别的大文件，或者进行复杂的图像滤镜计算，而用户依然可以在主页面上流畅地操作。

然而，Web Worker并非万能。它最大的局限在于无法直接访问DOM。这意味着你不能在Worker里直接操作页面元素，也不能直接访问window、document等全局对象。所有与UI相关的操作，最终还是得回到主线程来完成。Worker和主线程之间的数据通信，只能通过postMessage和onmessage进行消息传递，而且传递的数据会被序列化（结构化克隆算法），这意味着传递大量复杂对象时，会有一定的性能开销。

此外，Web Worker的创建和销毁也是有成本的。如果你的任务非常短小，或者需要频繁地与DOM交互，那么使用Worker反而可能引入额外的开销，得不偿失。它更适合那些独立、耗时且不需要直接操作DOM的计算任务。所以，它是一个强力的工具，但你得清楚它的边界。

除了Web Workers，还有哪些策略可以“欺骗”事件循环，让它显得不那么忙？

除了Web Workers这种开辟新线程的硬核方案，我们还有一些更“巧妙”的策略，它们并不会真正地让任务在另一个线程运行，而是通过合理地安排任务执行时机，利用事件循环的机制，让主线程能够“喘口气”，显得不那么忙碌。

一个很常用的技巧是任务切片（Task Chunking）。当有一个巨大的计算任务，比如遍历一个百万级的数据集并进行处理，如果一次性跑完，必然会阻塞主线程。我们可以把这个大任务分解成许多小任务，比如每次只处理1000条数据，处理完一批后，通过setTimeout(0)或者Promise.resolve().then(() => {})将剩余的任务推迟到下一个事件循环周期或微任务队列中执行。

例如，处理一个大数组：

function processLargeArrayInChunks(array, processItem, chunkSize = 100) {
    let index = 0;
    const total = array.length;

    function processChunk() {
        const start = index;
        const end = Math.min(index + chunkSize, total);

        for (let i = start; i < end; i++) {
            processItem(array[i]);
        }
        index = end;

        if (index < total) {
            // 将剩余任务推迟到下一个宏任务，让主线程有机会处理其他事件
            setTimeout(processChunk, 0);
            // 或者使用微任务：Promise.resolve().then(processChunk);
        } else {
            console.log('所有数据处理完毕！');
        }
    }
    processChunk();
}

// 示例用法
// const data = Array.from({ length: 1000000 }, (_, i) => i);
// processLargeArrayInChunks(data, item => {
//     // 模拟耗时操作
//     let sum = 0;
//     for (let i = 0; i < 1000; i++) {
//         sum += Math.sqrt(item + i);
//     }
//     // console.log(`Processed item: ${item}`);
// });

这种方式的原理是，setTimeout(0)虽然是0毫秒延时，但它会将回调函数放入宏任务队列的末尾，这样当前宏任务执行完毕后，浏览器就有机会进行UI渲染、处理用户输入等，然后再执行下一个小任务。Promise.resolve().then()则是将任务放入微任务队列，它会在当前宏任务执行完毕，但在下一个宏任务开始之前执行。

另一个非常实用的API是requestIdleCallback。这个API专门用于在浏览器空闲时执行低优先级的任务。当浏览器主线程没有任何高优先级任务（如动画、用户输入、网络请求回调）时，它会触发requestIdleCallback的回调。这非常适合执行一些不那么紧急的后台数据分析、日志上报、预加载等任务。它的好处是，浏览器会根据自身的负载情况来决定何时调用回调，如果浏览器一直很忙，它甚至可能不会调用，或者只调用一次。这比setTimeout更智能，因为它不会强制在特定时间执行，而是“见缝插针”。

// 示例：使用requestIdleCallback处理非关键任务
function processLowPriorityTask(deadline) {
    // deadline.timeRemaining() 告诉你当前帧还剩下多少空闲时间
    while (deadline.timeRemaining() > 0 && tasks.length > 0) {
        const task = tasks.shift();
        // 执行任务
        console.log(`Executing low priority task: ${task}`);
    }

    if (tasks.length > 0) {
        // 如果任务还没处理完，请求下一次空闲时继续
        requestIdleCallback(processLowPriorityTask);
    }
}

// let tasks = ['log data', 'analytics', 'pre-render component'];
// if ('requestIdleCallback' in window) {
//     requestIdleCallback(processLowPriorityTask);
// } else {
//     // 兼容方案，如果不支持则退化为setTimeout
//     setTimeout(() => {
//         tasks.forEach(task => console.log(`Executing fallback task: ${task}`));
//     }, 0);
// }

这些策略的共同点是，它们都利用了JavaScript事件循环的特性，将长时间运行的任务分解或推迟，从而让主线程保持活跃，确保用户界面的流畅响应。选择哪种策略，则取决于任务的性质、优先级以及对实时性的要求。

终于介绍完啦！小伙伴们，这篇关于《避免事件循环阻塞主线程的技巧有哪些？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！