Summary

  • W3C 于 2009 年 4 月 23 日发布首份 Web Workers 工作草案，允许网页在独立的并行执行环境运行后台脚本，通过消息与主页面协调。
  • 草案里的质数示例把循环计算放进 worker，算出新结果后逐个发给页面；页面负责显示，同时继续处理点击等交互。

一个按钮有没有礼貌，得在网页最忙的时候试。你点击它，没反应。再点一次，还是没反应。过一阵页面突然把积压的动作一股脑吐出来，仿佛刚才不是装聋，而是在办公室里埋头算账。计算本身可能毫无差错，但用户已经不知道页面还听不听得见自己。

W3C 在 2009 年 4 月 23 日发布的 Web Workers 工作草案要处理的正是这件事。草案允许后台脚本独立于响应点击等动作的界面脚本运行。它拿寻找质数举例：主页面启动一个 worker，worker 不断寻找新质数，找到就把结果送回，页面再把最新数字显示出来。柜台继续接待客人，里屋继续做算术。

这套分工并不神秘。页面用一个脚本 URL 创建 Worker；浏览器为它安排独立的并行执行环境。两边借 postMessage 和消息处理器交谈。后台负责循环计算，前台负责屏幕。质数从里屋传到柜台后，由页面里的代码改动可见文字。做计算的脚本有自己的工作空间，它要影响界面就得把结果说明白、送到正确的门口。

2009 年 12 月的后续草案把这种方式描述为类似线程的运行方式，以消息传递协调。消息不是为难程序员的额外手续，而是划清责任的一道门。页面可以发出任务，worker 报告进展，页面决定何时把结果给读者看。如果读者早已换了问题，迟来的旧答案也要先经过页面判断，而不是自己冲上屏幕宣布胜利。

为什么选质数？因为它把借口拿掉了。示例无需等待远方服务器，也没有慢吞吞的网络。网页卡住，原因就是一段计算占了处理交互的时间。把循环移到 worker，页面可以继续听取点击；新质数到了再更新数字。用户不用盯着凝固的界面猜浏览器是否还活着。这是把工作换了地方，不是给“请稍候”换一种字体。

后台员工也要吃资源。2009 年 12 月草案提醒读者，worker 有启动成本和单个实例的内存成本。文档甚至举了一个荒唐的反例：四百万像素的图片，给每个像素单独开一个 worker。召来四百万个小帮手处理四百万个点，最后可能只剩帮手在互相找工位。该把整项有意义的任务交给后台，而不是把每个微小动作都办成一次招聘。

后来文档把帮手的地址写得更清楚。2012 年候选推荐标准快照继续区分专用 worker 与共享 worker。专用 worker 通过隐含的通道与创建者通信；共享 worker 可以通过端口接待同一来源的多个连接。2015 年工作草案详细描述了 Worker 的创建、onmessage、postMessage 和共享 worker 的 MessagePort。多了一个后台工作间，回信地址也必须写对。

浏览器还有另一种边界：数据应该存在哪个窗口、哪个来源。Web Workers 解决的是工作在哪里跑、结果怎样回来。两者可以出现在同一网页上：订票选择保存在合适的空间，耗时搜索交给 worker。前台和后台不必挤在同一条队伍里，也不必共享一个模糊的“当前”状态。好的分工让人看得见进度，找得着答案的来路。

W3C 的发布沿革列出了 2009 年草案、2012 年候选快照和 2015 年草案。质数示例之所以耐看，在于它问了一个很普通的问题：网页算得再聪明，能不能顺手回应按按钮的人？后台继续数，页面继续听，消息把两件事接起来。