1. FLIP 是什么——先看它解決的問(wèn)題布局動(dòng)畫在網(wǎng)頁(yè)里是個(gè)很微妙的東西。視覺上你只是想讓某個(gè)元素從 A 點(diǎn)挪到 B 點(diǎn)或者從一行變成兩行代碼里卻要處理一整套瀏覽器的渲染機(jī)制。直接用top/left或者width/height做過(guò)渡動(dòng)畫結(jié)果往往不理想——要么一頓一頓的要么干脆直接跳到終點(diǎn)用戶體驗(yàn)非常生硬。這是因?yàn)檫@些屬性一旦變化瀏覽器就得重新計(jì)算布局也就是常說(shuō)的回流reflow后續(xù)還得重繪repaint每一步都開銷巨大動(dòng)畫自然就掉幀了。FLIP 策略就是為了解決這個(gè)痛點(diǎn)被提出的它的核心思路特別直白既然改布局屬性會(huì)引發(fā)昂貴的回流那能不能只讓元素“看起來(lái)”在動(dòng)實(shí)際上靠合成層把位移、縮放這些效果交給 GPU 處理答案就是 FLIP 四步法First、Last、Invert、Play。這套思路最早由 Paul Lewis 推廣如今已經(jīng)在各大前端團(tuán)隊(duì)的項(xiàng)目里用得非常成熟了。我在這篇文章里會(huì)把它拆開揉碎先講原理再帶你把核心代碼寫出來(lái)最后結(jié)合幾個(gè)真實(shí)場(chǎng)景講講我踩過(guò)的坑和排查技巧。整個(gè)過(guò)程不需要你有多深的圖形學(xué)背景只要會(huì) JavaScript 和 CSS 的 transform 操作就能上手。適合誰(shuí)看剛接觸前端動(dòng)畫、被“卡頓”折磨過(guò)的開發(fā)者或者已經(jīng)在團(tuán)隊(duì)里做動(dòng)效規(guī)范、想在布局變化這件事上找到一套通用方案的人都能從這篇里拿到可直接落地的代碼和思路。我會(huì)盡量用“人話”解釋每個(gè)環(huán)節(jié)的為什么而不是只丟給你一段封裝好的函數(shù)。2. 四階段拆解——從 First 到 Play每一步在干什么2.1 First 與 Last記錄前后狀態(tài)但別急著改FLIP 的第一步是記錄元素的初始位置也就是 First把元素的當(dāng)前幾何數(shù)據(jù)存下來(lái)通常包括x、y、scaleX、scaleY、width、height這些。獲取這些數(shù)據(jù)的標(biāo)準(zhǔn)方式是getBoundingClientRect()它返回的是元素相對(duì)于視口的位置和尺寸對(duì)于動(dòng)畫計(jì)算來(lái)說(shuō)正好。第二步是 Last記錄元素在布局變化之后的最終位置。這里有個(gè)容易忽略的細(xì)節(jié)改變布局的代碼比如加 class、改樣式、重新排序 DOM必須先執(zhí)行然后要強(qiáng)制讀取一次布局?jǐn)?shù)據(jù)才能拿到正確的 Last 值。問(wèn)題在于瀏覽器對(duì)樣式計(jì)算和布局都做了異步批量處理如果你在修改樣式之后立即調(diào)用getBoundingClientRect()瀏覽器會(huì)強(qiáng)制同步刷新布局這本身就是一次成本不低的操作。所以需要讓修改布局和執(zhí)行動(dòng)畫的計(jì)算不在同一幀里完成最常用的手法就是用requestAnimationFrame包一層。注意修改完布局后如果你在同一個(gè)同步任務(wù)里直接調(diào)getBoundingClientRect()瀏覽器為了給出準(zhǔn)確結(jié)果會(huì)同步觸發(fā)一次 layout這一下的開銷在復(fù)雜頁(yè)面上不容小覷。正確做法是先改完布局在下一幀回調(diào)里再測(cè)量 Last 值。我一般會(huì)這樣組織兩個(gè)階段// 1. First: 記錄初始狀態(tài) const first element.getBoundingClientRect(); // 2. 觸發(fā)布局變化, 例如添加一個(gè)類 element.classList.add(expanded); // 3. Last: 等下一幀再記錄最終狀態(tài) requestAnimationFrame(() { const last element.getBoundingClientRect(); // 后面再算差異、做動(dòng)畫 });2.2 Invert反算差值這是整個(gè)算法的靈魂拿到 First 和 Last 之后就輪到最巧妙的 Invert 階段了。這一步要做的是計(jì)算兩個(gè)狀態(tài)之間的變化量然后把元素“欺騙”回原來(lái)的位置。具體的做法是這樣先算出deltaX first.left - last.left、deltaY first.top - last.top再把transform設(shè)置成translate(deltaX, deltaY)。此時(shí)元素雖然在布局上已經(jīng)處于終點(diǎn)位置但通過(guò) transform 的位移它在視覺上仍然停留在起點(diǎn)。關(guān)鍵就在這里transform 的變化不會(huì)觸發(fā)重排只會(huì)在合成階段處理所以開銷遠(yuǎn)小于修改 top/left。同樣的思路也適用于尺寸變化。如果兩個(gè)狀態(tài)的寬度不同可以算出scaleX first.width / last.width然后把它加進(jìn) transform 里讓元素在縮放前和縮放后看起來(lái)“什么都沒變”。我這里說(shuō)“看起來(lái)”是因?yàn)閷?shí)際上它已經(jīng)被布局系統(tǒng)放到最終位置了只是視覺上被 transform 拉回了起點(diǎn)后續(xù)動(dòng)畫要做的就是把這個(gè) transform 變成“無(wú)”。2.3 Play把 transform 動(dòng)畫到 0動(dòng)畫就完成了最后一步 Play是把上一步的臨時(shí) transform 平滑地過(guò)渡到none讓元素從“視覺起點(diǎn)”一路滑到“真實(shí)終點(diǎn)”。因?yàn)檫@段動(dòng)畫只涉及 transform瀏覽器可以在合成線程上完成幀率通常非常穩(wěn)定。實(shí)現(xiàn)方式有兩種一種是用 CSS transition給元素加上transition: transform 0.3s cubic-bezier(...)然后把 transform 清零另一種是用 WAAPIWeb Animations API的element.animate()這種方式更靈活可以隨時(shí)取消或監(jiān)聽結(jié)束事件。我用得比較多的是 WAAPI因?yàn)樗膭?dòng)畫回調(diào)機(jī)制更清晰而且方便做批量管理element.animate( [ { transform: translate(${deltaX}px, ${deltaY}px) }, { transform: none } ], { duration: 300, easing: cubic-bezier(0.25, 0.8, 0.25, 1) } );到這一幀布局已經(jīng)穩(wěn)定在最終狀態(tài)transform 只是視覺上的偏移動(dòng)畫結(jié)束后瀏覽器不會(huì)產(chǎn)生“回彈”或閃爍。這就是 FLIP 的全部執(zhí)行路徑——聽起來(lái)不復(fù)雜但真正在項(xiàng)目里用順需要想清楚很多邊界情況。3. 手寫一個(gè)核心實(shí)現(xiàn)——從零搭出可復(fù)用的 FLIP 工具3.1 最簡(jiǎn)版本代碼結(jié)構(gòu)在寫完整工具之前先看一個(gè)最精簡(jiǎn)的實(shí)現(xiàn)。這個(gè)版本適合理解 FLIP 的主干邏輯不處理太多邊界但足夠讓你跑通一個(gè)最基本的使用場(chǎng)景列表里兩個(gè)元素交換位置。function flip(element, { duration 300, easing cubic-bezier(0.25, 0.8, 0.25, 1) } {}) { const first element.getBoundingClientRect(); // 這里由外部在本次調(diào)用后改變布局 // 比如把元素在 DOM 里移動(dòng)位置 requestAnimationFrame(() { const last element.getBoundingClientRect(); const deltaX first.left - last.left; const deltaY first.top - last.top; const scaleX first.width / last.width ; const scaleY first.height / last.height; element.animate( [ { transform: translate(${deltaX}px, ${deltaY}px) scale(${scaleX}, ${scaleY}), transformOrigin: top left }, { transform: none, transformOrigin: top left } ], { duration, easing } ); }); }這段代碼已經(jīng)覆蓋了 FLIP 的核心四個(gè)階段。transformOrigin設(shè)為top left是為了讓縮放方向符合直覺否則元素會(huì)朝中心縮放視覺上會(huì)偏離你預(yù)期的對(duì)齊位置。3.2 批量處理多個(gè)元素同時(shí)動(dòng)真實(shí)項(xiàng)目里很少只有一個(gè)元素在動(dòng)更常見的場(chǎng)景是一組元素同時(shí)發(fā)生變化。比如排序后的列表可能兩三個(gè)元素都換了位置此時(shí)如果給每個(gè)元素單獨(dú)做一套 First/Last 記錄代碼會(huì)變得很臃腫。我會(huì)用一個(gè)數(shù)組把多個(gè)元素統(tǒng)一管理function flipAll(elements, { duration 300 } {}) { const firstMap new Map(); elements.forEach((el) { firstMap.set(el, el.getBoundingClientRect()); }); // 在此處執(zhí)行布局變化 requestAnimationFrame(() { elements.forEach((el) { const first firstMap.get(el); const last el.getBoundingClientRect(); const deltaX first.left - last.left; const deltaY first.top - last.top; const scaleX first.width / last.width; const scaleY first.height / last.height; el.animate( [ { transform: translate(${deltaX}px, ${deltaY}px) scale(${scaleX}, ${scaleY}), transformOrigin: top left }, { transform: none, transformOrigin: top left } ], { duration, easing: ease-out } ); }); }); }3.3 進(jìn)入和離開動(dòng)畫的處理上面兩個(gè)版本針對(duì)的是“元素還在場(chǎng)只是位置或尺寸變了”。還有一種常見情況是元素被新增或刪除這時(shí)的處理思路稍有不同新增元素Flirst 狀態(tài)不存在元素是突然出現(xiàn)的?？梢栽谠夭迦牒笙劝阉O(shè)為透明度 0然后配合opacity過(guò)渡讓元素從無(wú)到有地顯現(xiàn)。如果一定要做位移效果可以給一個(gè)初始偏移量比如從下方translateY(20px)滑入。這個(gè)偏移量不是基于 First 位置而是你自定義的入場(chǎng)效果。刪除元素最麻煩的地方在于DOM 元素一旦移除getBoundingClientRect()就取不到值了。常規(guī)做法是先替它占位或者用絕對(duì)定位把它拖出文檔流保持它仍然可見記錄 Last也就是它本來(lái)的位置之后再給它做“離場(chǎng)”動(dòng)畫創(chuàng)建一個(gè)副本放到原位置播放 translate 或 opacity 動(dòng)畫結(jié)束后再真正移除。這里有一個(gè)實(shí)用的占位技巧在列表項(xiàng)刪除之前先給它的父容器設(shè)一個(gè)和原元素一樣高度寬度的占位塊等動(dòng)畫結(jié)束再移除占位塊。好處是其他元素的布局不會(huì)發(fā)生突然的“跳動(dòng)”視覺上會(huì)更連貫。4. 實(shí)戰(zhàn)場(chǎng)景——讓布局變化真正“絲滑”起來(lái)4.1 展開折疊卡片展開折疊大概是 FLIP 最經(jīng)典的用處之一。我做一個(gè)accordion組件時(shí)最初嘗試給height設(shè)置transition結(jié)果是展開速度一快就明顯掉幀因?yàn)?height 變化會(huì)連鎖影響整個(gè)文檔流的排布。后來(lái)改用 FLIP思路變成了這樣展開前記錄卡片的當(dāng)前位置和尺寸。動(dòng)態(tài)修改卡片內(nèi)容區(qū)的高度比如從 0 改成 500px此時(shí)布局發(fā)生了變化。用 FLIP 把尺寸變化做成 scaleY 的動(dòng)畫讓卡片感覺是“撐開”的而不是生硬地跳變。不過(guò)這里有一個(gè)特別容易踩的坑scaleY 動(dòng)畫會(huì)讓內(nèi)部文字在動(dòng)畫過(guò)程中被拉伸變形。如果你只是純色背景或者圖片內(nèi)容拉伸問(wèn)題不明顯但一有文字就會(huì)顯得劣質(zhì)。我的替代方案是對(duì)卡片的“外框”使用 transform 動(dòng)畫內(nèi)容區(qū)則用clip-path或overflow: hidden配合固定的內(nèi)部布局這樣外部看起來(lái)尺寸在變內(nèi)部文字不受拉伸影響。還有一種方案是只對(duì)高度做過(guò)渡但配合will-change提示瀏覽器優(yōu)化只是這種方式在復(fù)雜頁(yè)面上仍然不如 FLIP 穩(wěn)。4.2 網(wǎng)格重排與響應(yīng)式變化響應(yīng)式布局下當(dāng)窗口從寬屏縮窄到手機(jī)尺寸時(shí)網(wǎng)格列數(shù)通常會(huì)從 4 列變成 2 列卡片的位置會(huì)發(fā)生整體性的移動(dòng)。這種情況用 FLIP 再合適不過(guò)。我第一次在 Dashboard 頁(yè)面里試這個(gè)時(shí)發(fā)現(xiàn)一個(gè)有意思的問(wèn)題窗口尺寸連續(xù)變化時(shí)每觸發(fā)一次斷點(diǎn)就會(huì)執(zhí)行一次 FLIP 動(dòng)畫結(jié)果導(dǎo)致卡片在縮放窗口的過(guò)程中不斷“滑來(lái)滑去”體驗(yàn)反而更差。解決方法是只在斷點(diǎn)切換完成之后做動(dòng)畫或者在窗口調(diào)整結(jié)束后統(tǒng)一執(zhí)行一次 FLIP這可以通過(guò)防抖debounce來(lái)實(shí)現(xiàn)。歸根結(jié)底FLIP 適合的是“確定性的布局變化”而不是用戶持續(xù)拖拽造成的連續(xù)重排。4.3 拖拽排序拖拽排序是 FLIP 的另一個(gè)大顯身手的地方。當(dāng)卡片被拖到新的位置時(shí)其他卡片會(huì)騰出空位它們的位置發(fā)生了瞬間變化如果直接跳變會(huì)顯得非常生硬。做法是在拖拽過(guò)程中每當(dāng)目標(biāo)位置變化時(shí)把所有受影響的卡片執(zhí)行一次 FLIP讓它們以動(dòng)畫方式“滑”到新位置。這里還要兼顧被拖拽元素本身它通常被設(shè)為position: fixed或絕對(duì)定位脫離文檔流直接跟隨鼠標(biāo)釋放時(shí)再把它的位置映射回文檔流并同時(shí)觸發(fā)其他元素的 FLIP。整個(gè)過(guò)程配合得好的話效果很接近原生 App 的手感完全不像網(wǎng)頁(yè)。4.4 列表排序的按鈕操作一個(gè)更簡(jiǎn)單的場(chǎng)景列表里有兩個(gè)按鈕點(diǎn)擊“上移”“下移”讓某個(gè)條目換位置。這種場(chǎng)景用 FLIP 的收益非常明顯——排序算法改好 DOM 后只需要做一次flipAll就能讓所有移動(dòng)的條目同時(shí)滑到位代碼量少且效果整齊。我第一次實(shí)踐這個(gè)場(chǎng)景的時(shí)候發(fā)現(xiàn)之前手動(dòng)算top/left的過(guò)渡動(dòng)畫不但代碼冗長(zhǎng)還會(huì)因?yàn)槭录蛣?dòng)畫幀不同步出現(xiàn)抖動(dòng)。FLIP 用 transform 統(tǒng)一解決之后這類問(wèn)題幾乎絕跡。5. 細(xì)節(jié)、性能與兼容性——那些會(huì)影響成敗的關(guān)鍵點(diǎn)5.1 用 ResizeObserver 替代手動(dòng)測(cè)量如果布局變化的觸發(fā)源不只是你自己的代碼比如用戶改變了瀏覽器窗口寬度、字體縮放或者其他不確定因素那么手動(dòng)記錄 First/Last 的時(shí)機(jī)就不太靠譜。這時(shí)候可以用ResizeObserver監(jiān)聽容器尺寸尺寸一變就自動(dòng)重新做 FLIP。ResizeObserver 的兼容性在現(xiàn)代瀏覽器里已經(jīng)很好了是比純靠事件監(jiān)聽更穩(wěn)的方案。5.2 別讓 transform 和其他效果打架如果你在元素上原本就有持續(xù)的 transform 動(dòng)畫比如一個(gè)循環(huán)的浮動(dòng)效果那么在 Invert 階段給元素設(shè)置 transform 會(huì)把它原來(lái)的 transform 覆蓋掉。處理方式是先把原來(lái)的 transform 存起來(lái)在 Play 階段結(jié)束后恢復(fù)或者在動(dòng)畫過(guò)程中把原來(lái)的 transform 合并進(jìn)偏移量。聽起來(lái)簡(jiǎn)單實(shí)際操作時(shí)很容易漏尤其在團(tuán)隊(duì)協(xié)作的代碼里其他成員不一定知道你這里有 FLIP。提示FLIP 動(dòng)畫執(zhí)行期間盡量不要給同一元素同時(shí)疊加多個(gè)動(dòng)畫控制源。WAAPI 的element.animate()不會(huì)自動(dòng)和其他動(dòng)畫協(xié)調(diào)多次調(diào)用可能會(huì)導(dǎo)致后加的動(dòng)畫無(wú)視之前的。5.3 降低測(cè)量損耗雖然 FLIP 把動(dòng)畫階段的性能問(wèn)題解決了但 First/Last 的記錄始終需要讀取布局。單次getBoundingClientRect()并不貴但如果你有一千個(gè)元素要記錄累積的布局讀取就會(huì)造成卡頓。這里有兩個(gè)辦法只測(cè)量可見區(qū)域的元素配合IntersectionObserver做懶處理。不必每個(gè)元素單獨(dú)測(cè)量如果它們共享同一套變化規(guī)則可以做“代理測(cè)量”只測(cè)量一個(gè)參照元素其余元素用相對(duì)偏移推算。在實(shí)際項(xiàng)目中第一種做法已經(jīng)能解決大部分問(wèn)題。特別是長(zhǎng)列表第一屏之外的元素并不需要?jiǎng)赢嬎鼈冎苯拥却季址€(wěn)定就行了。5.4 子像素和縮放導(dǎo)致的邊緣縫隙寬度的比例在計(jì)算時(shí)經(jīng)常會(huì)出現(xiàn)小數(shù)點(diǎn)比如 0.33333px 這種。如果兩個(gè)元素并排縮放動(dòng)畫過(guò)程中可能產(chǎn)生一條細(xì)細(xì)的縫隙看起來(lái)像“漏油”。解決辦法是盡量用整數(shù)像素存儲(chǔ) First/Last或者在縮放結(jié)束后對(duì)元素做一次will-change: transform的強(qiáng)制合成處理把邊緣柔化掉。親密接觸的兩個(gè)元素還可以在動(dòng)畫期間給它們加一個(gè)同色背景或border-radius掩蓋縫隙。5.5 兼容性與降級(jí)策略FLIP 本身的 API 都是基于老的 DOM 和 CSS 能力getBoundingClientRect、requestAnimationFrame、transform、transition這些在現(xiàn)代瀏覽器里沒有任何門檻。真正要留意的是 WAAPI 的element.animate()在舊版 Safari 里的支持情況。如果需要兼容很老的瀏覽器可以先檢測(cè)element.animate是否存在不存在時(shí)退化為直接設(shè)置樣式不播放動(dòng)畫或者用 CSS transition 作為替代。這種降級(jí)策略成本很低但能給用戶兜底體驗(yàn)值得在封裝工具時(shí)就內(nèi)置進(jìn)去。6. 常見問(wèn)題與排查經(jīng)驗(yàn)——我在項(xiàng)目里踩過(guò)的坑6.1 動(dòng)畫一幀閃爍像是先跳到了終點(diǎn)這個(gè)現(xiàn)象通常發(fā)生在 Play 階段之前元素被一眼看到處于“終點(diǎn)位置”。排查順序如下先確認(rèn) First 和 Last 的測(cè)量時(shí)機(jī)是否處于同一幀尤其注意布局變化是不是由異步任務(wù)觸發(fā)的再看 Invert 階段有沒有真的給元素設(shè)置 transform。如果你用的是 CSS transition 方案記得在切換 class 的時(shí)候舊 class 里的transition屬性要先清掉否則瀏覽器可能在改樣式時(shí)直接播放了一個(gè)未預(yù)期的過(guò)渡。6.2 動(dòng)畫結(jié)束后元素輕微抖動(dòng)或位置偏移這是最容易讓人抓狂的問(wèn)題。我遇到過(guò)的情況是我在 Play 階段的transform里用了百分比或calc()導(dǎo)致瀏覽器計(jì)算出非整數(shù)的像素值縮放過(guò)程中產(chǎn)生了舍入誤差。解決方法是把動(dòng)畫的最終幀明確寫成transform: none并且在動(dòng)畫結(jié)束事件里清理內(nèi)聯(lián)樣式。另一個(gè)常見原因是元素內(nèi)部有異步加載的內(nèi)容比如圖片F(xiàn)irst 記錄時(shí)圖片還沒加載完布局尺寸不準(zhǔn)等圖片加載完元素位置已經(jīng)變了。處理這個(gè)問(wèn)題可以在圖片加載完成后再用 ResizeObserver 觸發(fā)一次 FLIP 校準(zhǔn)。6.3 卡頓問(wèn)題排查清單如果已經(jīng)用了 FLIP 卻還是卡可以從這幾個(gè)方向排查是否有父容器的overflow: hidden且父容器有border-radius導(dǎo)致合成層被反復(fù)光柵化。元素是否在動(dòng)畫期間改變了display或position這會(huì)打斷合成器的優(yōu)化。是否觸發(fā)了大量元素的同步布局讀取也就是多處調(diào)用getBoundingClientRect()而沒有批量處理。動(dòng)畫期間是否有頻繁的文字重排比如寬度變化導(dǎo)致每一行的折行點(diǎn)全部變化這種文字重排很難靠 FLIP 完全避免只能配合固定寬度或者white-space: nowrap做約束。6.4 表格形式的速查對(duì)照為了實(shí)用我把關(guān)鍵問(wèn)題的現(xiàn)象、原因和常用解法整理成一張表方便你放到項(xiàng)目文檔里?，F(xiàn)象常見原因處理方式動(dòng)畫前閃爍到終點(diǎn)First/Last 測(cè)量時(shí)機(jī)不對(duì)用 rAF 分隔布局修改和測(cè)量動(dòng)畫結(jié)束位置偏移最終幀不是transform: none動(dòng)畫結(jié)束時(shí)清理內(nèi)聯(lián)樣式文字被拉伸變形直接 scaleY 外層容器改用 clip-path 或固定內(nèi)部布局元素之間有縫隙縮放比例非整數(shù)像素動(dòng)畫期間加同色背景遮罩滾輪連續(xù)觸發(fā)重排動(dòng)畫未做防抖斷點(diǎn)或滾動(dòng)結(jié)束后再執(zhí)行 FLIPfont 加載后布局跳變First 記錄時(shí)字體未載入用 ResizeObserver 二次校準(zhǔn)6.5 我打磨出來(lái)的一個(gè)封裝習(xí)慣最后說(shuō)一個(gè)我自己的習(xí)慣會(huì)把 FLIP 抽成一個(gè)獨(dú)立的工具函數(shù)所有需要使用的地方只傳入“布局變化前的回調(diào)”和“需要?jiǎng)赢嫷脑丶稀眱?nèi)部統(tǒng)一處理測(cè)量、rAF、WAAPI 調(diào)用和降級(jí)策略。這樣業(yè)務(wù)代碼里幾乎看不到 FLIP 的邏輯全部語(yǔ)義化到“讓這些元素平滑過(guò)渡到新位置”。實(shí)際運(yùn)行時(shí)我能很方便地加統(tǒng)一的調(diào)試日志看看每次動(dòng)畫的成本。這個(gè)習(xí)慣在我們項(xiàng)目里被其他人接手時(shí)也獲得了不錯(cuò)的反饋因?yàn)榇蠹也恍枰斫?FLIP 的實(shí)現(xiàn)也能正確使用。FLIP 不是動(dòng)畫銀彈它解決的是“布局驅(qū)動(dòng)動(dòng)畫”這一特定問(wèn)題但對(duì)于縱深方向的卡片切換、復(fù)雜拖拽排序這類場(chǎng)景它確實(shí)把性能問(wèn)題解決得既優(yōu)雅又通用。遇到突發(fā)布局變化時(shí)先想想能不能用 FLIP 把變化“藏”進(jìn)合成層的過(guò)渡里往往比糾結(jié)怎么優(yōu)化重排成本要高效得多。