原文
   
    前言
   
    之前在看面经的时候看到了
    
     “Service Workers”
    
    这个名词,赶紧百度了一下,发现许多博客对它的描述是
    
     “一个Service Worker是一段运行在
     
      浏览器后台进程
     
     里的脚本,他独立于当前页面,提供了那些不需要与web页面交互的功能在网页背后悄悄执行的能力。”
    
    我眉头一皱,发现这句话好熟悉,好像在w3school上看到过,随后一找,发现了
    
     “Web Workers”
    
    ,w3school的描述是
    
     “web worker 是运行在后台(
     
      指的是浏览器后台进程
     
     )的 JavaScript,独立于其他脚本,不会影响页面的性能”
    
    。好像都是在浏览器后台运行的js,但具体区别通实例代码看的不是特别清楚,百度也没有发现有比较两者不同。而后又找到了这篇博客,原文是英文,比较的是Service Workers/Web Workers/WebSockets三者的区别,而WebSockets我知道它是啥,并且敲过相关的项目,但还是一并翻译过来。翻译中的注释会放在括号中并用斜体表示,比较重要的地方会以粗体显示。当然,我会选取文章中比较重要的部分进行翻译。
   
    翻译
   
    作为相当新的Web技术,Service Workers、Web Workers和WebSockets都出现、停滞,然后让死灰复燃。因此,我发现自己有点困惑,究竟它们都做了什么、它们之间的区别是什么、它们的目标是什么?
    
    我试着寻找一些比较的文章,但让我吃惊的是对这三种技术进行比较的文章如此之少。我发现两个接近的…
    
    
     《明白WebSockets与Web Workers能做到事情》
    
    ,
    
     《学习HTML5游戏编程》
    
    的一个章节
    
    
     Ajax vs. Web sockets vs. Web Workers
    
    是StackOverflow网站的一篇文章
    
    ……但两篇文章都不能满足我的好奇…所以我决定把它们都弄清楚一点,然后在这里记录我的发现(这样我就可以再回来提醒自己……)。
    
    本文将不涉及任何深入的东西,没有设置或使用说明,而且代码可能会很少;我将链接到所有这些资源,这仅仅是为了“了解”这些新的Web技术。
    
    
     (
     
      下面是三项技术的简介
     
     )
    
    
    
     Service Worker:
    
    
    
     处理网络请求的后台服务
    
    。完美的离线情况下后台同步或推送通知的处理方案。不能直接与DOM交互。通信(
    
     页面和ServiceWorker之间
    
    )得通过postMessage方法
    
    
     Web Worker:
    
    
    
     模仿多线程
    
    ,允许复杂的脚本在后台运行,所以它们不会阻止其他脚本的运行。是保持您的UI响应的同时也执行处理器密集型功能的完美解决方案。不能直接与DOM交互。通信必须通过postMessage方法
    
    
     WebSocket:
    
    
    在
    
     客户端和服务器之间
    
    创建一个开放的连接,允许在一个连接上
    
     进行双向通信
    
    。是你目前使用长轮询的任何情况,比如聊天软件、在线游戏,或运动代码的完美解决方案。可以直接与DOM交互。通信是通过WebSocket的send方法。
   
    
     (
     
      下面是三项技术更加详细的说明
     
     )
    
    
    
     Service Workers
    
    
    HTML5 Rocks有一个对Service Workers很棒的介绍(
    
     可惜被墙了
    
    ),从那篇文章中,我发现最好的一行定义是:
    
    Service worker是一个可编程的网络代理,允许您控制页面中的网络请求是如何处理的。
    
    Service worker非常适合创建一个优秀的离线web app。当你可以的时候,它们让你与服务器交互(从服务器获取新数据,或者将更新的信息推回到服务器),这样你的应用程序就可以工作,而不管你的用户的连接情况如何。
    
    例如,一个电子邮件客户端当应用程序加载时可以读取邮件,然后,如果用户短暂地丢失了连接,应用程序仍然可以继续查看、删除已读或未读的文件、储存新的邮件,等到连接恢复时再把这些更新通过Service Worker发送到服务器。对用户来说,他们一直处于离线状态,但应用程序还在继续工作,所以看起来用户“完成了工作”,而应用程序只是通过收集更改并尽快更新到服务器上来完成它的工作。
    
    虽然Service Worker不能直接与DOM交互,但您的js代码可以基于从Service Worker那里收到的消息来实现该功能。Service Worker在没有使用时也会停止,并在需要时重新启动,因此没有持久的“状态”;您需要依赖某种本地存储来保持这种持久性。重要的是要记住Service Worker的生命周期与你的网页是完全分开的。
    
    
     Web Workers
    
    
    HTML5 Rocks有一篇对Web Workers非常好的介绍。从那篇文章中,我发现最好的一行定义是:Web Workers利用线程消息传递来实现并行性
    
    Web Workers对于任何具有强大功能的Web app来说都是非常完美的。它们让你把复杂的功能推到后台线程中,这样你的主JS就可以继续工作,比如设置事件监听器和其他UI交互。然后,当复杂的功能完成时,他们会报告他们的结果,让JS更新Web app。
    
    例如,在一系列动态图表中获取和显示数据的站点可以让每个图表通过一个独立的Web Worker获取自己的数据。而Web Worker是获取、处理、计算和数据,main JS可以设置菜单,事件监听器,初始化日期选择器和自定义的UI元素,等当每个Web Worker完成它的线程,它将携带可以用来创建它负责的图表的数据返回到main JS。
    
    当Web Worker不能直接与DOM交互时,您的mian js代码可以基于从Web Worker那里收到的消息来实现该功能。由于它们是完全独立的线程,Web Worker的代码必须存在于一个单独的文件中,并且不能访问您的mian js。Web Worker也可以产生子进程,创造额外的后台线程。
    
    
     WebSockets
    
    
    HTML5 Rocks有一篇对WebSockets非常好的介绍。从那篇文章中,我发现最好的一行定义是:客户端和服务器之间有一个持久的连接,并且双方可以在任何时候开始发送数据。
    
    WebSockets对任何需要经常与服务器进行通信、并且可以从服务器能够直接与客户沟通的web app来说是非常完美的。
    
    例如,一个聊天应用程序可以创建一个WebSocket连接,这样每个人的消息会推送至服务器,服务器又可以直接发送消息到其他在聊天中的人。这在以前的方法是使用setInterval/setTimeout+Ajax请求。但是这些方法产生了密集的循环,不得不不断地问服务器:“你还有什么东西吗?”“没有”“你还有什么东西吗?”“不知道”。。。。
    
    我们用WebSockets可以直接影响到DOM,因为他们是主线程的一部分,WebSockets做访问您的mian JS。
   
 
