requestAnimationFrame 执行机制探索
[TOC]
什么是 requestAnimationFrame
window.requestAnimationFrame() 告诉浏览器——你希望执行一个动画，并且要求浏览器在下次重绘之前调用指定的回调函数更新动画。
该方法需要传入一个回调函数作为参数，该回调函数会在浏览器下一次重绘之前执行。根据以上 MDN 的定义，requestAnimationFrame 是浏览器提供的一个按帧对网页进行重绘的 API 。
先看下面这个例子，了解一下它是如何使用并运行的
const test = document.querySelector("#test")!;
let i = 0;
function animation() {
if (i > 200) return;
test.style.marginLeft = `${i}px`;
window.requestAnimationFrame(animation);
i++;
}
window.requestAnimationFrame(animation);
上面的代码 1s 大约执行 60 次，因为一般的屏幕硬件设备的刷新频率都是 60Hz，然后每执行一次大约是 16.6ms。使用 requestAnimationFrame 的时候，只需要反复调用它就可以实现动画效果。
同时 requestAnimationFrame 会返回一个请求 ID，是回调函数列表中的一个唯一值，可以使用 cancelAnimationFrame 通过传入该请求 ID 取消回调函数。
const test = document.querySelector("#test")!;
let i = 0;
let requestId: number;
function animation() {
test.style.marginLeft = `${i}px`;
requestId = requestAnimationFrame(animation);
i++;
if (i > 200) {
cancelAnimationFrame(requestId);
}
}
animation();
下图 1 是上面例子的执行结果:
requestAnimationFrame 执行困惑
使用 JavaScript 实现动画的方式还可以使用 setTimeout ，下面是实现的代码
const test = document.querySelector("#test")!;
let i = 0;
let timerId: number;
function animation() {
test.style.marginLeft = `${i}px`;
// 执行间隔设置为 0，来模仿 requestAnimationFrame
timerId = setTimeout(animation, 0);
i++;
if (i > 200) {
clearTimeout(timerId);
}
}
animation();
在这里将 setTimeout 的执行间隔设置为 0，来模仿 requestAnimationFrame。
单单从代码上实现的方式，看不出有什么区别，但是从下面具体的实现结果就可以看出很明显的差距了。
下图 2 是 setTimeout 执行结果
很明显能看出，setTimeout 比 requestAnimationFrame 实现的动画“快”了很多。这是什么原因呢？
可能你也猜到了，Event Loop 和 requestAnimationFrame 在执行的时候有些特殊的机制，下面就来探究一下 Event Loop 和 requestAnimationFrame 的关系。
Event Loop 与 requestAnimationFrame
Event Loop（事件循环）是用来协调事件、用户交互、脚本、渲染、网络的一种浏览器内部机制。
Event Loop 在浏览器内也分几种：
window event loopworker event loopworklet event loop
我们这里主要讨论的是 window event loop。也就是浏览器一个渲染进程内主线程所控制的 Event Loop。
task queue
一个 Event Loop 有一个或多个 task queues。一个 task queue 是一系列 tasks 的集合。
注：一个
task queue在数据结构上是一个集合，而不是队列，因为事件循环处理模型会从选定的task queue中获取第一个可运行任务（runnable task），而不是使第一个 task 出队。上述内容来自 HTML 规范。这里让人迷惑的是，明明是集合，为啥还叫“queue”啊 T.T
task
一个 task 可以有多种 task sources (任务源)，有哪些任务源呢？来看下规范里的 Gerneric task sources
-
DOM操作任务源，比如一个元素以非阻塞的方式插入文档 - 用户交互任务源，用户操作（比如 click）事件
- 网络任务源，网络 I/O 响应回调
- history traversal 任务源，比如
history.back()
除此之外还有像 Timers (setTimeout、setInterval 等)、IndexDB 操作也是 task source。
microtask
一个 event loop 有一个 microtask queue，不过这个 “queue” 它确实就是那个 FIFO 的队列。
规范里没有指明哪些是 microtask 的任务源，通常认为以下几个是 microtask
- promises
- MutationObserver
- Object.observe
- process.nextTick (这个东西是 Node.js 的 API，暂且不讨论)
Event Loop 处理过程
- 在所选
task queue(taskQueue)中约定必须包含一个可运行任务。如果没有此类task queue，则跳转至下面microtasks步骤。 - 让
taskQueue中最老的 task (oldestTask) 变成第一个可执行任务，然后从 taskQueue 中删掉它。 - 将上面 oldestTask 设置为
event loop中正在运行的 task。 - 执行 oldestTask。
- 将
event loop中正在运行的 task 设置为 null。 - 执行
microtasks检查点（也就是执行microtasks队列中的任务）。 - 设置
hasARenderingOpportunity为 false。 - 更新渲染。
- 如果当前是
window event loop且task queues里没有 task 且microtask queue是空的，同时渲染时机变量hasARenderingOpportunity为 false ，去执行 idle period（requestIdleCallback）。 - 返回到第一步。
大体上来说，event loop 就是不停地找 task queues 里是否有可执行的 task ，如果存在即将其推入到 call stack （执行栈）里执行，并且在合适的时机更新渲染。
下图 3 是 event loop 在浏览器主线程上运行的一个清晰的流程
在上面规范的说明中，渲染的流程是在执行 microtasks 队列之后，更进一步，再来看看渲染的处理过程。
更新渲染
- 遍历当前浏览上下文中所有的
document，必须按在列表中找到的顺序处理每个document。 - 渲染时机（Rendering opportunities）：如果当前浏览上下文中没有到渲染时机则将所有 docs 删除，取消渲染（此处是否存在渲染时机由浏览器自行判断，根据硬件刷新率限制、页面性能或页面是否在后台等因素）。
- 如果当前文档不为空，设置
hasARenderingOpportunity为 true 。 - 不必要的渲染（Unnecessary rendering）：如果浏览器认为更新文档的浏览上下文的呈现不会产生可见效果且文档的
animation frame callbacks是空的，则取消渲染。（终于看见requestAnimationFrame的身影了 - 从 docs 中删除浏览器认为出于其他原因最好跳过更新渲染的文档。
- 如果文档的浏览上下文是顶级浏览上下文，则刷新该文档的自动对焦候选对象。
- 处理
resize事件，传入一个performance.now()时间戳。 - 处理
scroll事件，传入一个performance.now()时间戳。 - 处理媒体查询，传入一个
performance.now()时间戳。 - 运行 CSS 动画，传入一个
performance.now()时间戳。 - 处理全屏事件，传入一个
performance.now()时间戳。 - 执行
requestAnimationFrame回调，传入一个performance.now()时间戳。 - 执行
intersectionObserver回调，传入一个performance.now()时间戳。 - 对每个
document进行绘制。 - 更新 ui 并呈现。
至此，requestAnimationFrame 的回调时机就清楚了，它会在 style/layout/paint 之前调用。
再回到文章开始提到的 setTimeout 动画比 requestAnimationFrame 动画更快的问题，这就很好解释了。
首先，浏览器渲染有个渲染时机（Rendering opportunity）的问题，也就是浏览器会根据当前的浏览上下文判断是否进行渲染，它会尽量高效，只有必要的时候才进行渲染，如果没有界面的改变，就不会渲染。
按照规范里说的一样，因为考虑到硬件的刷新频率限制、页面性能以及页面是否存在后台等等因素，有可能执行完 setTimeout 这个 task 之后，发现还没到渲染时机，所以 setTimeout 回调了几次之后才进行渲染，此时设置的 marginLeft 和上一次渲染前 marginLeft 的差值要大于 1px 的。
下图 5 是 setTimeout 执行情况，红色圆圈处是两次渲染，中间四次是处理 setTimout task，因为屏幕的刷新频率是 60 Hz，所以大致在 16.6ms 之内执行了多次 setTimeout task 之后才到了渲染时机并执行渲染。
requestAnimationFrame 帧动画不同之处在于，每次渲染之前都会调用，此时设置的 marginLeft 和上一次渲染前 marginLeft 的差值为 1px 。
下图 6 是 requestAnimationFrame 执行情况，每次调用完都会执行渲染：
所以看上去 setTimeout “快”了很多。
其他应用
使用 setTimeout 来执行动画之类的视觉变化，很可能导致丢帧，导致卡顿，所以应尽量避免使用 setTimeout 来执行动画，推荐使用 requestAnimationFrame 来替换它
requestAnimationFrame 除了用来实现动画的效果，还可以用来实现对大任务的分拆执行
执行 JavaScript task 是在渲染之前，如果在一帧之内 JavaScript 执行时间过长就会阻塞渲染，同样会导致丢帧、卡顿
针对这种情况可以将 JavaScript task 划分为各个小块，并使用 requestAnimationFrame() 在每个帧上运行。如下例所示
var taskList = breakBigTaskIntoMicroTasks(monsterTaskList);
requestAnimationFrame(processTaskList);
function processTaskList(taskStartTime) {
var taskFinishTime;
do {
// 假设下一个任务被压入 call stack
var nextTask = taskList.pop();
// 执行下一个 task
processTask(nextTask);
// 如何时间足够继续执行下一个
taskFinishTime = window.performance.now();
} while (taskFinishTime - taskStartTime < 3);
if (taskList.length > 0) {
requestAnimationFrame(processTaskList);
}
}
原文链接：requestAnimationFrame 执行机制探索