首发于前端自习室
【微前端】qiankun 到底是个什么鬼

【微前端】qiankun 到底是个什么鬼

前言

在上一篇文章【微前端】single-spa 到底是个什么鬼 聊到了 single-spa 这个框架仅仅实现了子应用的生命周期的调度以及 url 变化的监听。微前端的一个特点都没有实现，严格来说算不上微前端框架。

今天就来聊一个真正的微前端框架：qiankun。同样地，本文不会教大家怎么实现一个 Demo，因为官方的 Github 已经有一个很好的 Demo 了，如果你觉得官网的 Demo 太复杂了，也可以看我自己实现的小 Demo。

qiankun 到底做了什么

首先，qiankun 并不是单一个框架，它在 single-spa 基础上添加更多的功能。以下是 qiankun 提供的特性：

  • 实现了子应用的加载，在原有 single-spa 的 JS Entry 基础上再提供了 HTML Entry
  • 样式和 JS 隔离
  • 更多的生命周期：beforeMount, afterMount, beforeUnmount, afterUnmount
  • 子应用预加载
  • 全局状态管理
  • 全局错误处理

接下来不会一个特性一个特性地讲，因为这样会很无聊，讲完你也只能知道这是个啥，不能深入了解是怎么来的。所以我更愿意聊一下这些特性是怎么来的，它们是怎么被想到的。

多入口

先复习一下 single-spa 是怎么注册子应用的：

singleSpa.registerApplication(
  'appName',
  () => System.import('appName'),
  location => location.pathname.startsWith('appName'),
);

可以看到 single-spa 采用 JS Entry 的方式接入微应用，也即：输出一个 JS，然后 bootstrap, mount, unmount 函数。

但是事件并没有这么简单：我们项目一般都会将静态资源放到 CDN 上来加速。为了不受缓存的影响，我们还会将 JS 文件命名成 contenthash 的乱码文件名： jlkasjfdlkj.jalkjdsflk.js。这样一来，每次子应用一发布，入口 JS 文件名肯定又要改了，导致主应用引入的 JS url 又得改了。麻烦！

打包成单个 JS 文件的另一个问题就是打包的优化都没了：按需加载、首屏资源加载优化、css 独立打包等优化措施全 ️。

很多时候，子应用一般都已经是线上的应用了，比如 abcd.com。微前端融合多个子应用本质上不就是融合多个 HTML 嘛？那为什么不给你子应用的 HTML，主应用就自动接入收工了呢？操作起来应该和在 <iframe/> 和插入 src 是一样的才对味。

这种通过提供 HTML 入口来接入子应用的方式就叫 HTML Entry。 qiankun 的一大亮点就是提供了 HTML Entry，在调用 qiankun 的注册子应用函数时可以这么写：

registerMicroApps([
  {
    name: 'react app', // 子应用名
    entry: '//localhost:7100', // 子应用 html 或网址
    container: '#yourContainer', // 挂载容器选择器
    activeRule: '/yourActiveRule', // 激活路由
  },
]);

start(); // Go

用起来毫不费力，只需要在 JS 入口加上 single-spa 的生命周期钩子，再发布就可以直接接入了。

import-html-entry

然而，HTML Entry 并不是给个 HTML 的 url 就可以直接接入整个子应用这么简单了。子应用的 HTML 文件就是一堆乱七八糟的标签文本。<link>, <style>, <script> 得处理吧？要写正则表达式吧？头要秃了吧？

所以 qiankun 的作者自己也写了一个专门处理 HTML Entry 这种需求的 NPM 包：import-html-entry。用法如下：

import importHTML from 'import-html-entry';

importHTML('./subApp/index.html')
  .then(res => {
    console.log(res.template); // 拿到 HTML 模板

    res.execScripts().then(exports => { // 执行 JS 脚本
      const mobx = exports; // 获取 JS 的输出内容
      // 下面就是拿到 JS 入口的内容，并用来做一些事
      const { observable } = mobx;
      observable({
        name: 'kuitos'
      })    
    })
});

当然，qiankun 已经将 import-html-entry 与子应用加载函数完美地结合起来，大家只需要知道这个库是用来获取 HTML 模板内容，Style 样式和 JS 脚本内容就可以了。

有了上面的了解后，相信大家对于如何加载子应用就有思路了，伪代码如下：

// 解析 HTML，获取 html，js，css 文本
const {htmlText, jsText, cssText} = importHTMLEntry('https://xxxx.com')

// 创建容器
const $= document.querySelector(container)
$container.innerHTML = htmlText

// 创建 style 和 js 标签
const $style = createElement('style', cssText)
const $script = createElement('script', jsText)

$container.appendChild([$style, $script])

在第三步，我们不禁有个疑问：当前这个应用完美地插入了 style 和 script 标签，那下一个应用 mount 时就会被前面的 style 和 script 污染了呀。

为了解决这两个问题，不得不做好应用之间的样式和 JS 的隔离。

样式隔离

qiankun 实现 single-spa 推荐的两种样式隔离方案：ShadowDOM 和 Scoped CSS。

先来说说 ShadowDOM，qiankun 的源码实现也很简单，只是添加一个 Shadow DOM 节点，伪代码如下：

if (strictStyleIsolation) {
    if (!supportShadowDOM) {
      // 报错
      // ...
    } else {
      // 清除原有的内容
      const { innerHTML } = appElement;
      appElement.innerHTML = '';

      let shadow: ShadowRoot;

      if (appElement.attachShadow) {
        // 添加 shadow DOM 节点
        shadow = appElement.attachShadow({ mode: 'open' });
      } else {
        // deprecated 的操作
        // ...
      }
      // 在 shadow DOM 节点添加内容
      shadow.innerHTML = innerHTML;
    }
  }

通过 Shadow DOM 的天然的隔离特性来实现子应用间的样式隔离。

另一个方案就是 Scoped CSS 了，说白了就是通过修改 CSS 选择器来实现子应用间的样式隔离。 比如，你有这样的 CSS 代码：

.container {
  background: red;
}

div {
  color: red;
}

qiankun 会扫描给定的 CSS 文本，通过正则匹配在选择器前加上子应用的名字，如果遇到元素选择器，就加一个爸爸类名给它，比如：

.subApp.container {
  background: red;
}

.subApp div {
  color: red;
}

JS 隔离

第一步要隔离的是对全局对象 window 上的变量进行隔离。不能 A 子应用 window.setTimeout = undefined 之后， B 子应用用 setTimeout 的时候就凉了。

所以 JS 隔离深一层本质就是记录当前 window 对象以前的值，在 A 子应用进来时一顿乱搞之后，要将所有值都恢复过来（恢复现场）。这就是 SnapshotSandbox 的做法，伪代码如下：

class SnapshotSandbox {
  ...

  active() {
    // 记录当前快照
    this.windowSnapshot = {} as Window;
    getKeys(window).forEach(key => {
      this.windowSnapshot[key] = window[key];
    })

    // 恢复之前的变更
    getKeys(this.modifyPropsMap).forEach((key) => {
      window[key] = this.modifyPropsMap[key];
    });

    this.sandboxRunning = true;
  }

  inactive() {
    this.modifyPropsMap = {};

    // 记录变更，恢复环境
    getKeys(window).forEach((key) => {
      if (window[key] !== this.windowSnapshot[key]) {
        this.modifyPropsMap[key] = window[key];
        window[key] = this.windowSnapshot[key];
      }
    });

    this.sandboxRunning = false;
  }
}

除了 SnapShotSandbox，qiankun 还提供了一种使用 ES 6 Proxy 实现的沙箱：

class SingularProxySandbox {
  /** 沙箱期间新增的全局变量 */
  private addedPropsMapInSandbox = new Map<PropertyKey, any>();

  /** 沙箱期间更新的全局变量 */
  private modifiedPropsOriginalValueMapInSandbox = new Map<PropertyKey, any>();

  /** 持续记录更新的(新增和修改的)全局变量的 map，用于在任意时刻做 snapshot */
  private currentUpdatedPropsValueMap = new Map<PropertyKey, any>();

  active() {
    if (!this.sandboxRunning) {
      // 恢复子应用修改过的值
      this.currentUpdatedPropsValueMap.forEach((v, p) => setWindowProp(p, v));
    }

    this.sandboxRunning = true;
  }

  inactive() {
    // 恢复加载子应用前的 window 值
    this.modifiedPropsOriginalValueMapInSandbox.forEach((v, p) => setWindowProp(p, v));
    // 删掉子应用期间新加的 window 值 
    this.addedPropsMapInSandbox.forEach((_, p) => setWindowProp(p, undefined, true));

    this.sandboxRunning = false;
  }

  constructor(name: string) {
    this.name = name;
    this.type = SandBoxType.LegacyProxy;
    const { addedPropsMapInSandbox, modifiedPropsOriginalValueMapInSandbox, currentUpdatedPropsValueMap } = this;

    const rawWindow = window;
    const fakeWindow = Object.create(null) as Window;

    const proxy = new Proxy(fakeWindow, {
      set: (_: Window, key: PropertyKey, value: any): boolean => {
        if (this.sandboxRunning) {
          if (!rawWindow[key]) {
            addedPropsMapInSandbox.set(key, value); // 将沙箱期间新加的值记录下来
          } else if (!modifiedPropsOriginalValueMapInSandbox.has(key)) {
            modifiedPropsOriginalValueMapInSandbox.set(key, rawWindow[key]); // 记录沙箱前的值
          }

          currentUpdatedPropsValueMap.set(key, value); // 记录沙箱后的值

          // 必须重新设置 window 对象保证下次 get 时能拿到已更新的数据
          (rawWindow as any)[key] = value;
        }
      },

      get(_: Window, key: PropertyKey): any {
        return rawWindow[key]
      },
    }
  }
}

两者差不太多，那怎么不直接用 Proxy 高级方案呢，因为在一些低版本的浏览器下是没有 Proxy 对象的，所以 SnapshotSandbox 其实是 SingularProxySandbox 的降级方案。

然而，问题还是没有解决完。上面这种情况仅适用于一个页面只有一个子应用的情况，这种情况也被称为单例（singular mode）。 如果一个页面有多个子应用那一个 SingluarProxySandbox 明显不够的。为了解决这个问题，qiankun 提供了 ProxySandbox，伪代码如下：

class ProxySandbox {
  ...

  active() { // +1 废话
    if (!this.sandboxRunning) activeSandboxCount++;
    this.sandboxRunning = true;
  }

  inactive() { // -1 废话
    if (--activeSandboxCount === 0) {
      variableWhiteList.forEach((p) => {
        if (this.proxy.hasOwnProperty(p)) {
          delete window[p]; // 删除白名单里子应用添加的值
        }
      });
    }

    this.sandboxRunning = false;
  }

  constructor(name: string) {
    ...
    const rawWindow = window; // 原 window 对象
    const { fakeWindow, propertiesWithGetter } = createFakeWindow(rawWindow); // 将真 window 上的 key-value 复制到假 window 对象上

    const proxy = new Proxy(fakeWindow, { // 代理复制出来的 window
      set: (target: FakeWindow, key: PropertyKey, value: any): boolean => {
        if (this.sandboxRunning) {
          target[key] = value // 修改 fakeWindow 上的值

          if (variableWhiteList.indexOf(key) !== -1) {
            rawWindow[key] = value; // 白名单的话，修改真 window 上的值
          }

          updatedValueSet.add(p); // 记录修改的值
        }
      },

      get(target: FakeWindow, key: PropertyKey): any {
        return target[key] || rawWindow[key] // 在 fakeWindow 上找，找不到从直 window 上找
      },
    }
  }
}

从上面可以看到，在 active 和 inactive 里并没有太多在恢复现场操作，因为只要子应用 unmount，把 fakeWindow 一扔掉就完事了。

等等，说了这么多上面还只是讨论 window 对象的隔离呀，格局是不是小了点？是小了。

沙箱

现在我们再来审视一下沙箱这个玩意，其实无论沙箱也好 JS 隔离也好，最终要实现的是给子应用一个独立的环境，这也意味着我们有成百上千的东西要做补丁来打造终极的类 <iframe> 硬隔离。

然而，qiankun 也不是万能的，它只对某些重要的函数和监听器进行打补丁。

其中最重要的补丁就是 insertBefore, appendChild 和 removeChild 的补丁了。

当我们加载子应用的时候，免不了遇到动态添加/移除 CSS 和 JS 脚本的情况。这时 <head> 或 <body> 都有可能调用 insertBefore, appendChild, removeChild 这三个函数来插入或者删除 <style>, <link> 或者 <script> 元素。

所以，这三个函数在被 <head> 或 <body> 调用时，就要用上补丁，主要目的是别插入到主应用的 <head> 和 <body> 上，要插在子应用里。打补丁伪代码如下：

// patch(element)
switch (element.tagName) {
  case LINK_TAG_NAME:  // <link> 标签
  case STYLE_TAG_NAME: { // <style> 标签
    if (scopedCSS) { // 使用 Scoped CSS
      if (element.href;) { // 处理如 <link rel="icon" href="favicon.ico"> 的玩意
        stylesheetElement = convertLinkAsStyle( // 获取 <link> 里的 CSS 文本，并使用 css.process 添加前缀
          element,
          (styleElement) => css.process(mountDOM, styleElement, appName), // 添加前缀回调
          fetch,
        );
        dynamicLinkAttachedInlineStyleMap.set(element, stylesheetElement); // 缓存，下次加载沙箱时直接吐出来
      } else { // 处理如 <style>.container { background: red }</style> 的玩意
        css.process(mountDOM, stylesheetElement, appName);
      }
    }

    return rawDOMAppendOrInsertBefore.call(mountDOM, stylesheetElement, referenceNode); // 插入到挂载容器上
  }

  case SCRIPT_TAG_NAME: {
    const { src, text } = element as HTMLScriptElement;

    if (element.src) { // 处理外链 JS
      execScripts(null, [src], proxy, { // 获取并执行 JS
        fetch,
        strictGlobal,
      });

      return rawDOMAppendOrInsertBefore.call(mountDOM, dynamicScriptCommentElement, referenceNode); // 插入到挂载容器上
    }

    // 处理内联 JS
    execScripts(null, [`<script>${text}</script>`], proxy, { strictGlobal });
    return rawDOMAppendOrInsertBefore.call(mountDOM, dynamicInlineScriptCommentElement, referenceNode);
  }

  default:
    break;
}

当在创建沙箱时打完补丁后，在处理样式和 JS 脚本时就可以针对当前子应用来应用样式和 JS 了。上面我们还注意到 CSS 样式文本是被保存的，所以当子应用 remount 的时候，这些样式也可以作为缓存直接一波补上，不需要再做处理了。

剩下的补丁都是给 historyListeners, setInterval, addEventListeners, removeEventListeners 做的补丁，无非就是 mount 时记录 listeners 以及一些添加的值，在 unmount 的时候再一次性执行掉或者删除掉，不再赘述。

更多的生命周期

如果当前项目迁移成子应用，在入口的 JS 就不得不配合 qiankun 来做一些改动，而这些改动有可能影响子应用的独立运行。比如，接入了微前端后，可能就不得不在本地先起一个主应用，再起一个子应用，然后才能做开发和调试，那这也太蛋疼了。

为了解决子应用也能独立运行的问题，qiankun 注入了一些变量，来告诉子应用说：喂，你现在是儿子，要用子应用的渲染方式。而当子应用获取不到这些注入的变量时，它就知道：哦，我现在要独立运行了，用回原来的渲染方式就可以了，比如：

if (window. __POWERED_BY_QIANKUN__) {
  console.log('微前端场景')
  renderAsSubApp()
} else {
  console.log('单体场景')
  previousRenderApp()
}

怎么注入就是个问题了，不能简单的 window.__POWERED_BY_QIANKUN__ = true 就完事了，因为子应用会在编译时就要这个变量了。所以，qiankun 在 single-spa 提供的生命周期 load, mount, unmount 前做了变量的注入，伪代码如下：

// getAddOn
export default function getAddOn(global: Window): FrameworkLifeCycles<any> {
  return {
    async beforeLoad() {
      // eslint-disable-next-line no-param-reassign
      global.__POWERED_BY_QIANKUN__ = true;
    },

    async beforeMount() {
      // eslint-disable-next-line no-param-reassign
      global.__POWERED_BY_QIANKUN__ = true;
    },

    async beforeUnmount() {
      // eslint-disable-next-line no-param-reassign
      delete global.__POWERED_BY_QIANKUN__;
    },
  };
}

// loadApp
const addOnLifeCycles = getAddOn(window)

return {
  load: [addOnLifeCycles.beforeLoad, subApp.load],
  mount: [addOnLifeCycles.mount, subApp.mount],
  unmount: [addOnLifeCycles.unmount, subApp.unmount]
}

总结一下，新增的生命周期有：

  • beforeLoad
  • beforeMount
  • afterMount
  • beforeUnmount
  • afterUnmount

loadApp

好了，上面就是加载一个子应用的所有步骤了，这里先做个小总结：

  • import-html-entry 解析 html，获取 JavaScript, CSS, HTML
  • 创建容器 container，同时加上 css 样式隔离：在 container 上添加 Shadow DOM 或者对 CSS 文本 添加前缀实现 Scoped CSS
  • 创建沙箱，监听 window 的变化，并对一些函数打上补丁
  • 提供更多的生命周期，在 beforeXXX 里注入一些 qiankun 提供的变量
  • 返回带有 bootstrap, mount, unmount 属性的对象

预加载

从上面可以看到加载一个子应用的时候需要很多的步骤，我们不禁想到：如果在 mount 第一个子应用空闲时候，可以预先加载别的子应用，那之后切换子应用就可以更快了，也即子应用预加载。

在空闲的时候干一些事，可以使用浏览器提供的 requestIdleCallback。OK，那我们再来定义一下“预加载”是什么，其实就是把 CSS 和 JS 下载下来就完事了，所以 qiankun 的源码也是很简单的：

requestIdleCallback(async () => {
  const { getExternalScripts, getExternalStyleSheets } = await importEntry(entry, opts);
  requestIdleCallback(getExternalStyleSheets);
  requestIdleCallback(getExternalScripts);
});

现在，我们再来脑洞大开一下：难道一下子就要所有子应用都要预加载么？不见得吧？有可能一些子应用要预加载，一些不需要。

所以 qiankun 提供了三种预加载策略：

  • 全部子应用都立马预加载
  • 全部子应用都在第一个子应用加载后才预加载
  • 在 criticalAppNames 数组里的子应用要立马预加载，在 minorAppsName 数组里的子应用在第一个子应用加载后才预加载

源码实现如下：

export function doPrefetchStrategy(
  apps: AppMetadata[],
  prefetchStrategy: PrefetchStrategy,
  importEntryOpts?: ImportEntryOpts,
) {
  const appsName2Apps = (names: string[]): AppMetadata[] => apps.filter((app) => names.includes(app.name));

  if (Array.isArray(prefetchStrategy)) {
    // 全部都在第一个子应用加载后才预加载
    prefetchAfterFirstMounted(appsName2Apps(prefetchStrategy as string[]), importEntryOpts);
  } else if (isFunction(prefetchStrategy)) {
    (async () => {
      // 一半一半
      const { criticalAppNames = [], minorAppsName = [] } = await prefetchStrategy(apps);
      prefetchImmediately(appsName2Apps(criticalAppNames), importEntryOpts);
      prefetchAfterFirstMounted(appsName2Apps(minorAppsName), importEntryOpts);
    })();
  } else {
    switch (prefetchStrategy) {
      case true: // 全部都在第一个子应用加载后才预加载
        prefetchAfterFirstMounted(apps, importEntryOpts);
        break;

      case 'all': // 全部子应用都立马预加载
        prefetchImmediately(apps, importEntryOpts);
        break;

      default:
        break;
    }
  }
}

全局状态管理

全局状态很有可能出现在微前端的场景中，比如主应用提供可以一些初始化好的 SDK。刚开始先传个未初始好的 SDK，等主应用把 SDK 初始化好了，再通过回调通知子应用：醒醒，SDK 准备好了。

这种思路和 Redux, Event Bus 一模一样。 状态都存在 window 的 gloablState 全局对象里，再添加一个 onGlobalStateChange 回调就完事了，实现伪代码如下：

let gloablState = {}
let deps = {}

// 触发全局监听
function emitGlobal(state: Record<string, any>, prevState: Record<string, any>) {
  Object.keys(deps).forEach((id: string) => {
    if (deps[id] instanceof Function) {
      deps[id](cloneDeep(state), cloneDeep(prevState));
    }
  });
}

// 添加全局状态变化的监听器
function onGlobalStateChange(callback: OnGlobalStateChangeCallback, fireImmediately?: boolean) {
  deps[id] = callback;
  if (fireImmediately) {
    const cloneState = cloneDeep(globalState);
    callback(cloneState, cloneState);
  }
}

// 更新 globalState
function setGlobalState(state: Record<string, any> = {}) {
  const prevState = globalState
  globalState = {...cloneDeep(globalState), ...state}
  emitGlobal(globalState, prevState);
}

// 注销该应用下的依赖
function offGlobalStateChange() {
  delete deps[id];
}

onGlobalStateChange 添加监听器，当调用 setGlobalState 更新值，值改了，调用 emitGlobal，执行所有对应的监听器。调用 offGlobalStateChange 删掉监听器。Easy ~

全局错误处理

主要监听了 error 和 unhandledrejection 两个错误事件：

export function addGlobalUncaughtErrorHandler(errorHandler: OnErrorEventHandlerNonNull): void {
  window.addEventListener('error', errorHandler);
  window.addEventListener('unhandledrejection', errorHandler);
}

export function removeGlobalUncaughtErrorHandler(errorHandler: (...args: any[]) => any) {
  window.removeEventListener('error', errorHandler);
  window.removeEventListener('unhandledrejection', errorHandler);
}

使用的时候添加监听器，不要的时候移除监听器，不废话。

总结

再次总结一下 qiankun 做了什么事情：

  • 实现 loadApp 函数，是最关键、重要的一步
  • 实现 CSS 样式隔离，主要有 Shadow DOM 和 Scoped CSS 两种方案
  • 实现沙箱，JS 隔离，主要对 window 对象、各种 listeners 和方法进行隔离
  • 提供很多生命周期，并在一些 beforeXXX 的钩子里注入 qiankun 提供的变量
  • 提供预加载，提前下载 HTML、CSS、JS，并有三种策略
  • 全部立马预加载
  • 全部在第一个加载后预加载
  • 一些立马预加载，一些在第一个加载后预加载
  • 提供全局状态管理，类似 Redux，Event Bus
  • 提供全局错误处理，主要监听 error 和 unhandledrejection 两个事件

最后

虽然阿里说：“可能是你见过最完善的微前端解决方案 ”。但是从上面对源码的解读也可以看出来，qiankun 也有一些事情没有做的。比如没有对 localStorage 进行隔离，如果多个子应用都用到 localStorage 就有可能冲突了，除此之外，还有 cookie, indexedDB 的共享等。再比如如果单个页面下多个子应用都依赖了前端路由怎么办呢？当然这里的质疑也仅是我个人的猜想。

另一件事想说的是：微前端的难点并不是 single-spa 的生命周期、路由挟持。而是如何加载好一个子应用。从上面可以看到，有很多 hacky 的编码，比如在选择器前面加前缀，将子应用的 <link>, <script> 加载到子应用上，监听 window 的变化，恢复现场等等，都是台上一句话，台下想秃头的操作。如果不是真见过，估计想破头都想不出来。

也正是这些 hacky 代码，在搭建微前端的时候会遇到非常多的问题，而且微前端的目的是要将多个 山聚合起来，所以微前端的解决方案是注定没有银弹的，且行且珍惜吧。

发布于 2021-06-11 02:16
前端开发
SPA (Single-Page App)
前端框架

文章被以下专栏收录