【微前端】qiankun 究竟是個什麼鬼

前言

在上一篇文章【微前端】single-spa 究竟是個什麼鬼聊到了 single-spa 這個框架僅僅實現了子應用的生命週期的調度以及 url 變化的監聽。微前端的一個特色都沒有實現，嚴格來講算不上微前端框架。css

今天就來聊一個真正的微前端框架：qiankun。一樣地，本文不會教你們怎麼實現一個 Demo，由於官方的 Github 已經有一個很好的 Demo 了，若是你以爲官網的 Demo 太複雜了，也能夠看我本身實現的小 Demo。html

qiankun 到底作了什麼

首先，qiankun 並非單一個框架，它在 single-spa 基礎上添加更多的功能。如下是 qiankun 提供的特性：前端

實現了子應用的加載，在原有 single-spa 的 JS Entry 基礎上再提供了 HTML Entry
樣式和 JS 隔離
更多的生命週期：beforeMount, afterMount, beforeUnmount, afterUnmount
子應用預加載
全局狀態管理
全局錯誤處理

接下來不會一個特性一個特性地講，由於這樣會很無聊，講完你也只能知道這是個啥，不能深刻了解是怎麼來的。因此我更願意聊一下這些特性是怎麼來的，它們是怎麼被想到的。react

多入口

先複習一下 single-spa 是怎麼註冊子應用的：git

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

能夠看到 single-spa 採用 JS Entry 的方式接入微應用，也即：輸出一個 JS，而後 bootstrap, mount, unmount 函數。github

可是事件並無這麼簡單：咱們項目通常都會將靜態資源放到 CDN 上來加速。爲了避免受緩存的影響，咱們還會將 JS 文件命名成 contenthash 的亂碼文件名： jlkasjfdlkj.jalkjdsflk.js。這樣一來，每次子應用一發布，入口 JS 文件名確定又要改了，致使主應用引入的 JS url 又得改了。麻煩！正則表達式

打包成單個 JS 文件的另外一個問題就是打包的優化都沒了：按需加載、首屏資源加載優化、css 獨立打包等優化措施全 🈚️。bootstrap

不少時候，子應用通常都已是線上的應用了，好比 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 的時候再一次性執行掉或者刪除掉，再也不贅述。

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 代碼，在搭建微前端的時候會遇到很是多的問題，並且微前端的目的是要將多個💩山聚合起來，因此微前端的解決方案是註定沒有銀彈的，且行且珍惜吧。