Iframe在Vue中的狀態保持技術

語言: CN / TW / HK

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 {
……
}
}
}

(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執行insertBefore時,實際上DOM會依次執行移除、新增節點操作,導致Iframe狀態重新整理。

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

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

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