关于 “微前端----乾坤” 的概念

微前端 – 乾坤

产生背景： 在 toB 的前端开发工作中，我们往往就会遇到如下困境：

1. 工程越来越大，打包越来越慢

2. 团队人员多，产品功能复杂，代码冲突频繁、影响面大

3. 技术栈单一，无法灵活扩展

微前端到底是什么？

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
微前端借鉴了微服务的架构理念，将一个庞大的前端应用拆分为多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，
再将这些小型应用联合为一个完整的应用。微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，
微前端架构下的前端仓库倾向于更小更灵活。

微前端架构模式？

基座模式

通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。

自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。

就当前而言，基座模式实施起来比较方便，方案也是蛮多的。

注册表模式

和微服务架构相似，不论是哪种微前端方式，都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口，即路由。

它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。

作用：

应用注册。即提供新的微前端应用，向应用注册表注册功能。

应用发现。让主应用可以寻找到其它应用。

Qiankun

可以去官方网站看一下用法：

qiankun官方网址

生命周期

微前端每个应用都拥有自己的生命周期：

bootstrap， 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。

Mount，应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法

Unload，删除应用的生命周期

Unmount，应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例

乾坤的一些特性？

乾坤，作为一款微前端领域的知名框架，其建立在single-spa基础上。相较于single-spa，乾坤做了两件重要的事情，其一是加载资源，第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.

css隔离，确保微应用之间样式互相不干扰。

JS沙箱，确保微应用之间 全局变量/事件 不冲突。
每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test，这个属性只能在 A 应用自己的作用域通过 window.test 获取到，主应用或者其他应用都无法拿到这个变量。

乾坤Js隔离机制（沙箱）的发展史

1、快照沙箱

const window = {};
class SnapshotSandbox {    
  windowSnapshot = {}; // 保存window快照
  modifyPropsMap = {}; // 修改的内容
  // 沙箱激活
  active() {       
    // 记录window当时的状态
    for (const prop in window) {            
      this.windowSnapshot[prop] = window[prop];        
    }        
    // 恢复上一次沙箱失活时记录的沙箱运行过程中对window做的状态改变，也就是上一次沙箱激活后对        
    window做了哪些改变，现在也保持一样的改变。
    Object.keys(this.modifyPropsMap).forEach(prop => {            
      window[prop] = this.modifyPropsMap[prop];       
    })    
  }    // 沙箱失活
  inactive() {       
    for (const prop in window) {           
    if (window[prop] !== this.windowSnapshot[prop]) {               
      // 保存运行期间的修改
      this.modifyPropsMap[prop] = window[prop];               
      // 恢复激活时的快照状态                
      window[prop] = this.windowSnapshot[prop];            
    }       
  }   
}}

2、支持多应用的代理沙箱

class ProxySandbox {    
  proxyWindow;   
  isRunning = false;    
  active() {        
    this.isRunning = true;    
  }    
  inactive() {        
    this.isRunning = false;    
  }    
  constructor() {        
    const fakeWindow = Object.create(null);        
    this.proxyWindow = new Proxy(fakeWindow, {            
      set: (target, prop, value, receiver) => {                
        if (this.isRunning) {                    
          target[prop] = value;                
        }            
      },            
      get: (target, prop, receiver) => {                
        return prop in target ? target[prop] : window[prop];            
      }        
    });    
  }}
 // 验证：
let proxySandBox1 = new ProxySandBox();
let proxySandBox2 = new ProxySandBox();
proxySandBox1.active();
proxySandBox2.active();
proxySandBox1.proxyWindow.city = 'Beijing';
proxySandBox2.proxyWindow.city = 'Shanghai';
console.log('active:proxySandBox1:window.city:', proxySandBox1.proxyWindow.city);
console.log('active:proxySandBox2:window.city:', proxySandBox2.proxyWindow.city);
console.log('window:window.city:', window.city);
proxySandBox1.inactive();
proxySandBox2.inactive();
console.log('inactive:proxySandBox1:window.city:', proxySandBox1.proxyWindow.city);
console.log('inactive:proxySandBox2:window.city:', proxySandBox2.proxyWindow.city);
console.log('window:window.city:', window.city);
// ProxySandbox，完全不存在状态恢复的逻辑，同时也不需要记录属性值的变化，因为所有的变化都是沙箱内部的变化，和window没有关系，window上的属性至始至终都没有受到过影响。

💪 HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单。

JS Entry是什么？？
在使用 single-spa 加载微应用时，我们加载的不是微应用本身，而是微应用导出的 JS 文件，即JS Entry。

要接入一个微应用，就需要对微应用进行一系列的改造，然而 JS Entry 的问题就出在这儿，改造时对微应用的侵入行太强，而且和主应用的耦合性太强。

微应用改造一般分为三步：

l 微应用路由改造，添加一个特定的前缀

l 微应用入口改造，挂载点变更和生命周期函数导出

在js文件的入口中会导出一个对象，这个对象上有 bootstrap、mount、unmount 这三个接入 single-spa 框架必须提供的生命周期方法，其中 mount 方法规定了微应用应该怎么挂载到主应用提供的容器节点上。

l 打包工具配置更改

侵入型强其实说的就是第三点，更改打包工具的配置，使用 single-spa 接入微应用需要将微应用整个打包成一个 JS 文件，发布到静态资源服务器，然后在主应用中配置该 JS 文件的地址告诉 single-spa 去这个地址加载微应用。这就导致常见的打包优化基本上都没了，比如：按需加载、首屏资源加载优化、css 独立打包等优化措施。

项目发布以后出现了 bug ，修复之后需要更新上线，为了清除浏览器缓存带来的应用，一般文件名会带上 chunkcontent，微应用发布之后文件名都会发生变化，这时候还需要更新主应用中微应用配置，然后重新编译主应用然后发布，这套操作简直是不能忍受的。这也是 这也是 微前端框架 之 single-spa 从入门到精通 这篇文章中示例项目中微应用发布时的环境配置选择 development 的原因。

qiankun 框架为了解决 JS Entry 的问题，于是采用了 HTML Entry 的方式，让用户接入微应用就像使用 iframe 一样简单。

DEMO：

https://github.com/sy-l123/qiankun-demo