译者: cncuckoo
关于JavaScript,大家要牢记一点:它阻塞。
想象一下,浏览器里有一个进程小精灵,负责处理一切。渲染HTML、响应菜单命令、绘制屏幕、处理鼠标点击、运行JavaScript函数……。跟我们人一样,这个小精灵每次只能做一件事。如果一次交给它很多任务,那么就会有一个待办事项列表,小精灵按顺序一项一项去处理。
小精灵在碰到script
标签或者要运行JavaScript函数时,会停下其他任务。下载代码(必要时)然后立即运行,之后才会触发其他事件 ,以及渲染页面。这是必要的,因为脚本几乎什么都可能做:加载更多代码、删除DOM元素、重定向URL,等等。就算有两个甚至更多小精灵,那其他小精灵也需要在首次处理代码时停下来。这就是阻塞。这也是为什么运行时间过长的脚本会导致浏览器无响应的原因。
我们通常想让JavaScript尽快运行,因为代码要初始化部件和事件处理程序。可是,有些没那么重要的后台任务并不会直接影响用户体验,比如:
- 记录分析数据
- 向社交网络改送数据(或发送57个“分享”按钮)
- 预先取得内容
- 预先处理或预先渲染HTML
这些任务并不要求立即完成,而为了保证页面持续响应,不应该在用户滚动页面或浏览内容期间执行这些任务。
为此可以使用Web Workers,在另一个线程里并发地运行代码。这个技术非常适合预先取得和处理数据,但无权直接访问或修改DOM。你可保证自己的脚本不那么干,但却无法保证Google Analytics等第三方脚本不那么干。
还有一个选择是setTimeout
,比如setTimeout(doSomething, 1);
。浏览器会在立即执行的任务完成后紧接着执行doSomething()
函数。实际上是把它放在了待办事项的最后一项。问题在于无论有没有处理需求,这个函数都会被调用。
requestIdleCallback
requestIdleCallback是新API,用于在浏览器空闲的时候安排一些没那么重要的后台任务。这个API会让人联想到requestAnimationFrame,后者会在下一次绘制前调用函数更新动画。具体内容可以参考这篇文章:Simple Animations Using requestAnimationFrame
可以这样检测浏览器是否支持requestIdleCallback
:
if ('requestIdleCallback' in window) {
// 支持requestIdleCallback
requestIdleCallback(backgroundTask);
}
else {
// 不支持,换一种方式
setTimeout(backgroundTask1, 1);
setTimeout(backgroundTask2, 1);
setTimeout(backgroundTask3, 1);
}
还可以通过一个选项对象参数,指定暂停时间(以毫秒计),比如:
requestIdleCallback(backgroundTask, { timeout: 3000; });
这样可以保证你的函数在三秒钟内执行,无论浏览器是否空闲。
requestIdleCallback
只会调用一次你的函数,并传入一个包含以下属性的期限(deadline)对象:
didTimeout
— 如果可选的暂停时间已到则为true
timeRemaining()
— 函数,返回留给任务执行的毫秒数
timeRemaining()
会给你的任务分配不超过50ms的执行时间。它不会让任务停止超过这个时间限制,不过你可以再次调用requestIdleCallback
以安排进一步的处理。
下面看一个例子,按顺序执行几个任务。任务以函数引用形式保存在一个数组中:
// 要运行的函数数组
var task = [
background1,
background2,
background3
];
if ('requestIdleCallback' in window) {
// 支持requestIdleCallback
requestIdleCallback(backgroundTask);
}
else {
// 不支持,待会一次性运行所有任务
while (task.length) {
setTimeout(task.shift(), 1);
}
}
// requestIdleCallback回调函数
function backgroundTask(deadline) {
// 有可能的话运行下一个任务
while (deadline.timeRemaining() > 0 && task.length > 0) {
task.shift()();
}
// 还有未执行的任务,再次申请处理
if (task.length > 0) {
requestIdleCallback(backgroundTask);
}
}
有没有什么不应该通过requestIdleCallback做的
正如Paul Lewis在他关于这个主题的博客文章所说的,requestIdleCallback
应该执行小任务,不适合执行时间不确定的任务(像操作DOM,最好还是用requestAnimationFrame
回调来做)。在resolve
(或reject
)Promise的时候也要注意,因为空闲回调完成后会立即调用Promise的回调,而不管剩下的时间还够不够执行该回调。
requestIdleCallback的浏览器支持情况
requestIdleCallback
是一个实验性的API,规范仍在制定中,今后很可能有改动。Chrome 47支持它,Opera应该也会跟进。Microsoft和Mozilla都在关注它,前景不错。Apple照例没有表态。如果你现在就想试一试,最好用Chrome Canary。
Paul Lewis写了一个简单的requestIdleCallback
“垫片脚本”,实现了上述API的行为,但它不是一个可以模拟浏览器空闲检测行为的“腻子脚本”。他使用的是类似前面例子中的setTimeout
。不过,如果你不想依赖对象检测也不想写分支代码,用这个脚本还是不错的。
虽然今天的浏览器对requestIdleCallback
的支持有限,但这个API的确非常有助于提升网页性能。你对此有什么想法吗?欢迎留言。
qqqqqq
ssss
你们就不能有责任心一点的评论吗