乾坤的JS沙箱机制

single-spa有什么缺陷？

是通过路由来区分哪个微应用的，本身就不支持多个微应用，后来有parsal概念可以同时手动去支持多个微应用

• 资源加载过程繁琐需要手动处理

• 需要手动处理资源隔离(css资源、js资源)

为什么要有JS资源隔离机制

• 主应用和子应用，相同的全局变量可能发生冲突

• 子应用和子应用之间，相同的全局变量，可能冲突

乾坤的JS隔离机制有哪三种？

• 支持单个微应用的方案一：SnapshotSandBox 快照沙箱，因为兼容性非常好，所以还有用武之地

• 支持单个微应用的方案二：LegacySandBox 支持单微应用的代理沙箱，功能被proxySandBox覆盖，可能会被逐渐淘汰

• 支持同时激活多个微应用的方案：PrxoySandBox 支持多微应用的代理沙箱，主流

SnapshotSandBox

1. active

   1. 保存当前window对象上所有属性的状态

   2. 恢复上一次运行该微应用的时候所修改过的window上的属性

2. inactive

   1. 记录修改了window上的那些属性

   2. 将window上的属性状态还原至微应用运行之前的状态

3. 问题

   1. window上属性非常多，导致性能低

   2. 且给window赋值，直接影响全局，不能支持多个微应用处于激活状态

LegacySandBox

也是最终在window上操作，但修改是在proxyWindow上直接修改

1. active

   1. 恢复上次一该微应用处于运行状态时候对wndow上做的所有修改

2. inactive

   1. 还原window上原有的属性

3. 优缺点：优点是不需要遍历window上所有的属性，性能良好；缺点是同一时间只能激活一个微应用

PrxoySandBox

设置值的时候不在window上设置，取值的时候如果proxyWindow上没有再从window上取，不同应用的fakeWindow不同，不会互相影响，所以可以同时支持多个微应用同时运行。非常高效的方法。

优势：优点是不需要遍历window上所有的属性，性能良好；同一时间可以激活多个微应用，互不冲突互不干扰