|
TML5 正式推荐标准发布以来，HTML5 增加了越来越多强大的特性和功能，而在这其中，工作线程(Web Worker)概念的推出让人眼前一亮，但未曾随之激起多大的浪花，并被在其随后工程侧的 Angular、Vue、React 等框架的「革命」浪潮所淹没。当然，我们总会偶然看过一些文章介绍，或出于学习的目的做过一些应用场景下的练习，甚或在实际项目中的涉及大量数据计算场景中真的使用过。但相信也有很多人和我一样茫然，找不到这种高大上的技术在实际项目场景中能有哪些能起到广泛作用的应用。
究其原因，Web Worker 独立于 UI 主线程运行的特性使其被大量考虑进行性能优化方面的尝试(比如一些图像分析、3D 计算绘制等场景)，以保证在进行大量计算的同时，页面对用户能有及时的响应。而这些性能优化的需求在前端侧一方面涉及频率低，另一方面也能通过微任务或服务端侧处理来解决，它并不能像 Web Socket 这种技术为前端页面下的轮询场景的优化能带来质的改变。
直至 2019 年爆火的微前端架构的出现，基于微应用间 JavaScript 沙箱隔离的需求，Web Worker 才得以重新从边缘化的位置跃入到我的中心视野。根据我已经了解到的 Web Worker 的相关知识，我知道了 Web Worker 是工作在一个独立子线程下(虽然这个子线程比起 Java 等编译型语言的子线程实现得还有点弱，如无法加锁等)，线程之间自带隔离的特性，那基于这种「物理」性的隔离，能不能实现 JavaScript 运行时的隔离呢?
本文接下来的内容，将介绍我在探索基于 Web Worker 实现 JavaScript 沙箱隔离方案过程中的一些资料收集、理解以及我的踩坑和思考的过程。虽然可能整篇文章内容都在「炒冷饭」，但还是希望我的探索方案的过程能对正在看这篇文章的你有所帮助。
JavaScript 沙箱
在探索基于 Web Worker 的解决方案之前，我们先要对当前要解决的问题——JavaScript 沙箱有所了解。
提到沙箱，我会先想到出于兴趣玩过的沙盒游戏，但我们要探索的 JavaScript 沙箱不同于沙盒游戏，沙盒游戏注重对世界基本元素的抽象、组合以及物理力系统的实现等，而 JavaScript 沙箱则更注重在使用共享数据时对操作状态的隔离。
在现实与 JavaScript 相关的场景中，我们知道平时使用的浏览器就是一个沙箱，运行在浏览器中的 JavaScript 代码无法直接访问文件系统、显示器或其他任何硬件。Chrome 浏览器中每个标签页也是一个沙箱，各个标签页内的数据无法直接相互影响，接口都在独立的上下文中运行。而在同一个浏览器标签页下运行 HTML 页面，有哪些更细节的、对沙箱现象有需求的场景呢?
当我们作为前端开发人员较长一段时间后，我们很轻易地就能想到在同一个页面下，使用沙箱需求的诸多应用场景，譬如：
-
执行从不受信的源获取到的第三方 JavaScript 代码时(比如引入插件、处理 jsonp 请求回来的数据等)。
-
在线代码编辑器场景(比如著名的 codesandbox)。
-
使用服务端渲染方案。
-
模板字符串中的表达式的计算。
-
... ...
这里我们先回到开头，先将前提假设在我正在面对的微前端架构设计下。在微前端架构(推荐文章 Thinking in Microfrontend 、拥抱云时代的前端开发架构——微前端 等)中，其最关键的一个设计便是各个子应用间的调度实现以及其运行态的维护，而运行时各子应用使用全局事件监听、使全局 CSS 样式生效等常见的需求在多个子应用切换时便会成为一种污染性的副作用，为了解决这些副作用，后来出现的很多微前端架构(如 乾坤)有着各种各样的实现。譬如 CSS 隔离中常见的命名空间前缀、Shadow DOM、 乾坤 sandbox css 的运行时动态增删等，都有着确实行之有效的具体实践，而这里最麻烦棘手的，还是微应用间的 JavaScript 的沙箱隔离。
（编辑：东莞站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
