避免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事件循环的特性，将长时间运行的任务分解或推迟，从而让主线程保持活跃，确保用户界面的流畅响应。选择哪种策略，则取决于任务的性质、优先级以及对实时性的要求。
暂无评论内容