折騰了兩周半我終于把內部代號叫rea的輕量渲染引擎跑通了。說是引擎其實沒有想象中那么玄乎它解決的核心問題只有一句話如何把一段狀態(tài)數(shù)據(jù)變成用戶能看到的頁面并且在狀態(tài)變化時只更新該變化的部分。一開始我只是想接手一個內部支撐系統(tǒng)時把那些散落在各處的innerHTML和appendChild收攏一下順手也給團隊里的新同學留一份能看懂的“框架底層說明書”。結果寫著寫著發(fā)現(xiàn)光是渲染鏈路就夠寫一篇長文。這個代號rea就這么延續(xù)了下來它既不是某個成熟框架的變體也不是業(yè)務線的名字縮寫純粹是開發(fā)目錄里的臨時命名后來懶得改了。這篇文章不打算講多深奧的編譯原理也不會整段貼框架源碼。我想按照自己實際動手的順序把這個項目里的設計思路、關鍵實現(xiàn)、踩坑記錄和實測數(shù)據(jù)一次性講清楚。如果你正準備做類似的前端基建或者單純好奇“框架是怎么把數(shù)據(jù)變成頁面的”這篇應該能讓你少走點彎路。1. 項目背景與核心需求拆解1.1 rea 到底要解決什么問題場景特別典型一個后臺管理頁面左側篩選條件右側實時列表。用戶每點一次篩選接口回一批數(shù)據(jù)然后頁面要做的事包括更新統(tǒng)計數(shù)字、重繪列表、切換空狀態(tài)、調整分頁信息。在舊代碼里這些更新分散在各個回調函數(shù)中每來一次數(shù)據(jù)就操作一遍 DOM。小數(shù)據(jù)量時看不出毛病數(shù)據(jù)一過千頁面就開始卡。原因是多方面的頻繁觸發(fā)重排重繪、沒有節(jié)流、列表更新時把整塊容器清空再重建、事件綁定在每次重建后丟失又得重新掛。這些都指向同一個本質問題狀態(tài)和視圖之間缺少一條結構化的對應關系。rea的目標就很清楚了提供一個最小的數(shù)據(jù)驅動渲染方案。開發(fā)者只需要維護數(shù)據(jù)渲染層根據(jù)數(shù)據(jù)變化自動計算出需要增刪改的節(jié)點然后精準操作 DOM。不追求覆蓋所有復雜業(yè)務但要把最核心的“數(shù)據(jù)到視圖”鏈路做干凈。1.2 為什么選擇自研而不是直接套框架這是團隊里被問得最多的一個問題。不是說成熟框架不好而是當前項目有幾個客觀限制。第一運行環(huán)境不是常規(guī)瀏覽器而是一個定制化的 WebView 容器很多框架依賴的高級 DOM API 在這里表現(xiàn)不穩(wěn)定。第二業(yè)務包體有嚴格體積限制引入一個完整框架會吃掉大量預算。第三團隊里不少新人對框架的原理其實是一知半解的遇到線上問題只能靠猜我們希望借這個項目把渲染流程徹底攤開。自研rea并不是“重造輪子”式的炫技而是一次非常務實的取舍。既然業(yè)務形態(tài)足夠收斂那我要做的只是“渲染”這一件事就可以把體積和復雜度壓到很低?？蚣鼙旧淼倪吔绾芮逦惶幚砺酚?、不處理狀態(tài)管理、不處理網(wǎng)絡請求只負責把數(shù)據(jù)同步成 DOM。2. 總體架構設計與方案選型2.1 先梳理數(shù)據(jù)流再動手寫代碼動手前我先畫了一條單向數(shù)據(jù)流state - vnode - dom。狀態(tài)對象是唯一的數(shù)據(jù)來源每次狀態(tài)變更都會生成一棵新的虛擬節(jié)點樹然后和上一次的虛擬節(jié)點樹做對比最后把差異落到真實 DOM 上。為什么堅持單向因為雙向綁定在小型項目里雖然寫起來爽但數(shù)據(jù)流向一旦復雜排查問題就變成了“猜誰改了誰”。單向數(shù)據(jù)流的思路很簡單數(shù)據(jù)只能從 state 流向視圖視圖要改數(shù)據(jù)只能通過明確的方法調用。這樣做的好處是每個節(jié)點更新都能追溯到一次具體的狀態(tài)變更調試時把變更日志打開就能看清全鏈路。當時我也考慮過用 Proxy 做自動依賴收集像某些響應式框架那樣“改一個屬性就自動更新對應視圖”。但評估后發(fā)現(xiàn)定制 WebView 對 Proxy 的兼容性不夠穩(wěn)定而且依賴收集的邊界條件較多首版還是選擇最簡單可靠的方案手動觸發(fā)更新。也就是狀態(tài)變更后調用一次update()方法由調度器統(tǒng)一處理。2.2 虛擬節(jié)點不是銀彈但在這里性價比最高第一次接觸虛擬節(jié)點的人可能會疑惑直接在真實 DOM 上做 diff 不就行了嗎實測下來不太可行。真實 DOM 對象包含大量屬性和方法直接遍歷對比開銷很大而且很多屬性是只讀的改起來要小心翼翼。rea的虛擬節(jié)點就是一個普通 JavaScript 對象結構極其輕量{ tag: div, props: { id: list, class: item }, children: [...], el: null, // 指向真實 DOM掛載后回填 key: unique-key }在虛擬節(jié)點層面做比較相當于比較兩份“配置清單”成本遠低于操作真實 DOM。等確認差異后再把 diff 結果一次性落到真實 DOM 上。打個比方整理一份文檔如果每次都重新排版整個文件效率很低。虛擬節(jié)點方案相當于先把兩份目錄逐條對比只重印有變化的頁碼最后替換到文件里。頁面越大這種策略的優(yōu)勢越明顯。2.3 渲染管線分成四層我把整個渲染過程拆成了四層每一層只做一件事層級職責關鍵產出狀態(tài)層維護業(yè)務數(shù)據(jù)提供更新入口最新的 state節(jié)點層根據(jù) state 生成虛擬節(jié)點樹vnode tree對比層對比新舊節(jié)點樹計算差異patch list渲染層把差異應用到真實 DOM更新后的頁面分層帶來的最大好處是每一層都可以獨立測試。狀態(tài)層不碰 DOM節(jié)點層不關心數(shù)據(jù)從哪來對比層只做純計算渲染層才真正操作瀏覽器 API。調試一個詭異問題的時候我只需要定位到具體在哪一層不用把整條鏈路重新捋一遍。這也是我建議所有想寫渲染引擎的人先做的事別一上來就寫 diff先把數(shù)據(jù)流的骨架搭好。哪怕第一版功能簡單只要分層清晰后續(xù)加特性只是往對應層補代碼。3. 核心實現(xiàn)細節(jié)與實操要點3.1 三個生命周期mount、update、destroyrea的節(jié)點生命周期很簡單掛載、更新、銷毀。分別對應三個內部方法mount、patch、destroy。掛載階段做的事情是根據(jù)虛擬節(jié)點創(chuàng)建真實 DOM遞歸處理子節(jié)點最后把整個 DOM 插入容器。這一步的代碼不長但有幾個細節(jié)很關鍵。function mount(vnode, container) { const el document.createElement(vnode.tag); vnode.el el; // 處理屬性 for (const key in vnode.props) { if (key.startsWith(on)) { el.addEventListener(key.slice(2).toLowerCase(), vnode.props[key]); } else { el.setAttribute(key, vnode.props[key]); } } // 處理子節(jié)點 if (typeof vnode.children string) { el.textContent vnode.children; } else if (Array.isArray(vnode.children)) { vnode.children.forEach(child mount(child, el)); } container.appendChild(el); }注意這里的事件綁定邏輯在掛載階段直接用 addEventListener 綁定。但這會帶來一個隱患后面我會專門講。更新階段則是整個引擎的核心做的事情可以濃縮成一句話對比新舊虛擬節(jié)點找出差異只更新差異部分。如果新舊節(jié)點的tag不一樣說明整個節(jié)點類型變了直接把舊的卸載、把新的掛載上去如果tag一樣就復用真實 DOM逐項對比屬性再遞歸處理子節(jié)點。3.2 子節(jié)點 diff先對齊再最小化更新子節(jié)點的對比是渲染引擎里最復雜的部分也是最容易寫崩的地方。最簡單的做法是把舊子節(jié)點和新子節(jié)點按順序一一對比位置相同的就更新數(shù)量多出來的就新增數(shù)量不夠的就刪除。這種方案在“列表順序穩(wěn)定”的時候表現(xiàn)很好代碼也簡單。但業(yè)務里最常見的操作是列表重新排序比如把某一條數(shù)據(jù)置頂。如果只按順序對比原本在第一條的節(jié)點和新的第一條節(jié)點對不上就會引發(fā)一連串無意義的更新。解決方法是引入key。每個帶 key 的子節(jié)點在 diff 時會先建立一張以 key 為索引的映射表然后拿新舊列表做匹配。匹配上的節(jié)點復用沒有匹配上的按新增處理舊列表里多余的按刪除處理。function diffChildren(oldChildren, newChildren, parentEl) { const oldMap createKeyMap(oldChildren); const patches []; newChildren.forEach((newChild, index) { const oldChild oldMap.get(newChild.key); if (oldChild) { patches.push(patch(oldChild, newChild)); } else { patches.push({ type: MOUNT, vnode: newChild, index }); } }); oldChildren.forEach(oldChild { if (!newChildren.some(c c.key oldChild.key)) { patches.push({ type: REMOVE, el: oldChild.el }); } }); applyPatches(patches, parentEl); }代碼是簡化過的示意真實實現(xiàn)里還要考慮移動節(jié)點的處理。但核心思想是key 是對齊新舊節(jié)點的錨點不是隨便寫個 index 就完事。如果列表數(shù)據(jù)本身沒有穩(wěn)定唯一標識寧可額外生成一個 id也不要直接用數(shù)組下標做 key否則 diff 結果會非常詭異。3.3 屬性更新要區(qū)分“變更”和“無變化”節(jié)點更新時屬性對比看起來很小實際上坑很多。我最初的實現(xiàn)是每次更新都把新舊 props 里的所有屬性重新 setAttribute 一遍。實測下來除了浪費性能還有兩個明顯問題一是 class 變化會觸發(fā)樣式重算即使 class 值沒變二是部分屬性在設置時會引發(fā)額外的副作用比如value屬性在某些輸入框里會導致光標跳動。后來改成按 key 遍歷對比function patchProps(el, oldProps, newProps) { // 移除舊屬性中不存在的 for (const key in oldProps) { if (!(key in newProps)) { el.removeAttribute(key); } } // 更新變化的屬性 for (const key in newProps) { if (oldProps[key] ! newProps[key]) { el.setAttribute(key, newProps[key]); } } }這里的判斷用的是!也就是說只有值真的變了才會去操作 DOM。對于引用類型的 props還需要進一步做深度對比?，F(xiàn)實中我們通常限制 props 只能是字符串、數(shù)字或簡單對象復雜數(shù)據(jù)建議放到狀態(tài)層單獨管理避免在渲染層引入過重的對比邏輯。3.4 事件綁定代理是更好的選擇上文提到 mount 階段用了 addEventListener這在刪除節(jié)點時其實埋了個雷。節(jié)點被卸載后DOM 會被移除瀏覽器通常會回收事件監(jiān)聽問題不大。但有一種情況很麻煩節(jié)點復用但事件處理函數(shù)變了。如果只是簡單地在 patch 階段判斷新舊事件函數(shù)不一致把舊的移除再綁新的容易漏掉而且頻繁解綁綁定也有開銷。更好的方案是事件代理在容器根節(jié)點掛一個統(tǒng)一監(jiān)聽器所有節(jié)點事件都通過冒泡觸達根節(jié)點再由一個映射表根據(jù)事件類型和 node 標識找到對應的處理函數(shù)。container.addEventListener(click, (e) { const handler findEventHandler(e.target); if (handler) { handler(e); } });這樣做的好處有兩個第一節(jié)點掛載和卸載時完全不用關心事件綁定第二內存占用低不管頁面有多少個可點擊元素根節(jié)點只有一個監(jiān)聽器。代價是需要手動維護從節(jié)點到處理函數(shù)的映射同時要保證事件冒泡鏈路中的中間節(jié)點不會意外阻止事件傳遞。3.5 調度器把多次更新合并成一次渲染業(yè)務里經(jīng)常出現(xiàn)這種場景一次狀態(tài)變更同時改了列表、統(tǒng)計數(shù)字和篩選條件。如果每次變更都立刻執(zhí)行 diff 和 DOM 更新同一幀內可能觸發(fā)三次渲染白白浪費性能。我在rea里實現(xiàn)了一個極簡調度器基于微任務做批量更新。原理非常簡單let pending false; let dirty false; function scheduleUpdate() { dirty true; if (pending) return; pending true; Promise.resolve().then(() { pending false; if (dirty) { dirty false; performRender(); } }); }同一輪事件循環(huán)里不管調用多少次scheduleUpdate都只會執(zhí)行一次performRender。這樣做的收益在復雜頁面上特別明顯把同一幀內的多次更新合并成一次既減少了 diff 計算量也減少了 DOM 操作次數(shù)。調度的邊界情況比想象中多。比如在微任務執(zhí)行前又有新更新進來要保證不會漏掉又比如渲染過程中如果產生了新的更新需要避免死循環(huán)。這些我在調試階段都遇到過后面會專門講。4. 踩坑實錄與問題排查技巧4.1 列表更新后節(jié)點錯位問題出在 key 上做一個篩選列表時我遇到了一個詭異現(xiàn)象點“按時間排序”后列表內容沒變但每個卡片上的圖片錯位了。排查了半天發(fā)現(xiàn)是數(shù)據(jù)源里的 key 用的不是業(yè)務 id而是前端根據(jù)數(shù)組下標拼出來的。問題在于排序之后數(shù)組下標完全變了diff 時新舊節(jié)點對不上導致節(jié)點雖然復用了但里面的內容還是舊數(shù)據(jù)。后來我把 key 換成了業(yè)務數(shù)據(jù)里穩(wěn)定的主鍵錯位問題立刻消失。這里有個經(jīng)驗key 必須和數(shù)據(jù)本身強相關而不能和數(shù)據(jù)位置相關。如果后端沒有返回穩(wěn)定 id寧可在前端生成一個和內容綁定的哈希值也不要圖省事用 index。4.2 視圖不更新原來是引用比較惹的禍還有一次列表數(shù)據(jù)明明變了頁面卻紋絲不動。后來定位到問題出在 diff 的前置判斷我在更新節(jié)點時先比較了新舊 vnode 的 props而 props 是個對象。新對象和舊對象雖然是不同引用但內容一樣于是對比邏輯認為“沒有變化”直接跳過了更新。這個問題的根源是淺比較的誤判。解決方式是渲染入口不比較整個 props 對象而是把 props 拆成一個個基礎字段進行比較同時給業(yè)務方約定如果數(shù)據(jù)內容真的變了必須生成新的 props 對象而不是直接修改原對象。4.3 頁面卡頓居然是因為“過度渲染”項目跑到后面我發(fā)現(xiàn)頁面數(shù)據(jù)量一大就開始卡。打開性能面板一看絕大多數(shù)時間都花在 diff 上而不是 DOM 操作上。原因是每輪更新我都從根節(jié)點開始完整 diff 整棵虛擬節(jié)點樹即使只有底部一個列表變了上層的導航、側欄、頁頭也白白跑了一遍對比。優(yōu)化方案是給節(jié)點加“臟檢查”標記只有那些 props 或子節(jié)點引用發(fā)生變化的節(jié)點才需要進入 diff沒有變化的整棵子樹直接跳過。這個優(yōu)化讓大頁面更新耗時下降了接近一半。但臟檢查也會帶來隱患如果業(yè)務代碼在修改數(shù)據(jù)時不小心直接改原對象并保留了引用臟檢查就判斷不出變化。所以我在更新入口處做了強制約束每次更新必須傳入一個新的 state 引用內部再用淺比較判斷哪些子樹需要真正 render。4.4 根容器清空時的事件代理失效用過事件代理后理論上節(jié)點卸載不再需要關心事件。但有次我直接把整個根容器的innerHTML清空了結果所有點擊事件全部失效。一開始很費解代理不是掛在根容器上嗎按理說子節(jié)點沒了根容器還在事件應該還能觸發(fā)。仔細一看才反應過來我把代理監(jiān)聽器也綁在根容器內部的一個子節(jié)點上清空innerHTML把這個子節(jié)點也干掉了。后來把代理監(jiān)聽器綁定在真正的外層容器上并保證它不被內部操作影響問題才解決。這個坑提醒我一個原則代理監(jiān)聽的掛載節(jié)點必須和渲染管理的節(jié)點嚴格分離。渲染代碼可以清空內部內容但絕不能碰外層容器本身。4.5 常見問題速查表現(xiàn)象可能原因排查思路列表節(jié)點錯位key 與數(shù)據(jù)內容無關檢查 key 是否使用穩(wěn)定業(yè)務標識頁面完全沒更新新舊 state 引用相同確認更新時生成了新的對象引用點擊事件偶爾失效代理節(jié)點被誤清空或阻止冒泡確認代理掛載節(jié)點是否安全大列表渲染卡頓完整 diff 整棵節(jié)點樹增加臟檢查跳過未變化子樹輸入框光標跳動value 屬性被重復設置屬性對比時增加相等判斷5. 實測數(shù)據(jù)與優(yōu)化取舍5.1 一個千級節(jié)點的對照實驗為了驗證效果我用同一個模擬頁面做了組簡單對比渲染 1000 個列表項每 200ms 更新一批數(shù)據(jù)。對照組用舊代碼直接操作 DOM實驗組跑rea的完整渲染鏈路。最終數(shù)據(jù)是這樣的初始渲染耗時任舊代碼約 320msrea 約 360ms稍慢但差距不大。差異在后續(xù)更新上拉開舊代碼每輪更新平均 90msrea 首輪更新 45ms開啟批量更新和臟檢查后降到 22ms 左右。初始渲染變慢的原因是虛擬節(jié)點的構建和 diff 需要額外計算這在節(jié)點數(shù)少時可以忽略但是節(jié)點數(shù)量大了收益就體現(xiàn)在后續(xù)更新的穩(wěn)定性上。對于實時刷新類頁面體驗提升是非常明顯的舊代碼在連續(xù)數(shù)據(jù)更新時會出現(xiàn)肉眼可見的卡頓和閃爍rea 則是平滑的局部更新。5.2 優(yōu)化優(yōu)先級先減少計算量再優(yōu)化計算速度如果現(xiàn)在讓我重新做一遍優(yōu)化順序會非常明確。第一優(yōu)先是減少 DOM 操作。所有可以合并的更新盡量合并能復用的節(jié)點盡量復用。第二優(yōu)先是減少對比范圍。通過臟檢查跳過未變化子樹比優(yōu)化 diff 本身的算法復雜度更有效。第三才是優(yōu)化 diff 算法細節(jié)比如用雙端指針、緩存映射表等等。很多人在調優(yōu)時容易本末倒置一下就扎到算法細節(jié)里。以我的經(jīng)驗來看大部分性能問題都是“做了不該做的事”而不是“該做的事做得不夠快”。rea的 diff 算法說實話不算多高級但配合調度和臟檢查已經(jīng)能覆蓋掉絕大多數(shù)業(yè)務場景。5.3 這個項目后續(xù)可以怎么擴展做到這一步rea已經(jīng)能支撐實際業(yè)務的日常維護了但離“完美引擎”還差得遠。我后續(xù)規(guī)劃了幾個方向供參考。一是支持異步渲染。目前的渲染是同步的如果頁面特別復雜一次更新依然可能阻塞主線程。可以借鑒時間切片的思想把 diff 拆分成多個小任務在每一幀的空閑時間執(zhí)行。二是支持自定義渲染器。把 DOM 操作從核心邏輯中抽離出去理論上可以換一個canvas后端或者換到其他渲染目標上。當初分層設計時已經(jīng)留了口子但真正抽離還需要些工作量。三是提供 DevTools 面板。把每次 diff 產生的補丁、耗時、節(jié)點變化量可視化地展示出來排查問題會更直觀。這些擴展方向都不難難的是保持核心邏輯足夠克制不加著加著就變成了另一個大型框架。最后再分享一個實操體會項目收尾后我最大的體會是不要急著寫 diff 算法先把數(shù)據(jù)流和掛載流程跑通。一開始我花了很多時間在腦內設計一個“完美”的 diff結果代碼寫了又刪進度停滯。后來干脆先用最笨的順序對比方案把整條鏈路跑通再一步步加入 key 匹配、臟檢查、批量更新。每加一個特性都能立刻看到效果排查問題也更容易定位。渲染引擎這種項目最怕的就是“想一步到位”的心態(tài)。只要狀態(tài)到視圖的對應關系足夠干凈后續(xù)所有優(yōu)化都是水到渠成的事。如果你也在折騰類似的東西希望這篇總結能幫你省點時間。踩坑的細節(jié)還有很多等哪天我把 DevTools 面板做出來了再來分享第二輪。