Qiankun原理詳解JS沙箱是如何做隔離

2022-09-30 14:00:06

前言

相信大家也知道 qiankun 有 SnapshotSandbox, LegacySandbox 和 ProxySandbox 這些沙箱，而它們又可以分為單例和多例兩種模式，網上也有很多文章對其進行介紹。

但這些文章的關注點都是沙箱的環境恢復做的事，那 JS 的隔離到底是怎麼做到的呢？

換個問法，當我寫 window.a = 1 的時候，a 是怎麼被掛載到這些 XXXSandbox 上的呢？又或者我直接雲修改 window.a = 123 時，JS 沙箱到底是怎麼隔離這個 a 的呢？

總不能這樣吧：

window = window.sandbox
window.a = 1 // window.sandbox.a = 1

這篇文章就來簡單聊聊 qiankun 沙箱那些事。

複習一下沙箱

這裡我們還是稍微複習一下 qiankun 的三大沙箱吧。

SanpshotSandbox

第一種是快照沙箱。

它的原理是：把主應用的 window 物件做淺拷貝，將 window 的鍵值對存成一個 Hash Map。之後無論微應用對 window 做任何改動，當要在恢復環境時，把這個 Hash Map 又應用到 window 上就可以了。大概如下圖所示。

稍微做下小結：

微應用 mount 時
- 先把上一次記錄的變更 modifyPropsMap 應用到微應用的全域性 window，沒有則跳過
- 淺複製主應用的 window key-value 快照，用於下次恢復全域性環境
微應用 unmount 時
- 將當前微應用 window 的 key-value 和快照的 key-value 進行 Diff，Diff 出來的結果用於下次恢復微應用環境的依據
- 將上次快照的 key-value 拷貝到主應用的 window 上，以此恢復環境

LegacySandbox

上面的 SnapshotSandbox 有一個問題：每次微應用 unmount 時都要對每個屬性值做一次 Diff，類似這樣：

for (const prop in window) {
  if (window[prop] !== this.windowSnapshot[prop]) {
    // 記錄微應用的變更
    this.modifyPropsMap[prop] = window[prop];
    // 恢復主應用的環境
    window[prop] = this.windowSnapshot[prop];
  }
}

如果有 1000 個屬性就要對比 1000 次，不是那麼優雅。

LegacySandbox 的想法則是通過監聽對 window 的修改來直接記錄 Diff 內容，因為只要對 window 屬性進行設定，那麼就會有兩種情況：

如果是新增屬性，那麼存到 addedMap 裡
如果是更新屬性，那麼把原來的鍵值存到 prevMap，把新的鍵值存到 newMap

（當然這裡的變數名做了簡化）

通過 addedMap, prevMap 和 newMap 這三個變數就能反推出微應用以及原來環境的變化，qiankun 也能以此作為恢復環境的依據。

當然這裡的監聽用到了 ES6 的新語法 Proxy，不過這裡先不展開討論，在之後的系列文章上會會自己手動實現一個簡單的沙箱。

ProxySandbox

前面兩種沙箱都是單例模式下使用的沙箱。也即一個頁面中只能同時展示一個微應用，而且無論是 set 還是 get 依然是直接操作 window 物件。

在這樣單例模式下，當微應用修改全域性變數時依然會在原來的 window 上做修改，因此如果在同一個路由頁面下展示多個微應用時，依然會有環境變數汙染的問題。

為了避免真實的 window 被汙染，qiankun 實現了 ProxySandbox。它的想法是：

把當前 window 的一些原生屬性（如document, location等）拷貝出來，單獨放在一個物件上，這個物件也稱為 fakeWindow
之後對每個微應用分配一個 fakeWindow
當微應用修改全域性變數時：
- 如果是原生屬性，則修改全域性的 window
- 如果是原生屬性，則修改 fakeWindow 裡的內容
微應用獲取全域性變數時：
- 如果是原生屬性，則從 window 裡拿
- 如果不是原生屬性，則優先從 fakeWindow 裡獲取

這樣一來連恢復環境都不需要了，因為每個微應用都有自己一個環境，當在 active 時就給這個微應用分配一個 fakeWindow，當 inactive 時就把這個 fakeWindow 存起來，以便之後再利用。

隔離原理

看完上面，你大概也知道了這些沙箱是怎麼恢復環境的但是，回到我們的問題：qiankun 是怎麼把 a 和這些沙箱聯絡起來呢？也即寫下 window.a = 1 是怎麼做到對 a 變數隔離的呢？

這個邏輯的實現並不在 qiankun 的原始碼裡，而是在它所依賴的 import-html-entry 中，這裡做一下簡化：

const executableScript = `
  ;(function(window, self, globalThis){
    ;${scriptText}${sourceUrl}
  }).bind(window.proxy)(window.proxy, window.proxy, window.proxy);
`
eval.call(window, executableScript)

把上面字串程式碼展開來看看：

function fn(window, self, globalThis) {
  // 你的 JavaScript code
}
const bindedFn = fn.bind(window.proxy);
bindedFn(window.proxy, window.proxy, window.proxy);

可以發現這裡的程式碼做了三件事：

把要執行 JS 程式碼放在一個立即執行函數中，且函數入參有 window, self, globalThis
給這個函數繫結上下文 window.proxy
執行這個函數，並把上面提到的沙箱物件 window.proxy 作為入參分別傳入

因此，當我們在 JS 檔案裡有 window.a = 1 時，實際上會變成：

function fn(window, self, globalThis) {
  window.a = 1;
}
const bindedFn = fn.bind(window.proxy);
bindedFn(window.proxy, window.proxy, window.proxy);

那麼此時，window.a 的 window 就不是全域性 window 而是 fn 的入參 window 了。又因為我們把 window.proxy 作為入參傳入，所以 window.a 實際上為 window.proxy.a = 1。這也正好解釋了 qiankun 的 JS 隔離邏輯。

XXX is undefined

不知道看完上面的實現，你有沒有發現問題。

假如現在程式碼裡有隱式宣告或呼叫全域性物件的程式碼：

add = (a, b) => {
  return a + b
}
add(1, 2)

當這樣呼叫 add 時，上下文 this 則為剛剛繫結的 window.proxy。由於隱式宣告 add 不會自動掛載到 window.proxy 上，所以當執行 add，eval 就會報 add is undefined。詳見這個 Issue。

不要覺得這種情況不會發生，實際上，這還是挺常見的：

老舊的第三方 SDK JS 檔案
Webpack 外掛引入的 JS
公司閘道器層自動注入的 JS
等等...

我之前就遇到過這種情況：比如下面 Webpack 會注入腳手架定義好的 CDN 資源重試邏輯：

<script>
  var __JS_RETRY__ = {};
  function __rpReport(data) {
    console.log('__rpReport');
  }
  function __rpJsReport(loadType, msidType, url) {
    console.log('__rpJsReport');
  }
  function __retryPlugin(event) {
    console.log('retryPlugin')
  }
  // 改成下面就可以了
  // window.__JS_RETRY__ = {};
  //
  // window.__rpReport = (data) => {
  //     console.log('__rpReport');
  // }
  //
  // window.__rpJsReport = (loadType, msidType, url) => {
  //     console.log('__rpJsReport');
  // }
  //
  // window.__retryPlugin = (event) => {
  //     console.log('retryPlugin')
  // }
</script>

這個問題的解決的方法也很簡單：

把程式碼 a = 1 改成 window.a
新增全域性宣告 window a

這樣一來，你就得每次打包程式碼以及釋出時執行一個指令碼來做這些文字替換，非常麻煩。而京東的新微應用框架 MicroApp 則提供了一套外掛系統：

它可以讓開發者在執行 JS 前去做程式碼文字的替換：

import microApp from '@micro-zoe/micro-app'
microApp.start({
  plugins: {
    // ...
    modules: {
      'appName1': [{
        loader(code, url, options) {
          if (url === 'xxx.js') {
            // 替換有問題的程式碼
            code = code.replace('var abc =', 'window.abc =')
          }
          return code
        }
      }],
    }
  }
})

如果要對接別的團隊的微應用時，而且正好他們有 a = 1 這樣的程式碼，那麼在載入微應用的時候直接修復全域性變數的問題，不需要通知他們修改，也不失為一種策略吧。