关于前端:基于微前端qiankun的多页签缓存方案实践

作者：vivo 互联网前端团队 - Tang Xiao

本文梳理了基于阿里开源微前端框架 qiankun，实现多页签及子利用缓存的计划，同时还类比了多个不同计划之间的区别及优劣势，为应用微前端进行多页签开发的同学，提供一些参考。

一、多页签是什么？

咱们常见的浏览器多页签、编辑器多页签，从产品角度来说，就是为了可能实现用户拜访可记录，疾速定位工作区等作用；那对于单页利用，能够通过实现多页签，对用户的拜访记录进行缓存，从而提供更好的用户体验。

前端能够通过多种形式实现多页签，常见的计划有两种：

1. 通过 CSS 款式 display:none 来管制页面的显示暗藏模块的内容；
2. 将模块序列化缓存，通过缓存的内容进行渲染（与 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 并不能管控到其余子利用的实例，咱们须要缓存对所有的利用失效，那么只能将缓存放到基座利用中。

这个就存在几个问题：

1. 加载：主利用须要在什么时候，用什么形式来加载子利用实例？
2. 渲染：通过缓存实例来渲染子利用时，是通过 DOM 显隐形式渲染子利用还是有其余形式？
3. 通信：敞开页签时，如何判断是否齐全卸载子利用，主利用应该应用什么通信形式通知子利用？

二、计划抉择

通过在 Github issues 及掘金等平台的一系列材料查找和比照后，对于如何在 qiankun 框架下实现多页签，在不批改 qiankun 源码的前提下，次要有两种实现的思路。

2.1 计划一：多个子利用同时存在

实现思路：

在 dom 上通过 v -show 管制显示哪一个子利用，及 display:none; 管制不同子利用 dom 的显示暗藏。

url 变动时，通过 loadMicroApp 手动管制加载哪个子利用，在页签敞开时，手动调用 unmount 办法卸载子利用。

示例：

<template>
  <div id="app">
  <header>
    <router-link to="/app-vue-hash/">app-vue-hash</router-link>
    <router-link to="/app-vue-history/">app-vue-history</router-link>
    <router-link to="/about">about</router-link>
  </header>
  <div id="appContainer1" v-show="$route.path.startsWith('/app-vue-hash/')"></div>
  <div id="appContainer2" v-show="$route.path.startsWith('/app-vue-history/')"></div>
  <router-view></router-view>
</div>
</template>

<script>
import {loadMicroApp} from 'qiankun';

const apps = [
{
  name: 'app-vue-hash',
  entry: 'http://localhost:1111',
  container: '#appContainer1',
  props: {data : { store, router} }
},
{
  name: 'app-vue-history',
  entry: 'http://localhost:2222',
  container: '#appContainer2',
  props: {data : store}
}
]

export default {mounted() {
    // 优先加载以后的子项目
    const path = this.$route.path;
    const currentAppIndex = apps.findIndex(item => path.includes(item.name));
    if(currentAppIndex !== -1){const currApp = apps.splice(currentAppIndex, 1)[0];
      apps.unshift(currApp);
    }
    // loadMicroApp 返回值是 app 的生命周期函数数组
    const loadApps = apps.map(item => loadMicroApp(item))
    // 当 tab 页敞开时，调用 loadApps 中 app 的 unmount 函数即可
  },
}
</script>

具体的 DOM 展现（通过 display:none; 管制不同子利用 DOM 的显隐）：

计划劣势：

1. loadMicroApp 是 qiankun 提供的 API，能够不便疾速接入；
2. 该形式不卸载子利用，页签切换速度比拟快。

计划有余：

1. 子利用切换时不销毁 DOM，会导致 DOM 节点和事件监听过多，重大时会造成页面卡顿；
2. 子利用切换时未卸载，路由事件监听也未卸载，须要对路由变动的监听做非凡的解决。

2.2 计划二：同一时间仅加载一个子利用，同时保留其余利用的状态

实现思路：

1. 通过 registerMicroApps 注册子利用，qiankun 会通过主动加载匹配的子利用；
2. 参考 keep-alive 实现形式，每个子利用都缓存本人实例的 vnode，下次进入子利用时能够间接应用缓存的 vnode 间接渲染为实在 DOM。

计划劣势：

1. 同一时间，只是展现一个子利用的 active 页面，可缩小 DOM 节点数；
2. 非 active 子利用卸载时同时会卸载 DOM 及不须要的事件监听，可开释肯定内存。

计划有余：

1. 没有现有的 API 能够疾速实现，须要本人治理子利用缓存，实现较为简单；
2. DOM 渲染多了一个从虚构 DOM 转化为实在 DOM 的一个过程，渲染工夫会比第一种计划稍多。

vue 组件实例化过程简介

这里简略的回顾下 vue 的几个要害的渲染节点：

vue 要害渲染节点（起源：掘金社区）

compile： 对 template 进行编译，将 AST 转化后生成 render function;

render： 生成 VNODE 虚构 DOM;

patch： 将虚构 DOM 转换为实在 DOM;

因而，计划二绝对于计划一，就是多了最初 patch 的过程。

2.3 最终抉择

依据两种计划劣势与有余的评估，同时依据咱们我的项目的具体情况，最终抉择了计划二进行实现，具体起因如下：

• 过多的 DOM 及事件监听，会造成不必要的内存节约，同时咱们的我的项目次要以编辑器展现和数据展现为主，单个页签内内容较多，会更偏向于关注内存应用状况；
• 计划二在子利用二次渲染时多了一个 patch 过程，渲染速度不会慢多少，在可承受范畴内。

三、具体实现

在下面一部分咱们简略的形容了计划二的一个实现思路，其核心思想就是是通过缓存子利用实例的 vnode，那么这一部分，就来看下它的一个具体的实现的过程。

3.1 从组件级别的缓存到利用级别的缓存

在 vue 中，keep-alive 组件通过缓存 vnode 的形式，实现了组件级别的缓存，对于通过 vue 框架实现的子利用来说，它其实也是一个 vue 实例，那么咱们同样也能够做到通过缓存 vnode 的形式，实现利用级别的缓存。

通过剖析 keep-alive 源码，咱们理解到 keep-alive 是通过在 render 中进行缓存命中，返回对应组件的 vnode，并在 mounted 和 updated 两个生命周期钩子中退出对子组件 vnode 的缓存。

// keep-alive 外围代码
render () {
  const slot = this.$slots.default
  const vnode: VNode = getFirstComponentChild(slot)
  const componentOptions: ?VNodeComponentOptions = vnode && vnode.componentOptions
  if (componentOptions) {
    // 更多代码...
    // 缓存命中
    if (cache[key]) {vnode.componentInstance = cache[key].componentInstance
      // make current key freshest
      remove(keys, key)
      keys.push(key)
    } else {
      // delay setting the cache until update
      this.vnodeToCache = vnode
      this.keyToCache = key
    }
    // 设置 keep-alive，避免再次触发 created 等生命周期
    vnode.data.keepAlive = true
  }
  return vnode || (slot && slot[0])
}
// mounted 和 updated 时缓存以后组件的 vnode
mounted() {this.cacheVNode()
}
updated() {this.cacheVNode()
}

绝对于 keep-alive 须要在 mounted 和 updated 两个生命周期中对 vnode 缓存进行更新，在利用级的缓存中，咱们只须要在子利用卸载时，被动对整个实例的 vnode 进行缓存即可。

// 父利用提供 unmountCache 办法
function unmountCache() {
  // 此处永远只会保留首次加载生成的实例
  const needCached = this.instance?.cachedInstance || this.instance;
  const cachedInstance = {};
  cachedInstance._vnode = needCached._vnode;
  // keepalive 设置为必须 避免进入时再次 created，同 keep-alive 实现
  if (!cachedInstance._vnode.data.keepAlive) cachedInstance._vnode.data.keepAlive = true;
  // 省略其余代码...

  // loadedApplicationMap 用于是 key-value 模式，用于保留以后利用的实例
  loadedApplicationMap[this.cacheKey] = cachedInstance;
  // 省略其余代码...

  // 卸载实例
  this.instance.$destroy();
  // 设置为 null 后可进行垃圾回收
  this.instance = null;
}

// 子利用在 qiankun 框架提供的卸载办法中，调用 unmountCache
export async function unmount() {console.log('[vue] system app unmount');
  mainService.unmountCache();}

3.2 偷梁换柱——将 vnode 从新挂载到一个新实例上

将 vnode 缓存到内存中后，再将原有的 instance 卸载，从新进入子利用时，就能够应用缓存的 vnode 进行 render 渲染。

// 创立子利用实例，有缓存的 vnode 则应用缓存的 vnode
function newVueInstance(cachedNode) {
  const config = {
    router: this.router,
    store: this.store,
    render: cachedNode ? () => cachedNode : instance.render, // 优先应用缓存 vnode});
  return new Vue(config);
}

// 实例化子利用实例，依据是否有缓存 vnode 确定是否传入 cachedNode
this.instance = newVueInstance(cachedNode);
this.instance.$mount('#app');

那么，这里不禁就会有些疑难：

1. 如果咱们每次进入子利用时，都从新创立一个实例，那么为什么还要卸载，间接不卸载就能够了吗？
2. 将缓存 vnode 应用到一个新的实例上，不会有什么问题吗？

首先咱们答复一下第一个问题，为什么在切换子利用时，要卸载掉原来的子利用实例，有两个思考方面：

• 其一，是对内存的考量，咱们须要的其实仅仅是 vnode，而不是整个实例，缓存整个实例是计划一的实现计划，所以，咱们仅须要缓存咱们须要的对象即可；
• 其二，卸载子利用实例能够移除不必要的事件监听，比方 vue-router 对 popstate 事件就进行了监听，咱们在其余子利用操作时，并不心愿原来的子利用也对这些事件进行响应，那么在子利用卸载时，就能够移除掉这些监听。

对于第二个问题，状况会更加简单一点，上面一个局部，就次要来看下次要遇到了哪些问题，又该如何去解决。

3.3 解决利用级缓存计划的问题

3.3.1 vue-router 相干问题

• 在实例卸载后对路由变动监听生效；
• 新的 vue-router 对原有的 router params 等参数记录生效。

首先咱们须要明确这两个问题的起因：

• 第一个是因为在子利用卸载时移除了对 popstate 事件的监听，那么咱们须要做的就是从新注册对 popstate 事件的监听，这里能够通过从新实例化一个 vue-router 解决；
• 第二问题是因为通过从新实例化 vue-router 解决第一个问题之后，实际上是一个新的 vue-router，咱们须要做的就是不仅要缓存 vnode，还须要缓存 router 相干的信息。

大抵的解决实现如下：

// 实例化子利用 vue-router
function initRouter() {const { router: originRouter} = this.baseConfig;
  const config = Object.assign(originRouter, {base: `app-kafka/`,});
  Vue.use(VueRouter);
  this.router = new VueRouter(config);
}

// 创立子利用实例，有缓存的 vnode 则应用缓存的 vnode
function newVueInstance(cachedNode) {
  const config = {
    router: this.router, // 在 vue init 过程中，会从新调用 vue-router 的 init 办法，重新启动对 popstate 事件监听
    store: this.store,
    render: cachedNode ? () => cachedNode : instance.render, // 优先应用缓存 vnode});
  return new Vue(config);
}

function render() {
  if（isCache）{
    // 场景一、从新进入利用（有缓存）const cachedInstance = loadedApplicationMap[this.cacheKey];

    // router 应用缓存命中
    this.router = cachedInstance.$router;
    // 让以后路由在最后的 Vue 实例上可用
    this.router.apps = cachedInstance.catchRoute.apps;
    // 应用缓存 vnode 从新实例化子利用
    const cachedNode = cachedInstance._vnode;
    this.instance = this.newVueInstance(cachedNode);
  } else {
    // 场景二、首次加载子利用 / 从新进入利用（无缓存）this.initRouter();
    // 失常实例化
    this.instance = this.newVueInstance();}
}

function unmountCache() {
  // 省略其余代码...
  cachedInstance.$router = this.instance.$router;
  cachedInstance.$router.app = null;
  // 省略其余代码...
}

3.3.2 父子组件通信

多页签的形式减少了父子组件通信的频率，qiankun 有提供 setGlobalState 通信形式，然而在单利用模式下，同一时间仅反对和一个子利用进行通行，对于 unmount 的子利用来说，无奈接管到父利用的通信，因而，对于不同的场景，咱们须要更加灵便的通信形式。

子利用——父利用：应用 qiankun 自带通信形式；

从子到父的通信场景较为简单，个别只有路由变动时进行上报，并且仅为激活状态的子利用才会上报，可间接应用 qiankun 自带通信形式；

父利用——子利用：应用自定义事件通信；

父利用到子利用，不仅须要和 active 状态的子利用通信，还须要和以后处于缓存中子利用通信；

因而，父利用到子利用，通过自定义事件的形式，可能实现父利用和多个子利用的通信。

// 自定义事件公布
const evt = new CustomEvent('microServiceEvent', {
  detail: {action: { name: action, data},
    basePath, // 用于子利用惟一标识
  },
});
document.dispatchEvent(evt);

// 自定义事件监听
document.addEventListener('microServiceEvent', this.listener);

3.3.3 缓存治理，避免内存泄露

应用缓存最重要的事项就是对缓存的治理，在不须要的时候及时清理，这在 JS 中是十分重要但很容易被疏忽的事项。

利用级缓存

子利用 vnode、router 等属性，子利用切换时缓存；

页面级缓存

• 通过 vue-keep-alive 缓存组件的 vnode；
• 删除页签时，监听 remove 事件，删除页面对应的 vnode；
• vue-keep-alive 组件中所有缓存均被删除时，告诉删除整个子利用缓存；

3.4 整体框架

最初，咱们从整体的视角来理解下多页签缓存的实现计划。

因为不仅仅须要对子利用的缓存进行治理，还须要将 vue-keep-alive 组件注册到各个子利用中等事项，咱们将这些服务对立在主利用的 mainService 中进行治理，在 registerMicroApps 注册子利用时通过 props 传入子利用，这样就可能实现同一套代码，多处复用。

// 子利用 main.js
let mainService = null;

export async function mount(props) {
  mainService = null;
  const {MainService} = props;
  // 注册主应用服务
  mainService = new MainService({// 传入对应参数});
  // 实例化 vue 并渲染
  mainService.render(props);
}
export async function unmount() {mainService.unmountCache();
}

最初对要害流程进行梳理：

四、现有问题

4.1 临时只反对 vue 框架的实例缓存

该计划也是基于 vue 现有个性反对实现的，在 react 社区中对于多页签实现并没有对立的实现计划，笔者也没有过多的摸索，思考到现有我的项目是以 vue 技术栈为主，前期降级也会只降级到 vue3.0，在一段时间内是能够齐全反对的。

五、总结

相较于社区上大部分通过计划一进行实现，本文提供了另一种实现多页签缓存的一种思路，次要是对子利用缓存解决上有些许的不同，大抵的思路及通信的形式都是互通的。

另外本文对 qiankun 框架的应用没有做太多的发散总结，官网和 Github 上曾经有很多相干问题的总结和踩坑教训可供参考。

最初，如果文章有什么问题或谬误，欢送指出，谢谢。

参考浏览

• qiankun 微前端实际总结（二）
• [Feature Request] 主利用多页签切换不同子利用的页面状态放弃 #361
• 基于 qiankun 的微前端多页签我的项目实际与总结