笔记&收藏&学习

本文由简悦 SimpRead 转码，原文地址 mp.weixin.qq.com

点击上方前端 Q，关注公众号

回复加群，加入前端 Q 技术交流群

本文适合对任务切片感兴趣的小伙伴阅读

一、代码背景

本次分享基于一次线上环境的卡顿事故，客户数据体量过大导致的页面卡顿甚至页面直接崩溃的问题。现在我们将会把此次事故抽象成为大家更好理解的案例，从而来进行分析和解决。

同时希望大家在阅读完之后可以了解到页面卡顿背后的底层原因，还有任务切片的解决原理！

二、正文

<body>    <input type="text">    <button id="my-button">执行任务</button>    <!-- box容器 -->    <div id="box" style="height:500px;width:400px;overflow: auto;margin-top:24px;"></body>

// box容器溢出滚动const box = document.getElementById('box')for(let i=0;i<1000;i++){    const myText = document.createElement('h2')    myText.innerText = i    box.appendChild(myText)}// 执行任务const myButton = document.getElementById('my-button')myButton.addEventListener('click',load)function load() {  const total = 300000;  for (let i = 0; i < total; i++) {      console.log(i)  }}

点击执行任务按钮会发现，我们不仅不能和输入框进行交互，连 box 容器区域的滚动也不再有响应，整个页面卡顿住了，直到 load 任务执行完成，页面才恢复响应，输入框才能正常使用，box 容器区域也能正常响应滚动。

或许观察到这里有人已经能够想到解决方案了！

我知道了，长任务执行导致页面卡顿，使用任务切片的方式解决！

没错，这里确实是使用任务切片的方式能够解决！但是，我想问一下，任务切片解决卡顿问题的底层原理是什么样子的？或者说什么是卡顿问题，而任务切片又是如何解决这类问题的？

卡顿分析

保证页面的流畅性是前端的一个主要内容，页面卡顿会严重影响用户体验。这流畅性是需要一个指标来衡量的，那就是帧率（FPS），FPS 表示的是每秒钟画面更新次数，当今大多数设备的屏幕刷新率都是 60 次 / 秒。

不同帧率的体验

帧率能够达到 50 ～ 60 FPS 的动画将会相当流畅，让人倍感舒适；
帧率在 30 ～ 50 FPS 之间的动画，因人敏感程度不同，舒适度因人而异；
帧率在 30 FPS 以下的动画，让人感觉到明显的卡顿和不适感；
帧率波动很大的动画，亦会使人感觉到卡顿

也就是说想要保证页面流畅不卡顿，浏览器对每一帧画面的渲染工作需要在 16ms（1000ms/60）之内完成！

想要保证页面流畅，需要做到每16ms渲染一次！

也就是说，前面在我们执行任务的时候，浏览器没有能够做到每 16ms 渲染一次，所以我们页面会卡顿不流畅。那么是什么导致了浏览器没有能够正常渲染呢？或许在探索真相之前，我们还需要先深入了解一下浏览器的事件循环机制！

浏览器事件循环机制

浏览器事件循环机制是一种用于处理异步任务的机制。它的工作原理是不断地检查任务队列，执行队列中的任务，并等待新的任务加入。

执行顺序：

执行宏任务队列和微任务队列就不解释了。

进入 Update the rendering 阶段，这里有个 rendering opportunity 概念，浏览上下文渲染会根据屏幕刷新率、页面性能、页面是否在后台来确定是否需要渲染。而且渲染间隔通常是固定的。
如果不需要渲染，以下步骤（只列举常用的）也不会运行了：

run the resize steps，触发 resize 事件；
run the scroll steps，触发 scroll 事件；
update animations，触发 animation 相关事件;
run the fullscreen steps，执行 requestFullscreen 等 api；
run the animation frame callbacks，执行 requestAnimationFrame 回调；
run IntersectionObserver callbacks，图片懒加载经常使用；

重新渲染用户界面。
判断宏任务队列或者微任务队列是否为空，如果为空则执行 Idle 空闲周期计算，判断是否需要执行 requestIdleCallback 的回调。

性能分析

通过我们上面对浏览器事件循环的深入了解，我们可以知道，浏览器没能每 16ms 渲染一次也能被解读为没能每 16ms 执行完一次事件循环。

结合我们页面的 Performance 可以看到，load 函数的执行花费了 6s 多，而事件循环中的渲染需要等待前面任务执行完毕，才会判断执行。

也就是说，浏览器花费了 6s 多的时间才完成了一次事件循环，完成了一次渲染任务，而我们保持页面 60FPS 的最低要求是每 16ms 完成一次渲染，这就难怪页面会卡顿不流畅，这显然是不合理的！

任务切片（setTimeout、requestAnimationFrame）

这就类似我们去餐厅吃饭，我们几个人很饿，点了很多菜给到厨房，但是厨房却等所有菜都做完（长任务执行）才全部一次性端上来（渲染），这样的体验毫无疑问是十分差劲的。

正确的做法应该是我们点了很多菜（一个长任务），厨房做完一道菜（小任务执行），就端上来一道（渲染一次），这样分多次上菜（多个小任务多次渲染）才不会让顾客等待太久，也能提升用户体验。

回到我们的页面代码，我们也可以按照这个思路，将 load 函数代码拆分成多个小任务，保证 16ms 内能执行完一次事件循环，这样才能保持页面流畅不卡顿，而这个时候，就需要应用到我们的任务切片了！

终于回到任务切片了！

一般我们可以使用setTimeout或者requestAnimationFrame实现任务切片，这里我们使用setTimeout举例说明：

function load() {    let total = 1000000;    let length = 20;    let page = total/length    let index = 0;    function loop(curTotal,curIndex){        if(curTotal <= 0){            return false;        }        let pageCount = Math.min(curTotal , length);        setTimeout(()=>{            for(let i = 0; i < pageCount; i++){                console.log(i)            }            loop(curTotal - pageCount,curIndex + pageCount)        },0)    }    loop(total,index);  }

此时我们运行代码之后发现，点击执行任务按钮时，页面不再卡顿，输入框能够正常 focus 交互，box 容器区域也能正常滚动，一整个流畅！

我们再根据页面 Performance 进行分析：