在 JS 中如何调度后台任务?

关于 JavaScript,就算什么都不记得了,也请牢记这一点:它是阻塞式的

 

想象一下,你的浏览器是靠一个神奇的小精灵来运行的。所有的事情都是这一个小精灵来干的,不管是渲染 HTML、响应菜单的命令、在屏幕上绘图、处理鼠标点击,还是执行一个 JavaScript 函数。和我们大多数人一样,小精灵同时只能做一件事。如果我们把好多事都丢给小精灵,它们会被排到一个待处理列表中,按照顺序依次执行。

 

当小精灵碰到一个 script 标签,或者必须运行一个 JavaScript 函数的时候,所有事情都得停下来。首先得下载代码(如果需要的话),然后立即执行这些脚本,再然后才能继续执行后面的事件或者渲染操作。这个过程是必须的,因为你的脚本可能执行任何操作:加载后续代码、移除所有 DOM 元素、跳转到其他的 URL 等等。就算有两个或者更多的小精灵,在第一个小精灵处理你的代码的时候,剩下那些也得停下来等着。这就是所谓的阻塞式。在长时间运行脚本的时候,正式这种机制导致了浏览器会失去响应。

 

你经常希望你的 JavaScript 代码能够尽快执行,因为这些代码会初始化组件和事件处理函数。然而,也有一些不那么重要的后台任务,它们并不会直接影响用户体验,例如:

  • 记录分析数据
  • 把数据发送到社交网络(或者添加 57 个“分享”按钮)
  • 内容预读取
  • HTML 的预处理或者预渲染

 

这些任务在时间上并不是那么重要,不过为了让页面保持响应,在用户滚动页面或者与内容进行交互的时候,它们就不应该运行了。

 

选择之一是使用 Web Worker,它可以在一个独立的线程中并行运行。对于内容预读取和预处理工作而言,这是个不错的选择,不过在 Web Worker 中,你无法直接访问或者更新 DOM。当然你可以在你自己的代码中避免这一点,但你无法保证永远不会依赖第三方代码,比如 Google Analytics。

 

另一种可能的方式是使用 setTimeout,比如:setTimeout(doSomething, 1);。浏览器会在其它立即执行的任务完成后,再去执行 doSomething() 函数。实际上,这种方式是把它放到了待处理列表的最后面。不幸的是,不管是否需要,这个函数最终都会被调用。

 

requestIdleCallback

 

requestIdleCallback 是一个全新的 API,它可以在浏览器空闲的时候去调度那些不那么重要的后台任务。与之类似的还有 requestAnimationFrame,可以通过调用一个函数在下一次重绘之前更新动画。更多关于 requestAnimationFrame 的内容请见:使用 requestAnimationFrame 实现简单动画

 

我们可以通过如下方法检测浏览器是否支持 requestIdleCallback:

 

也可以指定一个 options 对象作为参数,其中包含超时时间(以毫秒为单位),例如:

 

这种方式可以确保你的函数在前 3 秒之内被调用,不论浏览器是否空闲。

 

requestIdleCallback 只会调用你的函数一次,并传递一个 deadline 对象,该对象内包含如下属性:

  • didTimeout — 如果上文提到的超时事件被触发了,该属性为 true
  • timeRemaining() — 该函数会返回执行任务所剩余的毫秒数

 

timeRemaining() 会给任务运行分配不超过 50 毫秒的时间。如果任务执行超过这个时间的话,任务并不会被强行终止,不过推荐的做法是,此时你应该再次调用 requestIdleCallback 来调度后续的处理流程。

 

让我们创建一个简单的示例,按照顺序执行多个任务。这些任务存储在一个数组中,该数组会在函数内使用:

 

是否有什么事情是不应该放在 requestIdleCallback 中执行的?

 

Paul Lewis 在他的博客中进行了说明,在 requestIdleCallback 中执行的操作应该是小片段的形式,不应该执行那些运行时间无法预测的任务(比如处理 DOM 更适合使用 requestAnimationFrame 回调)。你同样需要当心 Promise 对象的 resolve 或 reject,因为在空闲回调结束后,即使已经没有剩余时间,Promise 的回调也会立即执行。

 

requestIdleCallback 的浏览器支持情况

 

requestIdleCallback 是一个试验性质的特性,规范依然有可能会发生变化,所以如果你遇到了 API 变动的情况请不要吃惊。Chrome 47 支持该特性,也就是说应该在 2015 年结束之前。Opera 也应该很快就会支持该特性。微软和 Mozilla 也在考虑该 API,看起来问题不大。苹果公司一如既往地对此不置可否。如果你现在就要尝尝鲜,你的最佳选择是使用 Chrome Canary(最新版本的 Chrome,没有经过全面测试,但是其中包含了最新的特性)。(译注:在本文翻译时 Chrome 47 已经发布,并支持该特性)

 

之前提到的 Paul Lewis 创建了一个简单的 requestIdleCallback 替代品。它会实现同样功能的 API,不过它并不是完整的,因为没有模拟浏览器的空闲行为检测。它是靠 setTimeout 来完成功能的,正如上面的例子一样。如果你想要使用该 API,又不想做对象检测和代码更新的话,这也是个不错的选择。

 

尽管到目前为止支持还比较有限,requestIdleCallback 还是个有趣的东西,可以帮助你最大限度的优化网页性能。不过你是怎么想的呢?欢迎在本文下方发表你的评论。

打赏支持我翻译更多好文章,谢谢!

打赏译者

打赏支持我翻译更多好文章,谢谢!

1 4 收藏 评论

关于作者:Erucy

曾经的SharePoint喵星程序猿(暂时还挂着微软MVP的名头),现在的Azure/.Net/MongoDB/Cordova/前端程序猿,偶尔写小说 个人主页 · 我的文章 · 46 ·   

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部