Web Workers实践（2）

What’s the WebWorkers？

2008 年 W3C 制定出第一个 HTML5 草案中提出了工作线程（Web Worker）的概念，并且规范出 Web Worker 的三大主要特征：能够长时间运行（响应），理想的启动性能以及理想的内存消耗。Web Worker 允许开发人员编写能够长时间运行而不被用户所中断的后台程序，去执行事务或者逻辑，并同时保证页面对用户的及时响应。

Web Workers类型有哪些？

• 专用线程（Dedicated Workers） 由主线程创建，并且只能和主线程通信。相当于每一次创建都是一个新的实例。
• 共享线程（Shared Workers） 在同一域名下，可以和任何进程通信（不同的Tabs，iFrames等）。可以理解为第一次创建就是在浏览器中停驻，类似一个MemoryCache，此后如果其他页面需要创建该实例时，都会引用同一个Worker，成为跨进程的单例。
• 后台线程（Service Workers） 2014年推出的新规范，该API可以提供后台服务的能力，比如后台消息传递，代理伪装，离线，消息推送等有意思的功能。本人测试Chrome下支持，但IE下日常（不支持）。

Web Workers可以干什么？

JavaScript是异步的单线程，通过时间片轮换模拟并发效果（可参考之前写的《Web Workers实践》）。随着移动互联网以及带宽的提高，而HTML5提供了前端渲染的诸多好处（效果效率灵活轻量级），前端需要处理越来越多的数据，传输和解析也成为了一个很大的瓶颈。Workers+Promise绝对让你爽歪歪。下面举两个很实际的场景，让各位有一个清楚的认识。

应用场景1：后台计算能力

通过Worker将大量数据分析，统计的工作放到后台进行。比如为了减少文件大小，我们往往会做一次zip压缩，好处很明显，既可以加密，有可以极大的提高网络传输的速度。但在传统的JS中，zip解压缩的性能损失是巨大的。随着技术的发展，鱼和熊掌也是可以兼得的。通过Workers技术，我们把数据的解压缩和解析的工作交给子线程来处理，减轻主线程的负担。如下，现在我们可以将Update放到Workers线程，主线程专注Render以及和用户的交互。

应用场景2：共享线程代理多用户

通过共享Worker，可以在多个进程中共用一个线程，接收从不同连接发送过来的指令，然后实现自己的指令处理逻辑，指令处理完成后将结果返回到各个不同的连接用户。有了这种代理技术，可以衍生出很多有意思的功能，在代理中对参数安全性进行审核，对并发数统计，用户自定义的JS函数的权限管理等，都可以通过子线程加一层壳来进行过滤。

性能至上

任何的技术都是有消耗的，关键在于技术人员针对自身情况，做出一个合理选择，这取决于经验和对各种因素全面的衡量。下面给出一些关键时间消耗，供各位选择。

• Workers的创建一般都在1ms内，可以忽略不计
• PostMessage时间 不同浏览器差异较大，Chrome下80ms左右，而IE只有25ms 理论讲，如果Worker创建后调用PostMessage，此时PostMessage事件会放在请求队列，而此后的PostMessage则会直接在WebCore中响应，也就是首次事件可能时间要略久，但测试发现这种差异不并不存在或不明显。
• OnMessage 各个浏览器中时间消耗很小，忽略不计。
• Transferring 默认的参数都是Copy形式，如果参数对象很大，而且在线程中并不修改该对象值，则可以使用Transferring，则参数为引用形式。否则参数拷贝会消耗大量时间。
• 创建多个Workers后的性能 未测试具体时间，但在真实应用中体验很不错

缺点

Workers下不支持DOM对象，不支持Mutex，并不是一种彻底的多线程方案。个人认为Workers主要是把数据部分的工作放到线程，提供后台计算能力，让主线程和子线程更好的专注自己的工作，提高每个线程的性能。

Service Workers需要HTTPS才能使用，localhost除外，这太不实用。导致这一有意思的功能只能玩玩而已。