2008 年 W3C 制定出第一个 HTML5 草案中提出了工作线程(Web Worker)的概念,并且规范出 Web Worker 的三大主要特征:能够长时间运行(响应),理想的启动性能以及理想的内存消耗。Web Worker 允许开发人员编写能够长时间运行而不被用户所中断的后台程序,去执行事务或者逻辑,并同时保证页面对用户的及时响应。
JavaScript是异步的单线程,通过时间片轮换模拟并发效果(可参考之前写的《Web Workers实践》)。随着移动互联网以及带宽的提高,而HTML5提供了前端渲染的诸多好处(效果效率灵活轻量级),前端需要处理越来越多的数据,传输和解析也成为了一个很大的瓶颈。Workers+Promise绝对让你爽歪歪。下面举两个很实际的场景,让各位有一个清楚的认识。
应用场景1:后台计算能力
通过Worker将大量数据分析,统计的工作放到后台进行。比如为了减少文件大小,我们往往会做一次zip压缩,好处很明显,既可以加密,有可以极大的提高网络传输的速度。但在传统的JS中,zip解压缩的性能损失是巨大的。随着技术的发展,鱼和熊掌也是可以兼得的。通过Workers技术,我们把数据的解压缩和解析的工作交给子线程来处理,减轻主线程的负担。如下,现在我们可以将Update放到Workers线程,主线程专注Render以及和用户的交互。
应用场景2:共享线程代理多用户
通过共享Worker,可以在多个进程中共用一个线程,接收从不同连接发送过来的指令,然后实现自己的指令处理逻辑,指令处理完成后将结果返回到各个不同的连接用户。有了这种代理技术,可以衍生出很多有意思的功能,在代理中对参数安全性进行审核,对并发数统计,用户自定义的JS函数的权限管理等,都可以通过子线程加一层壳来进行过滤。
任何的技术都是有消耗的,关键在于技术人员针对自身情况,做出一个合理选择,这取决于经验和对各种因素全面的衡量。下面给出一些关键时间消耗,供各位选择。
Workers下不支持DOM对象,不支持Mutex,并不是一种彻底的多线程方案。个人认为Workers主要是把数据部分的工作放到线程,提供后台计算能力,让主线程和子线程更好的专注自己的工作,提高每个线程的性能。
Service Workers需要HTTPS才能使用,localhost除外,这太不实用。导致这一有意思的功能只能玩玩而已。