Qiankun
qiankun原理
一、主要原理
通过监听路由变化，动态装载、销毁子应用。
qiankun是对single-spa的封装，在其基础上主要做了两方面的扩展
子应用的加载方式：只需配置子应用入口，自动解析并加载其资源
沙箱隔离：对JS和样式都提供了隔离机制
二、主要架构
基座：负责子应用的注册、卸载、通信
子应用
三、核心技术点
1、子应用加载
借助import-html-entry从子应用的首页（可以理解成一个静态资源表）解析出对应的静态资源进行请求，无需用户手动配置。
2、JS隔离
代理沙箱（Proxy Sandbox）
它将window上的所有属性遍历拷贝生成一个新的fakeWindow对象，紧接着使用proxy代理这个fakeWindow，用户对window操作全部被拦截下来，只作用于在这个fakeWindow之上。每个子应用分配一个fakeWindow。
快照沙箱（Snapshot Sandbox）
windowSnapshot： window对象的浅拷贝
modifyPropsMap ：存储子应用的修改
子应用mount时，先将window存储到快照windowSnapshot上，然后将子应用之前的修改modifyPropsMap（如果有的话）应用到window上；
子应用unmount时，先将当前window和快照windowSnapshot做diff，将diff结果存储到modifyPropsMap上，然后用快照windowSnapshot恢复window；
遗留沙箱（Legacy Sandbox）
3、CSS隔离
（都没有完美解决弹窗挂在到body下的问题，解决方法：子应用自行隔离）
shadow DOM
Scoped CSS
四、通信方式
基座 <=>子应用，发布订阅模式实现
onGlobalStateChange()
setGlobalState()
offGlobalStateChange()
五、qiankun VS single-spa
| 优化点 | single-spa | qiankun |
|---|---|---|
子应用加载方式 | 用户自行配置子应用的加载方式和具体资源 | 用户仅配置子应用入口 |
应用间的隔离 | 无隔离机制 | 内置了JS和CSS隔离 |
应用间的通信 | 基座通过customProps向子应用传递静态参数 | 基座和子应用通过发布订阅进行信息通信 |
六、实践中的注意点
1.本地调试
接入多个子应用时，将需要调试的那个子应用本地启动，接入链接设置成本地url，其他设置成dev环境。可以考虑用vite的env来管理接入链接。
2.样式隔离
自身提供的两种隔离方案（shadowDOM、类Scoped CSS），无法解决一些特定场景，比如一些第三方库将弹窗等挂载到子应用根结点外（一般都是body下），弹窗内的样式没法从架构层面做隔离。
3.共享依赖
比较难抽取，尤其是各个子应用依赖的同一个第三方资源的版本再有区别的话，更增加了资源抽离的难度
参考：
Last updated