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

作者｜vivo 互联网前端团队- Tang Xiao,本文梳理了基于阿里开源微前端框架qiankun，实现多页签及子应用缓存的方案，同时还类比了多个不同方案之间的区别及优劣势，为使用微前端进行多页签开发的同学，提供一些参考。,我们常见的浏览器多页签、编辑器多页签，从产品角度来说，就是为了能够实现用户访问可记录，快速定位工作区等作用；那对于单页应用，可以通过实现多页签，对用户的访问记录进行缓存，从而提供更好的用户体验。,,前端可以通过多种方式实现多页签，常见的方案有两种：,相对于第一种方式，第二种方式将DOM格式存储在序列化的JS对象当中，只渲染需要展示的DOM元素，减少了DOM节点数，提升了渲染的性能，是当前主流的实现多页签的方式。,那么相对于传统的单页面应用，通过微前端qiankun进行改造后的前端应用，在多页签上实现会有什么不同呢？,改造前的单页面应用技术栈是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自定义的拓展实现：,vue-keep-alive组件即可传入自定义方法，用于自定义vnode.key，支持同一匹配路由中派生多个实例。,qiankun是由蚂蚁金服推出的基于Single-Spa实现的前端微服务框架，本质上还是路由分发式的服务框架，不同于原本 Single-Spa采用JS Entry用的方案，qiankun采用HTML Entry 方式进行了替代优化。,使用qiankun进行微前端改造后，页面被拆分为一个基座应用和多个子应用，每个子应用都运行在独立的沙箱环境中。,,相对于单页面应用中通过keep-alive管控组件实例的方式，拆分后的各个子应用的keep-alive并不能管控到其他子应用的实例，我们需要缓存对所有的应用生效，那么只能将缓存放到基座应用中。,这个就存在几个问题：,通过在Github issues及掘金等平台的一系列资料查找和对比后，关于如何在qiankun框架下实现多页签，在不修改qiankun源码的前提下，主要有两种实现的思路。,实现思路：,示例：,具体的DOM展示（通过display:none;控制不同子应用DOM的显隐）：,,方案优势：,方案不足：,实现思路：,方案优势：,方案不足：,vue组件实例化过程简介,这里简单的回顾下vue的几个关键的渲染节点：,,vue关键渲染节点（来源：掘金社区）,因此，方案二相对于方案一，就是多了最后patch的过程。,根据两种方案优势与不足的评估，同时根据我们项目的具体情况，最终选择了方案二进行实现，具体原因如下：,在上面一部分我们简单的描述了方案二的一个实现思路，其核心思想就是是通过缓存子应用实例的vnode，那么这一部分，就来看下它的一个具体的实现的过程。,在vue中，keep-alive组件通过缓存vnode的方式，实现了组件级别的缓存，对于通过vue框架实现的子应用来说，它其实也是一个vue实例，那么我们同样也可以做到通过缓存vnode的方式，实现应用级别的缓存。,通过分析keep-alive源码，我们了解到keep-alive是通过在render中进行缓存命中，返回对应组件的vnode，并在mounted和upda,相对于keep-alive需要在mounted和updated两个生命周期中对vnode缓存进行更新，在应用级的缓存中，我们只需要在子应用卸载时，主动对整个实例的vnode进行缓存即可。,将vnode缓存到内存中后，再将原有的instance卸载，重新进入子应用时，就可以使用缓存的vnode进行render渲染。,那么，这里不禁就会有些疑问：,首先我们回答一下第一个问题，为什么在切换子应用时，要卸载掉原来的子应用实例，有两个考虑方面：,对于第二个问题，情况会更加复杂一点，下面一个部分，就主要来看下主要遇到了哪些问题，又该如何去解决。,首先我们需要明确这两个问题的原因：,大致的解决实现如下：,多页签的方式增加了父子组件通信的频率，qiankun有提供setGlobalState通信方式，但是在单应用模式下，同一时间仅支持和一个子应用进行通行，对于unmount 的子应用来说，无法接收到父应用的通信，因此，对于不同的场景，我们需要更加灵活的通信方式。,子应用——父应用：使用qiankun自带通信方式；,从子到父的通信场景较为简单，一般只有路由变化时进行上报，并且仅为激活状态的子应用才会上报，可直接使用qiankun自带通信方式；,父应用——子应用：使用自定义事件通信；,父应用到子应用，不仅需要和active状态的子应用通信，还需要和当前处于缓存中子应用通信；,因此，父应用到子应用，通过自定义事件的方式，能够实现父应用和多个子应用的通信。,使用缓存最重要的事项就是对缓存的管理，在不需要的时候及时清理，这在JS中是非常重要但很容易被忽略的事项。,应用级缓存,页面级缓存,最后，我们从整体的视角来了解下多页签缓存的实现方案。,因为不仅仅需要对子应用的缓存进行管理，还需要将vue-keep-alive组件注册到各个子应用中等事项，我们将这些服务统一在主应用的mainService中进行管理，在registerMicroApps注册子应用时通过props传入子应用，这样就能够实现同一套代码，多处复用。,,最后对关键流程进行梳理：,,该方案也是基于vue现有特性支持实现的，在react社区中对于多页签实现并没有统一的实现方案，笔者也没有过多的探索，考虑到现有项目是以vue技术栈为主，后期升级也会只升级到vue3.0，在一段时间内是可以完全支持的。,相较于社区上大部分通过方案一进行实现，本文提供了另一种实现多页签缓存的一种思路，主要是对子应用缓存处理上有些许的不同，大致的思路及通信的方式都是互通的。,另外本文对qiankun框架的使用没有做太多的发散总结，官网和Github上已经有很多相关问题的总结和踩坑经验可供参考。