控制臺里突然刷出一屏[Violation] Forced reflow while executing JavaScript took 87ms然后頁面滾一下來一條、點一下來一條開發(fā)機上還沒什么感覺一上真機就開始滑動粘手打字掉幀——這個場景做 Vue 的同學(xué)基本都躲不掉。這條警告不是報錯不影響功能所以它常年被埋在日志里沒人管但它幾乎是所有頁面越用越卡問題的第一現(xiàn)場。它說的是一件很具體的事JavaScript 執(zhí)行過程中觸發(fā)了強制同步重排Forced reflow瀏覽器為了把最新的布局?jǐn)?shù)據(jù)交還給你被迫中斷當(dāng)前 JS 執(zhí)行提前把渲染流水線跑了一遍這一趟花了 87 毫秒。而 87 毫秒在 60 幀的節(jié)奏里等于你連丟五幀還多。這篇文章想解決的就是這一類問題Vue 項目里為什么特別容易踩到 Forced reflow、怎么用 DevTools 把它釘?shù)骄唧w那一行代碼、讀寫分離到底該怎么寫、第三方庫和動畫場景怎么繞過去。內(nèi)容偏實戰(zhàn)代碼可以整段抄走改適合寫過一兩個 Vue 項目、開始關(guān)心性能但還沒系統(tǒng)整理過渲染流程的同學(xué)如果你只是想知道警告關(guān)掉行不行那答案是不行后面會說為什么。1. 先把這條警告翻譯成人話1.1 瀏覽器渲染一幀要經(jīng)過哪幾步現(xiàn)代瀏覽器的渲染主流程可以粗略拆成五段JavaScript 執(zhí)行 → 樣式計算Style / Recalculate Style→ 布局Layout也就是重排 / Reflow→ 繪制Paint→ 合成Composite。JS 階段你改 DOM、改 class、改 inline style樣式計算把 CSS 規(guī)則解析成每個元素最終的計算樣式布局拿到計算樣式后算出每個盒子在頁面上的精確位置和尺寸繪制把盒子變成像素指令合成把這些指令按圖層拼成你看到的畫面。關(guān)鍵點在于布局這一步是惰性的。你在 JS 里改了el.style.width 200px瀏覽器不會立刻重算布局它只會在內(nèi)部標(biāo)記這個元素的布局臟了然后攢著。攢到什么時候攢到兩種時刻一是真的要畫下一幀了二是有代碼來問它要布局結(jié)果。后者就是災(zāi)難的起點。因為一旦你問它要布局結(jié)果它沒法用舊數(shù)據(jù)糊弄你舊數(shù)據(jù)已經(jīng)過期了只能立刻停下來把樣式計算和布局全部跑完再把答案給你。這中間你的 JS 是被打斷的主線程被布局占滿這就是同步重排。所謂 Forced重點在被迫——瀏覽器本來想拖到幀末一起算的被你逼著提前算了。1.2 到底哪些操作會逼瀏覽器重排能觸發(fā)強制重排的操作本質(zhì)都是讀取幾何信息。這些屬性不是存在元素身上的靜態(tài)值而是布局算完才有的結(jié)果所以讀它們就等于向瀏覽器要賬。常見的清單如下觸發(fā)源典型寫法說明偏移尺寸offsetTopoffsetLeftoffsetWidthoffsetHeight最常被踩的一類循環(huán)里讀它等于開重排循環(huán)客戶區(qū)尺寸clientWidthclientHeightclientTopclientLeft不含邊框常用于算滾動容器可視高度滾動尺寸與位置scrollTopscrollLeftscrollWidthscrollHeight寫scrollTop是寫操作但連著讀就會交替幾何矩形getBoundingClientRect()getClientRects()定位類組件、拖拽、Tooltip 全靠它計算樣式getComputedStyle(el).width等布局相關(guān)屬性讀color未必觸發(fā)讀width必觸發(fā)CSS 變量getComputedStyle(el).getPropertyValue(--x)變量參與了布局計算時同樣要 flush焦點與滾動定位element.focus()scrollIntoView()內(nèi)部需要知道元素位置才能滾動Range 相關(guān)range.getBoundingClientRect()富文本編輯器里非常常見這里有個非常重要的判斷標(biāo)準(zhǔn)很多人搞混連續(xù)讀是安全的連續(xù)寫也是安全的只有讀寫交替才致命。你一口氣讀一百個元素的offsetHeight瀏覽器只會重排一次因為第一次讀之后布局就是干凈的剩下的讀都在用同一份新鮮數(shù)據(jù)你一口氣寫一百個元素的寬高瀏覽器一次都不重排因為布局被推遲到幀末。但你要是讀一個、寫一個、再讀一個、再寫一個那就是一百次完整重排。注意console.log(el.offsetWidth)這種調(diào)試語句本身就是讀操作。有時候你只是加了幾行日志想看看尺寸警告就冒出來了別把這個鍋甩給業(yè)務(wù)代碼。1.3 警告里那個 took 87ms 是怎么來的Chrome 會把每一次強制布局的耗時算出來超過一定閾值經(jīng)驗上單次幾十毫秒級別就會在控制臺記一條 Violation。數(shù)字越大說明這次重排的代價越離譜。為什么能這么大因為一次重排不只是算你這一個元素布局的波及范圍可能是整棵子樹甚至整個文檔。改了外層容器的寬度里面所有依賴百分比的子元素、所有的文本換行、所有的 flex/grid 分配都要跟著重算。一個幾千行的表格一次重排干到幾十毫秒一點都不夸張。更麻煩的是它會累積。你在mousemove里搞一次強制重排鼠標(biāo)移動一秒觸發(fā)六十次那就是六十次重排主線程被切成碎片用戶看到的就是拖拽跟不上手。單看一條警告好像無所謂乘上觸發(fā)頻率就是災(zāi)難。2. Vue 項目為什么格外容易踩這個坑2.1 響應(yīng)式更新的批處理救了你也騙了你Vue 3 的更新是異步批處理的你在一個 tick 里改了十個ref它只會在微任務(wù)隊列里 flush 一次patch一次 DOM。這本身是非常好的設(shè)計它天然把寫集中起來了。問題出在讀上——Vue 只幫你批處理了寫沒管你的讀。于是很常見的寫法就變成了這樣組件里某個方法先改了一個狀態(tài)然后await nextTick()接著遍歷 DOM 子節(jié)點讀尺寸讀完根據(jù)尺寸再改一次狀態(tài)。這一輪下來寫、讀、寫交替得非常干凈每一次讀都在逼瀏覽器 flush。而且因為 Vue 的patch是深度優(yōu)先遍歷虛擬 DOM一個父組件的更新可能牽動幾十個子組件同時掛載你在onMounted里讀一次尺寸就是幾十次讀擠在同一幀如果中間還夾雜著子組件的寫操作交替就發(fā)生了。還有一個隱蔽的點Vue 的nextTick用的是微任務(wù)Promise.then它跑在瀏覽器渲染之前的任意時刻跟幀的節(jié)奏沒關(guān)系。你在微任務(wù)里讀布局瀏覽器一樣得立刻滿足你。所以nextTick不是等渲染完它只是等 DOM 更新完DOM 更新完不代表布局算完了。這個區(qū)別決定了你很多我已經(jīng)nextTick了為什么還有警告的困惑。2.2 組件化本身會制造隱形讀寫交替單文件組件寫多了你很難一眼看出哪里在讀哪里在寫因為讀寫散落在不同組件里。舉個我真實遇到過的例子一個父組件列表子組件里有個mounted鉤子用于根據(jù)自身寬度決定標(biāo)題要不要省略號。子組件掛載時會讀自己的clientWidth而父組件在插入這些子組件之前剛剛設(shè)置過容器的padding。結(jié)果就是子組件每掛載一個讀一次寬度而父組件的樣式寫入又讓布局臟掉下一個子組件讀的時候又得重排。一百個子組件就是一百次重排控制臺刷屏。這種問題在組件層級越深、復(fù)用越多的項目里越嚴(yán)重因為寫操作發(fā)生在祖先讀操作發(fā)生在后代中間隔著好幾層組件邊界你根本不會把它們聯(lián)系起來。這也是為什么我認為這條警告不能只靠看到就改得建立一個意識任何讀 DOM 尺寸的代碼都要問一句我前面有沒有剛寫過樣式。2.3 Transition 和動畫鉤子里的固定開銷Vue 的Transition在實現(xiàn)上為了拿到過渡起點需要在元素插入后、添加過渡類名之前讀取一次布局信息這個操作本身就會強制重排。單個元素?zé)o所謂一兩個毫秒的事但列表過濾、v-show批量切換、路由切換帶動畫的時候同一幀內(nèi)可能有幾十個元素同時走這套流程代價就上來了。v-show還有額外一層display: none和display: block的切換會直接讓布局失效切完再去讀尺寸就是一次完整重排。有些同學(xué)為了做折疊展開動畫用v-show配合讀取內(nèi)容高度在長列表里滾動著展開卡頓感會非常明顯。2.4 第三方庫是重災(zāi)區(qū)而且你往往改不動ECharts、Swiper、各類拖拽庫、虛擬表格、富文本編輯器這些庫的定位邏輯基本都建立在getBoundingClientRect()上。它們初始化的時候要量容器尺寸resize的時候要重新量彈出面板的時候要算位置。你沒法改它們的源碼只能從兩個方向下手控制調(diào)用時機和控制調(diào)用頻率。時機上別在mounted同步初始化一屏幾十個圖表讓它們在requestAnimationFrame里排隊頻率上resize回調(diào)必須防抖而且防抖的落地方式最好是rAF節(jié)流加時間閾值不是簡單的setTimeout。這部分在第 5 節(jié)會展開寫具體代碼。3. 把這個警告釘?shù)骄唧w那一行代碼3.1 Performance 面板的正確讀法控制臺的 Violation 只告訴你發(fā)生了不告訴你在哪。真正定位得靠 Performance 面板。操作步驟是打開 DevTools切到 Performance點左上角的錄制按鈕然后在頁面上復(fù)現(xiàn)卡頓操作滾動、拖拽、切換列表三五秒后停止錄制。拿到火焰圖之后看頂上那幾條橫軸色塊。紫色偏藍的是 Layout布局深紫偏紅的是 Recalculate Style。如果你看到一串密密麻麻的小紫色塊每個都很短但數(shù)量巨大中間還夾著黃色Scripting的小塊那就是典型的 layout thrashing——讀寫交替的指紋。如果是一個巨大的紫色塊那說明是單次重排范圍太大方向就不一樣了該考慮的是減少布局波及面比如contain、content-visibility。再往下看切換到 Bottom-Up 或者 Call Tree 視圖按 Self Time 排序。通常在紫色塊下面能直接看到你的業(yè)務(wù)函數(shù)名點進去就能定位到源碼行。如果看到的是一堆getBoundingClientRect、offsetHeight之類的原生調(diào)用展開它的調(diào)用棧業(yè)務(wù)代碼一定在里面。3.2 用代碼給自己埋點抓出超時的那一次Performance 面板好用但它只能事后看而且信息量大、有學(xué)習(xí)成本。想快速定位我習(xí)慣直接給關(guān)鍵 API 打個補丁統(tǒng)計每次耗時和調(diào)用棧。這段代碼只在開發(fā)環(huán)境加上線前刪掉或包在if (import.meta.env.DEV)里// dev-perf.js —— 只在開發(fā)環(huán)境引入 if (import.meta.env.DEV) { const wrap (obj, name) { const raw obj[name] if (typeof raw ! function) return obj[name] function (...args) { const t0 performance.now() const result raw.apply(this, args) const cost performance.now() - t0 // 閾值可以調(diào)抓大放小 if (cost 5) { console.warn([slow ${name}] ${cost.toFixed(1)}ms, this) console.trace() } return result } } wrap(Element.prototype, getBoundingClientRect) wrap(Element.prototype, getClientRects) wrap(Range.prototype, getBoundingClientRect) // 幾何屬性是 getter用 defineProperty 包一層 const geometryProps [offsetWidth, offsetHeight, offsetTop, offsetLeft, clientWidth, clientHeight, scrollWidth, scrollHeight] geometryProps.forEach((prop) { const owner prop.startsWith(scroll) ? Element.prototype : HTMLElement.prototype const desc Object.getOwnPropertyDescriptor(owner, prop) if (!desc || !desc.get) return Object.defineProperty(owner, prop, { ...desc, get() { const t0 performance.now() const value desc.get.call(this) const cost performance.now() - t0 if (cost 5) { console.warn([slow read ${prop}] ${cost.toFixed(1)}ms, this) console.trace() } return value } }) }) }這里有個細節(jié)值得說offsetWidth這類屬性是getter不是方法所以不能像getBoundingClientRect那樣直接替換函數(shù)得用Object.getOwnPropertyDescriptor拿到原始 getter 再包一層。另外注意scrollWidth掛在Element上offsetWidth掛在HTMLElement上掛錯原型鏈會報錯我上面做了個簡單區(qū)分。埋點閾值別設(shè)太小5ms 以下的不看。跑一遍頁面控制臺會直接告訴你哪一行慢、調(diào)用棧是什么比在火焰圖里翻半天高效得多。3.3 一張現(xiàn)場排查清單真到了線上或者別人移交的項目里時間緊不可能慢慢打補丁。我整理了一張按現(xiàn)象反推原因的表先對號入座再動手現(xiàn)場現(xiàn)象大概率原因第一步做什么拖拽/鼠標(biāo)跟隨明顯延遲mousemove里讀getBoundingClientRect并寫樣式把讀取挪到mousedown移動過程只寫transform長列表滾動頓挫列表項內(nèi)讀offsetTop做吸附/瀑布流改用IntersectionObserver或緩存偏移量輸入框打字掉幀input事件里讀scrollHeight做高度自適應(yīng)用rAF節(jié)流 textarea的field-sizing或緩存彈層/下拉定位抖動Popper 類庫在滾動事件里持續(xù)測量限制resize/scroll觸發(fā)源或用 CSS 定位一屏圖表初始化時白屏卡住多個圖表mounted同步初始化爭搶主線程用rAF分批初始化配合骨架屏折疊展開動畫卡v-show切換后立刻讀內(nèi)容高度改v-if加緩存高度或用grid-template-rows動畫窗口拉伸時整體卡頓resize回調(diào)沒防抖全量重排rAF節(jié)流只在幀內(nèi)算一次這張表覆蓋了八成左右的常見情況。如果你遇到的警告既不屬于拖拽也不屬于滾動那大概率是某個第三方組件的初始化或resize用第 3.2 節(jié)的埋點腳本跑一遍最快。4. 核心解藥讀寫分離到底怎么做4.1 為什么讀寫分離能根治原理其實一句話把同一幀內(nèi)所有的讀集中在前半段所有的寫集中在后半段讀之前保證布局是干凈的寫之后不再去問布局要數(shù)據(jù)。這樣一幀內(nèi)最多強制重排一次甚至零次如果讀的時候沒有臟布局。這套思路業(yè)界叫 fastdom名字來自 FastDOM 這個庫核心就是一個兩階段隊列measure放讀任務(wù)mutate放寫任務(wù)統(tǒng)一調(diào)度。自己實現(xiàn)一個簡化版完全夠用五十行以內(nèi)。4.2 一個可以直接抄的調(diào)度器// scheduler.js const readQueue [] const writeQueue [] let rafId 0 let flushing false function flush() { rafId 0 flushing true // 第一階段集中讀此時布局應(yīng)當(dāng)是最新的 const reads readQueue.splice(0) for (let i 0; i reads.length; i) { try { reads[i]() } catch (e) { console.error(e) } } // 第二階段集中寫寫操作不會立刻觸發(fā)重排 const writes writeQueue.splice(0) for (let i 0; i writes.length; i) { try { writes[i]() } catch (e) { console.error(e) } } flushing false // 寫入過程中如果又產(chǎn)生了新的任務(wù)常見于寫里嵌套了讀排到下一幀 if (readQueue.length || writeQueue.length) schedule() } function schedule() { if (rafId) return rafId requestAnimationFrame(flush) } export function measure(fn) { readQueue.push(fn) // 關(guān)鍵如果當(dāng)前不在 flush 中說明還沒到幀可以立即安排 // 如果正在寫階段追加讀任務(wù)絕不能同步執(zhí)行否則立刻退化成 thrashing schedule() } export function mutate(fn) { writeQueue.push(fn) if (!flushing) schedule() }有三個地方是我踩過坑之后特意加固的第一schedule用requestAnimationFrame而不是微任務(wù)。微任務(wù)在當(dāng)前宏任務(wù)結(jié)束時就跑了可能還在同一幀的 JS 階段里讀到的布局照樣要 flushrAF回調(diào)發(fā)生在瀏覽器決定要渲染這一幀的時刻此時上一輪寫入的樣式已經(jīng)被瀏覽器納入計算讀起來更干凈。第二用一個flushing標(biāo)志判斷當(dāng)前階段。如果mutate階段的函數(shù)里又調(diào)了measure絕對不能同步執(zhí)行那個讀否則你精心設(shè)計的讀寫分離當(dāng)場失效。我的做法是讓它在flush結(jié)束時檢測隊列非空重新排一幀。第三每個任務(wù)包try/catch。調(diào)度器是全局的一個任務(wù)拋錯不能拖垮整批任務(wù)線上排查時這一點很關(guān)鍵。4.3 在 Vue 組件里怎么落地有了調(diào)度器業(yè)務(wù)代碼的改法就很機械了——把讀包進measure把寫包進mutate。但 Vue 里有幾個地方要注意。第一不要在measure回調(diào)里直接改響應(yīng)式狀態(tài)。改狀態(tài)會觸發(fā) Vue 的更新調(diào)度雖然它也是異步的但在這個上下文里容易讓數(shù)據(jù)流變得不可預(yù)測。清爽的做法是讀階段把結(jié)果收集到一個普通對象里寫階段再拿這些數(shù)據(jù)統(tǒng)一提交給 Vue。第二await nextTick()之后不要直接讀尺寸。正確的姿勢是import { nextTick } from vue import { measure, mutate } from ./scheduler async function syncLayout() { await nextTick() // 等 DOM 更新完 measure(() { // 再等一個渲染幀讀干凈布局 const items [...listRef.value.children] const heights items.map(el el.offsetHeight) // 連續(xù)讀只重排一次 mutate(() { items.forEach((el, i) { el.style.setProperty(--row-h, heights[i] px) // 連續(xù)寫 }) }) }) }注意這里讀和寫的順序先nextTick保證 DOM 存在再measure保證布局新鮮讀的時候用map一次性收集完不要在循環(huán)里寫然后mutate里批量寫。這套流程下來整個函數(shù)最多觸發(fā)一次強制重排。第三組件卸載時要清理。調(diào)度器是模塊級的如果組件卸載后隊列里還有引用著已銷毀 DOM 的回調(diào)讀的時候就會拿到null。我的處理是在回調(diào)里做空值判斷或者給任務(wù)加一個cancelled標(biāo)記在onUnmounted里置位。4.4 什么情況下不用調(diào)度器直接 rAF 就夠調(diào)度器解決的是多個模塊零散讀寫的問題。如果你只有一個函數(shù)讀寫都在里面那直接requestAnimationFrame更輕let pending false let cachedRect null function onScroll() { if (!pending) { pending true requestAnimationFrame(() { pending false // 這里集中做讀寫注意讀必須放在寫前面 const top container.getBoundingClientRect().top sticky.style.transform top 0 ? translateY(${-top}px) : none }) } }這個模式叫rAF 節(jié)流本質(zhì)上是把一個高頻事件壓縮成每幀最多執(zhí)行一次。它在滾動、拖拽、mousemove、resize場景里幾乎是萬能的代碼量小、沒有依賴建議先把這個用起來再考慮上調(diào)度器。提示resize事件還有個更現(xiàn)代的替代品ResizeObserver。它比window上的resize精準(zhǔn)得多能觀察單個元素但要注意它的回調(diào)本身也是布局之后、繪制之前執(zhí)行回調(diào)里讀尺寸是安全的寫尺寸卻可能觸發(fā)循環(huán)。要寫就包一層rAF或者直接在回調(diào)里做防抖。5. 高頻場景逐個擊破5.1 拖拽把讀取挪到事件開始那一刻拖拽是 Forced reflow 的頭號來源。壞的寫法幾乎人人寫過// 反面教材每一幀都在讀寫交替 function onMouseMove(e) { const rect box.getBoundingClientRect() // 讀強制重排 box.style.left rect.left e.movementX px // 寫布局臟了 box.style.top rect.top e.movementY px }每一次mousemove都是讀一次、寫一次而且讀的還是自己剛剛寫臟的元素重排跑不掉了。正確做法是把狀態(tài)存在變量里事件開始時讀一次移動過程純計算加寫const state { startX: 0, startY: 0, originLeft: 0, originTop: 0, moving: false, x: 0, y: 0 } let rafId 0 function onMouseDown(e) { const rect box.getBoundingClientRect() // 整個拖拽過程只讀這一次 state.startX e.clientX state.startY e.clientY state.originLeft rect.left state.originTop rect.top state.moving true document.addEventListener(mousemove, onMouseMove) } function onMouseMove(e) { if (!state.moving) return state.x state.originLeft (e.clientX - state.startX) state.y state.originTop (e.clientY - state.startY) if (!rafId) rafId requestAnimationFrame(paint) } function paint() { rafId 0 // 用 translate3d 而不是 left/top box.style.transform translate3d(${state.x}px, ${state.y}px, 0) }兩個改動帶來兩個收益第一整個拖拽只強制重排一次第二用transform替代left/top元素在合成層上移動連布局和繪制都省了只剩下合成流暢度是數(shù)量級的差別。這個技巧是我做拖拽交互時最常用的一招記住動位置用 transform不動 left/top基本能躲掉一半的卡頓。5.2 長列表與虛擬滾動v-for渲染幾千條數(shù)據(jù)然后在某個方法里遍歷子元素讀offsetTop這是瀑布流和吸附滾動的經(jīng)典寫法也是經(jīng)典的重排炸彈。改法有兩條路。輕量的一條是緩存加批量在列表數(shù)據(jù)變化之后用一個measure任務(wù)一次性把所有子元素的偏移量讀出來存到數(shù)組里之后滾動過程中只查數(shù)組不碰 DOM。注意這個緩存要在容器尺寸變化時失效重建ResizeObserver是合適的鉤子。徹底的一條是上虛擬滾動。虛擬滾動的核心思想是只渲染視口內(nèi)的元素元素數(shù)量從幾千降到幾十任何遍歷操作的代價都變得可以接受。如果要自己實現(xiàn)關(guān)鍵點是行高固定或提前測量、用絕對定位撐開滾動高度、滾動事件用rAF節(jié)流。行高不固定的場景通常做法是先按估算行高渲染再用ResizeObserver或者measure任務(wù)逐個修正真實高度并回填緩存。對于大多數(shù)業(yè)務(wù)項目我建議直接用成熟庫而不是自己寫。選庫的時候看一眼它在滾動過程中有沒有讀取getBoundingClientRect有的庫為了做滾動到指定項會在每次滾動時測量那就得配個節(jié)流。5.3 動畫優(yōu)先動不會觸發(fā)布局的屬性做動畫有一條鐵律只動transform和opacity其他屬性盡量別碰。原因是這兩個屬性在合成階段處理改它們不會引起樣式重算和布局重排而改width、height、margin、padding、top、left、font-size這些必然重排而且很可能牽連一大片。Vue 的Transition默認用的是opacity和transform之外的類名切換所以自定義過渡的時候要自己寫對。常見的折疊展開如果想平滑別用height: 0到height: autoauto沒法過渡而且會重排用grid-template-rows: 0fr到1fr或者transform: scaleY加transform-origin。前者是純粹的小技巧兼容性不錯。如果用 Vue 的 JS 鉤子做動畫before-enter、enter這類記得每次在enter回調(diào)里做一次el.offsetHeight強制重排來激活過渡這是標(biāo)準(zhǔn)做法但別在循環(huán)里對幾十個元素同時做。批量過渡的場景我通常改成 CSS 類切換加transition-delay錯開讓瀏覽器自己安排。5.4 第三方庫控時機、控頻率、控范圍第三方庫有三個可下手的地方?？貢r機指不要在mounted里同步初始化。一屏十個圖表每個初始化都要量容器、算布局堆在一起就是幾百毫秒。把它們?nèi)MrAF或者用IntersectionObserver做進視口才初始化onMounted(() { const io new IntersectionObserver((entries) { entries.forEach((entry) { if (!entry.isIntersecting) return io.unobserve(entry.target) requestAnimationFrame(() initChart(entry.target)) }) }, { rootMargin: 200px }) chartEls.value.forEach(el io.observe(el)) })rootMargin: 200px是提前量用戶還沒滾到就初始化完了體驗更順?？仡l率指給庫的resize、scroll回調(diào)加節(jié)流。很多庫自己不做這件事。如果它的 API 允許傳回調(diào)就在外面包一層rAF節(jié)流如果它是監(jiān)聽window.resize的可以自己在初始化前先把尺寸算好傳進去減少它內(nèi)部測量的次數(shù)?？胤秶赣?CSS 限制布局的波及面下一節(jié)講。5.5 CSS 側(cè)的兩個低成本優(yōu)化contain屬性可以讓瀏覽器知道這個元素的內(nèi)部布局不影響外部從而把重排范圍鎖在局部。常用值是contain: layout paint布局和繪制都不外溢列表項、卡片、彈層都很適合加。加了之后改動內(nèi)部的尺寸不會引起整個頁面的布局重算收益非常直接。content-visibility: auto更進一步讓屏幕外元素的渲染被跳過。長文檔、長列表里效果明顯但要配contain-intrinsic-size給它一個占位尺寸否則滾動條會跳。這兩個屬性現(xiàn)代瀏覽器都支持得不錯屬于加一行、收益立竿見影的類型。還有will-change: transform很多人拿它當(dāng)萬金油到處加。它的作用是提前把元素提升為獨立合成層減少動畫過程中的重排和重繪。但別濫用——每個合成層都要占顯存幾十上百個層會把內(nèi)存吃光反而更卡。我的習(xí)慣是只在確實要做高頻動畫的元素上加動畫結(jié)束就移除。6. 常見問題與避坑速查6.1 問題速查表問題原因解決nextTick之后讀尺寸仍報警告nextTick是微任務(wù)不等渲染幀讀操作包進rAF或調(diào)度器單個元素動畫也報警告動畫屬性觸發(fā)了布局width/height/top改用transform/opacity只在低端機上卡高端機重排耗時低低于閾值不報用 Performance 面板看別依賴控制臺加了will-change反而更卡合成層數(shù)量過多占顯存只在動畫期間加結(jié)束后移除resize里代碼很少也卡沒節(jié)流一次拉伸觸發(fā)幾十次用rAF節(jié)流并加最小間隔生產(chǎn)環(huán)境沒有警告Violation 只在 DevTools 打開時采集生產(chǎn)排查靠 Performance 性能指標(biāo)組件卸載后報錯調(diào)度隊列里的回調(diào)引用了已銷毀 DOM回調(diào)內(nèi)判空或加取消標(biāo)記列表用index做 key 更卡復(fù)用錯位導(dǎo)致大量 DOM 重建用穩(wěn)定的業(yè)務(wù) id 做 key6.2 幾個容易搞反的細節(jié)第一個反直覺的點getComputedStyle讀color、font-weight這類純繪制屬性通常不會觸發(fā)重排但讀width、height、margin這些布局屬性一定觸發(fā)。所以別一看到getComputedStyle就緊張看你讀的是哪個屬性。第二個scrollTop的讀取是重排的來源之一但對滾動容器來說它更常見的坑是讀scrollHeight算總高。這個屬性依賴全部子元素布局代價很高能緩存就緩存。第三個v-if和v-show在這件事上的表現(xiàn)不同。v-if是增刪節(jié)點插入新節(jié)點必然讓布局臟掉v-show是切換display同樣讓布局臟掉。兩者都不省區(qū)別在渲染成本和狀態(tài)保持上別指望用v-show能繞開重排。第四個offsetTop是相對于offsetParent的不是相對于視口。很多同學(xué)算錯位置是因為沒注意offsetParent會被position: relative的祖先改變。算視口坐標(biāo)老老實實用getBoundingClientRect。6.3 我在實際項目里踩過的坑第一個坑是埋點本身拖慢了頁面。有一段時間我在Element.prototype上包了好幾層補丁本地跑得好好的一上真機開發(fā)包就卡成幻燈片。原因是補丁里的performance.now()和console.trace()本身開銷就不小console.trace()尤其重在mousemove高頻場景里直接拖垮主線程。后來我改成只在超過閾值且做了采樣比如每 20 次記錄一次的情況下才打日志問題就沒了。第二個坑是調(diào)度器里的死循環(huán)。我最初的版本在flush結(jié)束時無條件重新schedule()結(jié)果一個任務(wù)里不斷往隊列里塞新任務(wù)把rAF變成了忙循環(huán)頁面反而更卡。后來加了單幀最多迭代兩次的限制超出的任務(wù)順著排到下一幀才穩(wěn)下來。第三個坑是以為transform是萬能藥。transform確實不觸發(fā)布局但如果它作用的元素上有一個filter或者復(fù)雜的box-shadow照樣會觸發(fā)重繪代價并不低。還有transform會影響position: fixed子元素的定位基準(zhǔn)做全屏遮罩的時候要特別注意。第四個坑比較隱蔽document.body上的 class 切換會引發(fā)全頁重排。項目里做主題切換、字號切換的時候我在body上切了個 class里面包含font-size變量結(jié)果整頁所有文本重新?lián)Q行一次重排上百毫秒。后來改成用 CSS 變量配合contain把影響限制在主要內(nèi)容區(qū)才把這一下優(yōu)化掉。說到底Forced reflow 這條警告的價值不在于它本身而在于它是一個信號——它告訴你你的代碼正在用一種命令式、逐步確認的方式跟瀏覽器打交道而瀏覽器更希望你一次說清楚。把讀和寫分開、把動位置交給transform、把高頻事件壓到每幀一次這三件事做到位控制臺里那串紅色的[Violation]基本就會消失頁面手感也會跟著變一個檔次。