作者:vivo 互联网前端团队- Tang Xiao
本文梳理了基于阿里开源微前端框架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,支持同一匹配路由中派生多个实例。
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 框架下实现多页签,在不修改qiankun 源码的前提下,主要有两种实现的思路。
2.1 方案一:多个子应用同时存在
实现思路:
示例:
<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); } const loadApps = apps.map(item => loadMicroApp(item)) }, } </script >
具体的DOM 展示(通过display:none; 控制不同子应用DOM的显隐):
方案优势:
loadMicroApp 是qiankun 提供的API,可以方便快速接入;
该方式不卸载子应用,页签切换速度比较快。
方案不足:
子应用切换时不销毁DOM ,会导致DOM 节点和事件监听过多,严重时会造成页面卡顿;
子应用切换时未卸载,路由事件监听也未卸载,需要对路由变化的监听做特殊的处理。
2.2 方案二:同一时间仅加载一个子应用,同时保存其他应用的状态
实现思路:
方案优势:
方案不足:
vue组件实例化过程简介
这里简单的回顾下vue 的几个关键的渲染节点:
vue关键渲染节点(来源:掘金社区 )
因此,方案二相对于方案一,就是多了最后patch 的过程。
2.3 最终选择
根据两种方案优势与不足的评估,同时根据我们项目的具体情况,最终选择了方案二进行实现,具体原因如下:
在上面一部分我们简单的描述了方案二的一个实现思路,其核心思想就是是通过缓存子应用实例的vnode ,那么这一部分,就来看下它的一个具体的实现的过程。
3.1 从组件级别的缓存到应用级别的缓存
在vue 中,keep-alive 组件通过缓存vnode 的方式,实现了组件级别的缓存,对于通过vue 框架实现的子应用来说,它其实也是一个vue 实例,那么我们同样也可以做到通过缓存vnode的方式,实现应用级别的缓存。
通过分析keep-alive 源码,我们了解到keep-alive是通过在render 中进行缓存命中,返回对应组件的vnode ,并在mounted 和updated 两个生命周期钩子中加入对子组件vnode 的缓存。
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 remove(keys, key) keys.push(key) } else { this .vnodeToCache = vnode this .keyToCache = key } vnode.data .keepAlive = true } return vnode || (slot && slot[0 ]) } mounted() { this .cacheVNode() } updated() { this .cacheVNode() }
相对于keep-alive 需要在mounted 和updated 两个生命周期中对vnode 缓存进行更新,在应用级的缓存中,我们只需要在子应用卸载时,主动对整个实例的vnode 进行缓存即可。
function unmountCache ( ) { const needCached = this .instance?.cachedInstance || this .instance; const cachedInstance = {}; cachedInstance._vnode = needCached._vnode; if (!cachedInstance._vnode.data.keepAlive) cachedInstance._vnode.data.keepAlive = true ; loadedApplicationMap[this .cacheKey] = cachedInstance; this .instance.$destroy(); this .instance = null ; } export async function unmount ( ) { console .log('[vue] system app unmount' ); mainService.unmountCache(); }
3.2 移花接木——将vnode重新挂载到一个新实例上
将vnode 缓存到内存中后,再将原有的instance 卸载,重新进入子应用时,就可以使用缓存的vnode 进行render 渲染。
function newVueInstance (cachedNode ) { const config = { router : this .router, store : this .store, render : cachedNode ? () => cachedNode : instance.render, }); return new Vue(config); } this .instance = newVueInstance(cachedNode);this .instance.$mount('#app' );
那么,这里不禁就会有些疑问:
如果我们每次进入子应用时,都重新创建一个实例,那么为什么还要卸载,直接不卸载就可以了吗?
将缓存vnode 使用到一个新的实例上,不会有什么问题吗?
首先我们回答一下第一个问题,为什么在切换子应用时,要卸载掉原来的子应用实例,有两个考虑方面:
对于第二个问题,情况会更加复杂一点,下面一个部分,就主要来看下主要遇到了哪些问题,又该如何去解决。
3.3 解决应用级缓存方案的问题
3.3.1 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); } function newVueInstance (cachedNode ) { const config = { router : this .router, store: this .store, render : cachedNode ? () => cachedNode : instance.render, }); return new Vue(config); } function render ( ) { if (isCache) { const cachedInstance = loadedApplicationMap[this .cacheKey]; this .router = cachedInstance.$router; this .router.apps = cachedInstance.catchRoute.apps; 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 传入子应用,这样就能够实现同一套代码,多处复用。
let mainService = null ;export async function mount (props ) { mainService = null ; const { MainService } = props; mainService = new MainService({ }); mainService.render(props); } export async function unmount ( ) { mainService.unmountCache(); }
最后对关键流程进行梳理:
4.1 暂时只支持vue框架的实例缓存
该方案也是基于vue现有特性支持实现的,在react社区中对于多页签实现并没有统一的实现方案,笔者也没有过多的探索,考虑到现有项目是以vue 技术栈为主,后期升级也会只升级到vue3.0 ,在一段时间内是可以完全支持的。
相较于社区上大部分通过方案一进行实现,本文提供了另一种实现多页签缓存的一种思路,主要是对子应用缓存处理上有些许的不同,大致的思路及通信的方式都是互通的。
另外本文对qiankun 框架的使用没有做太多的发散总结,官网和Github 上已经有很多相关问题的总结和踩坑经验可供参考。
最后,如果文章有什么问题或错误,欢迎指出,谢谢。
参考阅读