基于微前端qiankun的多页签缓存方案实践
本文梳理了基于阿里开源微前端框架qiankun，实现多页签及子应用缓存的方案，同时还类比了多个不同方案之间的区别及优劣势，为使用微前端进行多页签开发的同学，提供一些参考。
一、多页签是什么？
我们常见的浏览器多页签、编辑器多页签，从产品角度来说，就是为了能够实现用户访问可记录，快速定位工作区等作用；那对于单页应用，可以通过实现多页签，对用户的访问记录进行缓存，从而提供更好的用户体验。
前端可以通过多种方式实现多页签，常见的方案有两种：
- 通过CSS样式display:none来控制页面的显示隐藏模块的内容；
- 将模块序列化缓存，通过缓存的内容进行渲染（与vue的keep-alive原理类似，在单页面应用中应用广泛）。
相对于第一种方式，第二种方式将DOM格式存储在序列化的JS对象当中，只渲染需要展示的DOM元素，减少了DOM节点数，提升了渲染的性能，是当前主流的实现多页签的方式。
那么相对于传统的单页面应用，通过微前端qiankun进行改造后的前端应用，在多页签上实现会有什么不同呢？
1.1 单页面应用实现多页签
改造前的单页面应用技术栈是Vue全家桶(vue2.6.10 + element2.15.1 + webpack4.0.0+vue-cli4.2.0)。
vue框架提供了keep-alive来支持缓存相关的需求，使用keep-alive即可实现多页签的基本功能，但是为了支持更多的功能，我们在其基础上重新封装了vue-keep-alive组件。
相对较于keep-alive通过include、exclude对缓存进行控制，vue-keep-alive使用更原生的发布订阅方式来删除缓存，可以实现更完整的多页签功能，例如同个路由可以根据参数的不同派生出多个路由实例（如打开多个详情页页签）以及动态删除缓存实例等功能。
下面是vue-keep-alive自定义的拓展实现：
created() {
// 动态删除缓存实例监听
this.cache = Object.create(null);
breadCompBus.$on('removeTabByKey', this.removeCacheByKey);
breadCompBus.$on('removeTabByKeys', (data) => {
data.forEach((item) => {
this.removeCacheByKey(item);
});
});
}
vue-keep-alive组件即可传入自定义方法，用于自定义vnode.key，支持同一匹配路由中派生多个实例。
// 传入`vue-keep-alive`的自定义方法
function updateComponentsKey(key, name, vnode) {
const match = this.$route.matched[1];
if (match && match.meta.multiNodeKey) {
vnode.key = match.meta.multiNodeKey(key, this.$route);
return vnode.key;
}
return key;
}
1.2 使用qiankun进行微前端改造后，多页签缓存有什么不同
qiankun是由蚂蚁金服推出的基于Single-Spa实现的前端微服务框架，本质上还是路由分发式的服务框架，不同于原本 Single-Spa采用JS Entry用的方案，qiankun采用HTML Entry 方式进行了替代优化。
使用qiankun进行微前端改造后，页面被拆分为一个基座应用和多个子应用，每个子应用都运行在独立的沙箱环境中。
相对于单页面应用中通过keep-alive管控组件实例的方式，拆分后的各个子应用的keep-alive并不能管控到其他子应用的实例，我们需要缓存对所有的应用生效，那么只能将缓存放到基座应用中。
这个就存在几个问题：
- 加载：主应用需要在什么时候，用什么方式来加载子应用实例？
- 渲染：通过缓存实例来渲染子应用时，是通过DOM显隐方式渲染子应用还是有其他方式？
- 通信：关闭页签时，如何判断是否完全卸载子应用，主应用应该使用什么通信方式告诉子应用？
二、方案选择
通过在Github issues及掘金等平台的一系列资料查找和对比后，关于如何在qiankun框架