Qiankun JS沙箱是怎么做隔離的

這篇“Qiankun JS沙箱是怎么做隔離的”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Qiankun JS沙箱是怎么做隔離的”文章吧。

前言

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

總不能這樣吧：

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

復習一下沙箱

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 也能以此作為恢復環境的依據。

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 這樣的代碼，那么在加載微應用的時候直接修復全局變量的問題，不需要通知他們修改，也不失為一種策略吧。

以上就是關于“Qiankun JS沙箱是怎么做隔離的”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。