Iframe在Vue中的狀態保持技術-有解無憂

引言

Iframe是一個歷史悠久的HTML元素，根據MDN WEB DOCS官方介紹，Iframe定義為HTML行內框架元素，表示嵌套的Browsing Context，它能夠將另一個HTML頁面嵌入到當前頁面中，Iframe可以廉價實作跨應用級的頁面共享，并且具有使用簡單、高兼容性、內容隔離等優點，因此以Iframe為核心形成了前端平臺架構領域第1代技術，

眾所周知，當Iframe在DOM中初始渲染時，會自動加載其指向的資源鏈接Url，并重置內部的狀態，在一個典型的平臺應用中，一個父應用主頁面要掛載多個視窗（每一個視窗對應一個Iframe），那么如何在切換視窗時，實作每一個視窗中的狀態（包括輸入狀態、錨點資訊等）不丟失，也即“狀態保持”呢？

如果采用父子應用通信來記錄視窗狀態，那么改造成本是非常巨大的，答案是利用Iframe的CSS Display特性，切換視窗時，非激活狀態的視窗并不消失，僅是Display狀態變更為none，激活狀態視窗的Display狀態變更為非none，在Display狀態切換時，Iframe不會重新加載，在Vue應用中，一行v-show指令即可替我們實作這一需求，

競爭機制

上述的狀態保持模型存在一個性能缺陷，即父應用主頁面實際上要提前擺放多個Iframe視窗，即使是這些不可見的視窗，也會發出資源request請求，大量的并發請求，會導致頁面性能下降，（值得一提的是，Chrome最新版本已經支持了Iframe的滾動懶加載策略，但是在此場景下，并不能改善并發請求的問題，）因此，我們需要引入資源池和競爭機制來管理多個Iframe，

引入一個容量為N的Iframe資源池來管理多開視窗，當資源池未滿時，新激活的視窗可以直接插入至資源池中；當資源池已滿時，資源池按照競爭策略，淘汰若干池中的視窗并丟棄，然后插入新激活的視窗至資源池中，通過調整容量N，可以限制父應用主頁面上多開視窗的數量，從而限制并發請求數量，實作資源管控的目的，

Vue Patch原理探索

日前遇到了一個基于Vue應用的Iframe狀態保持問題，在上述模型下，資源池不僅保存視窗物件，而且記錄了每個視窗的點擊激活時間，資源池使用以下競爭淘汰策略：對視窗激活時間進行先后次序排序，激活時間排序次序較前的視窗優先被淘汰，當資源池滿時，會偶發池中視窗狀態不能保持的問題，

在Vue中，組件是一個可復用的Vue實體，Vue 會盡可能高效地渲染元素，通常會復用已有元素而不是從頭開始渲染，組件狀態是否正確保持，依賴關鍵屬性key，基于此，首先排查了Iframe組件的key屬性，事實上，Iframe組件已經正確分配了唯一的Uid，此種情況可以排除，

既然不是組件復用的問題，那么在Vue內部的Diff Patch機制到底是如何運行的呢？讓我們看一下Vue 2.0的源代碼：

/**
 * 頁面首次渲染和后續更新的入口位置，也是 patch 的入口位置 
 */
Vue.prototype._update = function (vnode: VNode, hydrating?: boolean) {
  if (!prevVnode) {
    // 老 VNode 不存在，表示首次渲染，即初始化頁面時走這里
    ……
  } else {
    // 回應式資料更新時，即更新頁面時走這里
    vm.$el = vm.__patch__(prevVnode, vnode)
  }
}

（1）在update生命周期下，主要執行了vm.__patch__方法，

/** 
* vm.__patch__ 
* 1、新節點不存在，老節點存在，呼叫 destroy，銷毀老節點 
* 2、如果 oldVnode 是真實元素，則表示首次渲染，創建新節點，并插入 body，然后移除老節點 
* 3、如果 oldVnode 不是真實元素，則表示更新階段，執行 patchVnode 
*/
function patch(oldVnode, vnode, hydrating, removeOnly) {
  …… // 1、新節點不存在，老節點存在，呼叫 destroy，銷毀老節點
  if (isUndef(oldVnode)) {
    …… // 2、老節點不存在，執行創建新節點
  } else {
    // 判斷 oldVnode 是否為真實元素
    const isRealElement = isDef(oldVnode.nodeType)
    if (!isRealElement && sameVnode(oldVnode, vnode)) {
      // 3、不是真實元素，但是老節點和新節點是同一個節點，則是更新階段，執行 patch 更新節點
      patchVnode(oldVnode, vnode, insertedVnodeQueue, null, null, removeOnly)
    } else {
      ……// 是真實元素，則表示初次渲染
    }
  }
  invokeInsertHook(vnode, insertedVnodeQueue, isInitialPatch)
  return vnode.elm
}

（2）在__patch__方法內部，觸發patchVnode方法，

function patchVnode (oldVnode, vnode, insertedVnodeQueue, removeOnly) {
  ……
  if (isUndef(vnode.text)) {// 新節點不為文本節點
    if (isDef(oldCh) && isDef(ch)) {// 新舊節點的子節點都存在，執行diff遞回
      if (oldCh !== ch) updateChildren(elm, oldCh, ch, insertedVnodeQueue, removeOnly)
    } else {
      ……
    }
  } else {
    ……
  }
}

（3）在patchVnode方法內部，觸發updateChildren方法，

/**
 * diff 程序:
 *   diff 優化：做了四種假設，假設新老節點開頭結尾有相同節點的情況，一旦命中假設，就避免了一次回圈，以提高執行效率
 *   如果不幸沒有命中假設，則執行遍歷，從老節點中找到新開始節點
 *   找到相同節點，則執行 patchVnode，然后將老節點移動到正確的位置
 *   如果老節點先于新節點遍歷結束，則剩余的新節點執行新增節點操作
 *   如果新節點先于老節點遍歷結束，則剩余的老節點執行洗掉操作，移除這些老節點
 */
function updateChildren(parentElm, oldCh, newCh, insertedVnodeQueue, removeOnly) {
  // 老節點的開始索引
  let oldStartIdx = 0
  // 新節點的開始索引
  let newStartIdx = 0
  // 老節點的結束索引
  let oldEndIdx = oldCh.length - 1
  // 第一個老節點
  let oldStartVnode = oldCh[0]
  // 最后一個老節點
  let oldEndVnode = oldCh[oldEndIdx]
  // 新節點的結束索引
  let newEndIdx = newCh.length - 1
  // 第一個新節點
  let newStartVnode = newCh[0]
  // 最后一個新節點
  let newEndVnode = newCh[newEndIdx]
  let oldKeyToIdx, idxInOld, vnodeToMove, refElm

  // 遍歷新老兩組節點，只要有一組遍歷完（開始索引超過結束索引）則跳出回圈
  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    if (isUndef(oldStartVnode)) {
      // 如果節點被移動，在當前索引上可能不存在，檢測這種情況，如果節點不存在則調整索引
      oldStartVnode = oldCh[++oldStartIdx] // Vnode has been moved left
    } else if (isUndef(oldEndVnode)) {
      oldEndVnode = oldCh[--oldEndIdx]
    } else if (sameVnode(oldStartVnode, newStartVnode)) {
      // 老開始節點和新開始節點是同一個節點，執行 patch
      patchVnode(oldStartVnode, newStartVnode, insertedVnodeQueue, newCh, newStartIdx)
      // patch 結束后老開始和新開始的索引分別加 1
      oldStartVnode = oldCh[++oldStartIdx]
      newStartVnode = newCh[++newStartIdx]
    } else if (sameVnode(oldEndVnode, newEndVnode)) {
      // 老結束和新結束是同一個節點，執行 patch
      patchVnode(oldEndVnode, newEndVnode, insertedVnodeQueue, newCh, newEndIdx)
      // patch 結束后老結束和新結束的索引分別減 1
      oldEndVnode = oldCh[--oldEndIdx]
      newEndVnode = newCh[--newEndIdx]
    } else if (sameVnode(oldStartVnode, newEndVnode)) { // Vnode moved right
      // 老開始和新結束是同一個節點，執行 patch
      ……
    } else if (sameVnode(oldEndVnode, newStartVnode)) { // Vnode moved left
      // 老結束和新開始是同一個節點，執行 patch
      ……
    } else {
      // 如果上面的四種假設都不成立，則通過遍歷找到新開始節點在老節點中的位置索引
      ……
        // 在老節點中找到新開始節點了
        if (sameVnode(vnodeToMove, newStartVnode)) {
          // 如果這兩個節點是同一個，則執行 patch
          patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue, newCh, newStartIdx)
          // patch 結束后將該老節點置為 undefined
          oldCh[idxInOld] = undefined
          canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
        } else {
          // 最后這種情況是，找到節點了，但是發現兩個節點不是同一個節點，則視為新元素，執行創建
          ……
        }
      // 老節點向后移動一個
      newStartVnode = newCh[++newStartIdx]
    }
  }
  // 走到這里，說明老姐節點或者新節點被遍歷完了，執行剩余節點的處理
  ……
}

（4）咱們終于來到了主角updateChildren，在updateChildren內部實作中，使用了2套指標分別指向新舊Vnode頭尾，并向中間聚攏遞回，以實作新舊資料對比重繪，

在前述資源池模型下，當查找到新舊Iframe組件時，會執行如下邏輯：

if (sameVnode(vnodeToMove, newStartVnode)) {
          // 如果這兩個節點是同一個，則執行 patch
          patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue, newCh, newStartIdx)
          // patch 結束后將該老節點置為 undefined
          oldCh[idxInOld] = undefined
          canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
}

看來出現問題的罪魁禍首是執行了nodeOps.insertBefore，在WEB的運行環境下實際上執行的是DOM的insertBefore API，那么我們移步來看看在DOM環境下，Iframe究竟是采取了何種重繪策略，

Iframe的狀態重繪機制

為了更清晰地看到DOM節點的變化情況，我們可以引入MutationObserver在最新版Chrome中來觀測DOM根節點，
首先設定容器節點下有兩個子節點：<span/>和<iframe/>，分別執行以下方案并記錄結果：
對比方案A：使用insertBefore在iframe節點前再插入一個新的span節點
對比方案B：使用insertBefore在iframe節點后再插入一個新的span節點
對比方案C：使用insertBefore交換span和iframe節點
對比方案D：使用insertBefore原地操作iframe自身
其結果如下：

方案名稱	Iframe是否重繪	DOM節點變化
A	否	新增一個子節點span
B	否	新增一個子節點span
C	是	先移除一個iframe，再插入一個iframe
D	是	先移除一個iframe，再插入一個iframe

實驗結果顯示，對Iframe執行insertBefore時，實際上DOM會依次執行移除、新增節點操作，導致Iframe狀態重繪，

在Vuejs Issues #9473中提到了類似的問題，一種解決方案是在Vue Patch時優先對非Iframe型別元素進行DOM操作，但是目前這個優化策略尚未被采用，在Vue 3.0版本中也依然存在這個問題，

那么在資源池模型下，如何才能保證Iframe不執行insertBefore呢？重新回到Vue Patch機制下，我們發現，只有新舊Iframe在新舊Vnode串列中的相對位置保持不變時，才會只執行patchVnode方法，而不會觸發insertBefore方法，

因此，采取的最終解決方案是，更改淘汰機制，將排序操作改為搜索操作，保證了多開視窗在Vue中的狀態保持，

作者：京東零售陳震

內容來源：京東云開發者社區

轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/553393.html

標籤：其他

上一篇：如何撰寫一個健壯的 npm 包

下一篇：返回列表