FLIP 動(dòng)畫這幾年幾乎成了前端動(dòng)畫繞不開的話題核心名字卻簡單得有些反直覺First、Last、Invert、Play。它解決的問題特別直白——讓一個(gè)改變尺寸、位置的 DOM 元素動(dòng)畫跑起來又順又不卡。但光看效果不過癮真要在項(xiàng)目里落地得從瀏覽器渲染原理講到工程級實(shí)踐把每一步的為什么弄清楚調(diào)試時(shí)才不會(huì)懵。這篇文章適合正在做交互原型、維護(hù)動(dòng)畫庫或者被重排卡頓折磨過的前端開發(fā)者也適合想弄懂高性能動(dòng)畫原理的同學(xué)。1. 為什么動(dòng)畫會(huì)卡頓先補(bǔ)瀏覽器渲染原理1.1 瀏覽器渲染管線里的昂貴工作瀏覽器把一個(gè) DOM 元素顯示到屏幕上中間要經(jīng)過好幾道工序。首先要拿到 HTML 解析出來的 DOM 樹然后把 CSS 選擇器匹配到的樣式逐條生效得到每個(gè)元素的最終樣式接著進(jìn)入布局階段瀏覽器會(huì)計(jì)算元素在頁面上的確切尺寸和位置再往后是繪制階段把邊框、背景、文字這些視覺內(nèi)容畫出來最后交給合成階段把已經(jīng)畫好的各個(gè)圖層按層級疊加輸出到屏幕上。這段管線聽起來挺常規(guī)但它對動(dòng)畫的代價(jià)完全不同。如果動(dòng)畫期間改變了元素的 width、height、top、left 這類幾何屬性瀏覽器每一幀都可能需要重新跑一遍布局和繪制。比如一個(gè)盒子的寬度從 100px 變成 300px布局階段要重新計(jì)算它周圍的元素怎么排繪制階段要重新生成這塊區(qū)域的像素連續(xù) 30 幀都這么做主線程很快就滿了。這里可以把整個(gè)流程類比成裝修房子。布局就像先丈量客廳尺寸、決定沙發(fā)放哪繪制就像調(diào)好漆、往墻上刷顏色。你買來新的沙發(fā)改了一下朝向整間屋子都要重新量一遍、重新刷一遍代價(jià)當(dāng)然大。而我們在動(dòng)畫里真正想優(yōu)化的就是盡量別讓瀏覽器頻繁做這種“量屋子、刷墻”的重活。1.2 合成器屬性是瀏覽器特意開的后門好在瀏覽器并不是只會(huì)蠻干它對個(gè)別屬性留了專門的優(yōu)化路徑。transform 和 opacity 屬于“合成器屬性”意思是元素位置和透明度的變化可以在獨(dú)立的合成層上處理不需要主線程重新計(jì)算布局和繪制只要把圖層交給 GPU 做位移、縮放和透明疊加就行。這就像你已經(jīng)把完整房間的照片打印在了一張透明膜上現(xiàn)在只需要把這層膜從桌子的左邊平移到右邊而不是重新打開施工圖、重新鋪一遍墻紙。GPU 擅長這類矩陣運(yùn)算一個(gè) translate 或 scale 的動(dòng)畫在它那里就是幾個(gè)矩陣相乘成本低得多主線程也騰得出來處理點(diǎn)擊、滾動(dòng)和業(yè)務(wù)代碼。這個(gè)思路也是 FLIP 動(dòng)畫的底層依據(jù)如果你能把元素的位置和尺寸變化偽裝成 transform 變化那么動(dòng)畫就能避開昂貴的布局和繪制。注意這里說的是“偽裝”因?yàn)?transform 不會(huì)真正改變文檔流里的布局位置和尺寸它只是在視覺上做了一個(gè)偏移和縮放。這個(gè)特性在 FLIP 里會(huì)被反復(fù)利用也是理解代碼邏輯的關(guān)鍵。1.3 不同動(dòng)畫方式的代價(jià)對比把常見做法放在一起看就清楚得多我給它們按觸發(fā)階段做了個(gè)對比動(dòng)畫方式是否觸發(fā)布局是否觸發(fā)繪制主線程開銷適合動(dòng)畫嗎改 width / height是是高連續(xù)幀容易卡不推薦改 top / left是是高依賴布局重排有條件的極小場景可用改 transform否否低合成層處理推薦改 opacity否否低合成層處理推薦改 clip-path視情況視情況中到高謹(jǐn)慎所以高性能動(dòng)畫的結(jié)論很樸素能用 transform 解決的就不要直接去動(dòng)布局屬性。但問題來了很多交互本質(zhì)上就是“尺寸發(fā)生變化”比如展開的卡片、伸縮的側(cè)邊欄這時(shí)候單純用 transform 沒法直接把布局尺寸變成動(dòng)畫。FLIP 的作用就是橋接這兩者——它先用真實(shí)布局把尺寸變成最終目標(biāo)再用 transform 把元素“拉回”起點(diǎn)最后補(bǔ)一段順滑的位移。2. FLIP 原理拆解First、Last、Invert、Play2.1 First 和 Last兩次狀態(tài)測量FLIP 的第一步是在元素改變之前記錄它的狀態(tài)第二步是改變之后記錄狀態(tài)。通常是調(diào)用 getBoundingClientRect() 拿到元素的 left、top、width、height因?yàn)檫@些值正好覆蓋了位置和尺寸兩個(gè)關(guān)鍵維度。這里有個(gè)細(xì)節(jié)可以多說一句getBoundingClientRect 返回的是相對視口的位置而不是相對文檔的位置。如果你頁面里用了滾動(dòng)不同時(shí)刻測量出的 top 可能受滾動(dòng)高度影響但 FLIP 關(guān)心的是兩次測量之間的差值只要兩幀處于相同滾動(dòng)位置差值就能抵消這個(gè)問題。當(dāng)然如果在動(dòng)畫過程中滾動(dòng)位置變了最后的位移會(huì)出現(xiàn)偏差這點(diǎn)我會(huì)在后面的排查章節(jié)專門講。First 的測量必須發(fā)生在任何 DOM 變化之前Last 的測量必須發(fā)生在 DOM 已經(jīng)變化之后。聽起來很簡單但瀏覽器有個(gè)特性容易坑人——布局是異步的。你改了樣式之后瀏覽器不會(huì)立刻重新布局而是要等一個(gè)合適的時(shí)機(jī)。如果這時(shí)候你立刻再讀一次布局屬性瀏覽器會(huì)被迫中斷當(dāng)前任務(wù)先把排隊(duì)的布局工作全部執(zhí)行掉這就是所謂的“強(qiáng)制同步布局”。所以在寫 FLIP 時(shí)最容易犯的錯(cuò)誤是在回調(diào)函數(shù)之后馬上測量 Last結(jié)果測得的是舊狀態(tài)或者測得的新狀態(tài)內(nèi)部自相矛盾。穩(wěn)妥的做法是在回調(diào)后強(qiáng)制讀取一次布局屬性讓瀏覽器先完成布局再拿到準(zhǔn)確的新坐標(biāo)。這個(gè)同步布局確實(shí)有開銷但 FLIP 只在狀態(tài)切換的那一幀做一次集中測量而不是在動(dòng)畫幀里持續(xù)做所以總體可以接受。2.2 Invert把終點(diǎn)偽裝成起點(diǎn)拿到了 firstRect 和 lastRect 之后立即算出兩者之間的差值。我們希望元素視覺上還停在原來的位置但實(shí)際的布局位置已經(jīng)到了終點(diǎn)。差值是deltaX firstRect.left - lastRect.leftdeltaY firstRect.top - lastRect.topscaleX firstRect.width / lastRect.widthscaleY firstRect.height / lastRect.height可以看出位移量是“起點(diǎn)減終點(diǎn)”縮放比是“起點(diǎn)寬度除以終點(diǎn)寬度”。把這個(gè)差值放到 transform 上元素就被“拽回”了起點(diǎn)。這里我強(qiáng)烈建議設(shè)置 transform-origin 為 top left因?yàn)檫@樣縮放的原點(diǎn)就在左上角translate 的計(jì)算和 scale 的計(jì)算可以各自獨(dú)立不容易算錯(cuò)。如果保留默認(rèn)的中心點(diǎn)縮放最后的坐標(biāo)還要把中心偏移算進(jìn)去手寫容易翻車。另一個(gè)容易踩坑的是 transform 的順序。CSS 的 transform 相當(dāng)于多個(gè)矩陣依次作用從左到右會(huì)把前一個(gè)變換繼續(xù)應(yīng)用到后一個(gè)變換的結(jié)果上。直觀理解就是先寫 translate 再寫 scale 時(shí)translate 的像素值不會(huì)被 scale 放大先寫 scale 再寫 translate 的話translate 的像素值也會(huì)被縮放計(jì)算位移時(shí)就得再除以縮放比例。為了省心和準(zhǔn)確推薦寫成 translate(...px, ...px) scale(...)并且配合 top left 的原點(diǎn)。2.3 Play用合成器屬性把反向變回來Invert 完成之后元素雖然視覺上還在起點(diǎn)但 transform 記錄的是一個(gè)反向偏移。接下來要做的就是把反向 transform 清掉讓元素從起點(diǎn)位置回到真實(shí)終點(diǎn)位置。因?yàn)?transform 是合成器屬性這個(gè)過渡過程只會(huì)觸發(fā)合成層操作動(dòng)畫幀率就會(huì)非常穩(wěn)定。具體執(zhí)行時(shí)可以把 transition 設(shè)置為 transform 0.3s ease然后把 transform 的值清成空字符串。瀏覽器檢測到 transform 從反向值變?yōu)槌跏贾稻蜁?huì)在這兩個(gè)值之間插入過渡動(dòng)畫。整段時(shí)間里沒有布局重排也沒有繪制重刷主線程幾乎無事可做60fps 不是問題。有一個(gè)非常重要的收尾動(dòng)作動(dòng)畫結(jié)束后要把 transform 真正清空不能一直留著 translate 或 scale。transform 只是視覺上的欺騙文檔流里元素的真實(shí)位置和大小已經(jīng)變成 lastRect 了。如果不清空后續(xù)再測量這個(gè)元素getBoundingClientRect 會(huì)把 transform 也算進(jìn)去下一輪 FLIP 的差值就會(huì)算錯(cuò)。更嚴(yán)重的是transform 默認(rèn)會(huì)創(chuàng)建層疊上下文和包含塊可能影響 fixed 定位子元素和 z-index 層級。2.4 FLIP 適合什么場景不適合什么場景把四個(gè)步驟串起來看FLIP 特別適合那些“起點(diǎn)和終點(diǎn)狀態(tài)都可以明確測量”的場景列表增刪后自動(dòng)排序、折疊面板展開收縮、拖拽排序后的歸位、路由切換時(shí)的頁面轉(zhuǎn)場。這些場景的共同點(diǎn)是元素真實(shí)地移動(dòng)了位置或改變了尺寸但動(dòng)畫效果卻要表現(xiàn)得像是一小段 transform 過渡。反過來如果動(dòng)畫本身已經(jīng)是用 transform 來寫比如一個(gè)按鈕的縮放 hover 效果那就不需要 FLIP直接用 CSS transition 更合適。FLIP 的最大價(jià)值是連接“真實(shí)布局變化”和“合成器動(dòng)畫”這兩個(gè)原本不相干的世界是一種橋接手法而不是萬能動(dòng)畫方案。它也不適合做路徑復(fù)雜、需要逐幀控制的動(dòng)畫那種需求更適合用 Web Animations API 或者逐幀 rAF 來做插值。3. 手寫 FLIP從一個(gè)最小實(shí)現(xiàn)到工程化封裝3.1 一個(gè)能跑的最小實(shí)現(xiàn)先寫一個(gè)足夠簡單、能看清邏輯的版本。它接收一個(gè) run 函數(shù)調(diào)用之前測量所有標(biāo)記元素調(diào)用之后測量第二次然后計(jì)算差值并應(yīng)用反向 transform最后觸發(fā) transition。function flip(run, options {}) { const duration options.duration ?? 300; const easing options.easing ?? ease; const firstMap new Map(); document.querySelectorAll([data-flip]).forEach((el) { firstMap.set(el, el.getBoundingClientRect()); }); run(); const lastMap new Map(); document.querySelectorAll([data-flip]).forEach((el) { lastMap.set(el, el.getBoundingClientRect()); }); firstMap.forEach((firstRect, el) { const lastRect lastMap.get(el); if (!lastRect) return; const deltaX firstRect.left - lastRect.left; const deltaY firstRect.top - lastRect.top; const scaleX firstRect.width / lastRect.width; const scaleY firstRect.height / lastRect.height; el.style.transition none; el.style.transformOrigin top left; el.style.transform translate(${deltaX}px, ${deltaY}px) scale(${scaleX}, ${scaleY}); }); // 強(qiáng)制瀏覽器完成一次布局確保 transform 生效 document.body.offsetHeight; firstMap.forEach((firstRect, el) { el.style.transition transform ${duration}ms ${easing}; el.style.transform ; }); }這段代碼有幾個(gè)地方值得琢磨。Map 的 key 直接存元素避免用數(shù)組索引跟蹤順序變化時(shí)不會(huì)串位。第一次測量之后立刻調(diào)用 run第二次測量放到循環(huán)前面集中讀取而不是每個(gè)元素單獨(dú)又讀又寫這樣可以減少強(qiáng)制同步布局的次數(shù)。中間那個(gè) document.body.offsetHeight 是為了強(qiáng)制刷新布局雖然名字看著像是在讀一個(gè)無關(guān)屬性但瀏覽器為了返回這個(gè)值會(huì)先把排隊(duì)的布局任務(wù)做完。3.2 經(jīng)典場景實(shí)戰(zhàn)列表展開收縮FLIP 最常被提及的場景之一就是列表的展開收縮。假設(shè)有一個(gè)可折疊的分組點(diǎn)擊時(shí)高度從 0 變成 auto或者從一個(gè)固定高度變成內(nèi)容高度。直接用 height 加 transition 來做瀏覽器會(huì)在動(dòng)畫每一幀里重排并重繪數(shù)據(jù)一多就卡。用 FLIP 的思路就不一樣先把高度設(shè)置為最終值讓瀏覽器完成布局再用 transform 把視覺狀態(tài)倒推到展開前然后再補(bǔ)回原位。實(shí)際代碼只需要在前面的 flip 函數(shù)基礎(chǔ)上改 run 的內(nèi)容。比如一個(gè)模擬目錄結(jié)構(gòu)div classgroup button classtoggle展開分組/button ul classlist li第一項(xiàng)/li li第二項(xiàng)/li /ul /div點(diǎn)擊按鈕時(shí)把 list 的 display 從 none 改成 block或者把 max-height 從 0 改成實(shí)際內(nèi)容的高度。接著調(diào)用 flip 函數(shù)run 里只做這個(gè) DOM 狀態(tài)切換然后在 flip 內(nèi)部自動(dòng)完成 start、end、invert、play。這里要注意display: none 的元素?zé)o法通過 getBoundingClientRect 拿到真實(shí)尺寸所以更穩(wěn)妥的做法是用 max-height 0 到 max-height 1000px或者先把元素放到可視區(qū)域外測量再回來做 FLIP。我自己在模擬項(xiàng)目 X 里實(shí)現(xiàn)“側(cè)欄抽屜展開”時(shí)就遇到過 display 從 none 變 block 的坑。改成下面這種方案后就順了把內(nèi)容放進(jìn)一個(gè)普通 div里面用固定高度包裹外層高度設(shè)為 0 并加 overflow: hidden展開時(shí)再設(shè)置外層高度為內(nèi)容的實(shí)際高度。這時(shí)測量 Last 就能拿到真實(shí)的寬高FLIP 的差值也自然正確。3.3 工程級封裝異步更新、rAF 與取消機(jī)制真正到了生產(chǎn)環(huán)境情況比上面的 demo 復(fù)雜得多。首先是數(shù)據(jù)驅(qū)動(dòng)的框架DOM 不是靠同步調(diào)用生成的而是數(shù)據(jù) update 之后由框架異步渲染。這時(shí)你在 run 之后立刻做 Last 測量拿到的很可能是舊 DOM。解決方案是在 run 之后用 nextTick 或者等一個(gè)微任務(wù)確?？蚣芤呀?jīng)更新完視圖再執(zhí)行測量。如果你發(fā)現(xiàn) transform 沒有生效第一個(gè)要懷疑的就是這里。其次是動(dòng)畫編排多個(gè)元素之間可能要設(shè)置 stagger也就是每個(gè)元素稍微延遲一點(diǎn)開始?？梢栽?flip 內(nèi)給每個(gè)元素計(jì)算一個(gè) delay比如 index * 50ms。注意 transition 里 delay 和 duration 是兩碼事不要混在一起。最后還要考慮的是 cancel 機(jī)制用戶快速連續(xù)點(diǎn)擊時(shí)上一個(gè)動(dòng)畫可能還沒有結(jié)束此時(shí)舊 transform 在過渡中新狀態(tài)又插進(jìn)來元素會(huì)跳一下。工程級封裝需要加一個(gè)動(dòng)畫令牌每次開始前校驗(yàn)令牌如果上一次動(dòng)畫未完成就先用 getAnimations() 取消元素上的動(dòng)畫把 transform 重置到當(dāng)前布局狀態(tài)再開始新一次 FLIP。下面是更進(jìn)一步封裝的核心思路我通常寫成工具類而不是普通函數(shù)class FlipController { constructor(root document) { this.root root; this.token 0; } async play(updateFn, options {}) { const token this.token; const elements [...this.root.querySelectorAll([data-flip])]; const firstMap elements.map((el) [el, el.getBoundingClientRect()]); await updateFn(); if (token ! this.token) return; const lastMap elements.map((el) [el, el.getBoundingClientRect()]); firstMap.forEach(([el, firstRect], i) { const lastRect lastMap[i]?.[1]; if (!lastRect) return; el.getAnimations().forEach((anim) anim.cancel()); el.style.transition none; el.style.transformOrigin top left; el.style.transform translate(${firstRect.left - lastRect.left}px, ${firstRect.top - lastRect.top}px) scale(${firstRect.width / lastRect.width}, ${firstRect.height / lastRect.height}); }); requestAnimationFrame(() { if (token ! this.token) return; firstMap.forEach(([el, firstRect], i) { const lastRect lastMap[i]?.[1]; if (!lastRect) return; el.style.transition transform ${options.duration ?? 300}ms ${options.easing ?? cubic-bezier(0.25, 0.8, 0.35, 1)}; el.style.transform ; }); }); } }這個(gè)封裝里把測量集中成數(shù)組保證 First 和 Last 一一對應(yīng)。await updateFn 的場景很靈活調(diào)用方可以傳入一個(gè) async 函數(shù)里面做框架更新、異步請求或者任意重排操作。token 的存在確保動(dòng)畫只響應(yīng)最新一次操作中斷的舊動(dòng)畫會(huì)被安全丟棄。requestAnimationFrame 確保 transition 是在當(dāng)前幀已經(jīng)把 Invert 寫進(jìn)去之后才設(shè)置的不會(huì)出現(xiàn) transition 從舊狀態(tài)直接開始的尷尬情況。4. 常見問題與排查技巧實(shí)錄4.1 文字抖動(dòng)、模糊和拉伸我在實(shí)際項(xiàng)目里遇到最多的就是動(dòng)畫期間文字模糊、抖動(dòng)。原因多半是 scale 把文字柵格化了或者 transform 移動(dòng)到了小數(shù)像素位置。scale 動(dòng)畫過程中文字會(huì)在中間狀態(tài)被拉伸成非整數(shù)倍瀏覽器對位圖的插值結(jié)果看起來就有點(diǎn)糊。幾個(gè)可以試的辦法。一是給動(dòng)畫中的元素加 will-change: transform讓瀏覽器提前分配合成層降低動(dòng)態(tài)創(chuàng)建層的開銷二是把屬性盡量取整translate 的 x 和 y 可以用 Math.round 處理減少半像素渲染三是如果只做位移不需要縮放就盡量只保留 translate不要為了視覺效果強(qiáng)行加 scale四是如果文字必須跟尺寸一起過渡可以考慮外層元素做 FLIP 縮放內(nèi)層元素做一個(gè)反向縮放來抵消拉伸這樣文字在視覺上始終接近正常比例。4.2 子元素溢出、容器裁剪問題FLIP 變換以 scale 模擬尺寸變化時(shí)子元素經(jīng)常會(huì)被父容器裁掉尤其是父容器設(shè)置了 overflow: hidden 或圓角之后。原理是 scale 只是把整個(gè)盒子畫小了但內(nèi)容沒有真的重排超出新邊界的部分會(huì)被剪裁。動(dòng)畫結(jié)束后布局尺寸已經(jīng)變成最終值內(nèi)容反而正常了所以問題只在動(dòng)畫過渡到一半的時(shí)間段里集中爆發(fā)。如果只是視覺上有幾毫秒的頭暈感問題不大。但如果裁切非常明顯可以采用“雙層結(jié)構(gòu)”外層元素負(fù)責(zé)位置和尺寸的 FLIP內(nèi)層元素負(fù)責(zé)內(nèi)容渲染FLIP 過程中給內(nèi)層加一個(gè)反向 scale 來抵消外層的縮放。這個(gè)做法的計(jì)算量稍微復(fù)雜一點(diǎn)但視覺質(zhì)量很穩(wěn)定現(xiàn)在不少動(dòng)畫庫內(nèi)部的尺寸 FLIP 過渡用的都是類似思路。4.3 動(dòng)畫中斷、重復(fù)觸發(fā)錯(cuò)亂用戶連點(diǎn)按鈕時(shí)FLIP 最容易爆出位置跳躍。想象一下第一個(gè)動(dòng)畫才走了一半transform 還是某個(gè)中間值你這時(shí)候又把元素重置為 Invert 狀態(tài)原先的中間值和新的 Invert 值完全對不上瀏覽器就會(huì)硬生生把元素從舊位置拽到新位置視覺上就是一閃而過。解決思路是動(dòng)畫開始前把元素上未完成的動(dòng)畫全部取消或者先把 transform 清空再測量。Web Animations API 提供了 element.getAnimations() 和 anim.cancel()配合動(dòng)畫令牌可以在新動(dòng)畫開始時(shí)徹底清理舊狀態(tài)。如果團(tuán)隊(duì)里還在用老代碼也會(huì)用 transitionend 事件來標(biāo)記動(dòng)畫是否完成但那個(gè)方案在元素隱藏或快速重排時(shí)經(jīng)常漏觸發(fā)不如直接取消動(dòng)畫可靠。4.4 窗口尺寸變化、字體加載后測量不準(zhǔn)FLIP 的 Last 測量依賴一個(gè)穩(wěn)定的環(huán)境但瀏覽器窗口尺寸變化、字體加載、圖片加載都會(huì)改變布局。假設(shè)用戶正在看一個(gè)展開動(dòng)畫突然滾動(dòng)條出現(xiàn)或消失視口寬度變化布局重新計(jì)算之前測好的 lastRect 可能就不對了動(dòng)畫終點(diǎn)會(huì)偏離真實(shí)位置甚至出現(xiàn)閃爍。應(yīng)對方式有兩類。一類是讓 FLIP 在布局穩(wěn)定之后重新測量比如監(jiān)聽 resize 事件用防抖再執(zhí)行一次或者在 document.fonts.ready 之后再做動(dòng)畫另一類是盡量讓觸發(fā)動(dòng)畫的元素處于自約束狀態(tài)寬高不依賴外部視口。開發(fā)中如果發(fā)現(xiàn)“換了個(gè)窗口寬度動(dòng)畫就歪了”多半就是測量時(shí)機(jī)沒控制好。實(shí)測下來ResizeObserver 比 window.resize 更精確因?yàn)樗梢枣i定到具體容器變化而不是全局視口變化。做一個(gè)簡單的問題速查表方便大家直接查現(xiàn)象可能原因處理建議文字抖動(dòng)小數(shù)像素、scale 插值對齊到整數(shù)、加 will-change、反向縮放內(nèi)容被裁剪overflow hidden 與 scale 沖突雙層結(jié)構(gòu)、動(dòng)畫期間放寬 overflow重復(fù)點(diǎn)擊跳動(dòng)前一次動(dòng)畫未清理取消舊動(dòng)畫、動(dòng)畫令牌終點(diǎn)不對Last 測量時(shí)機(jī)太早使用 nextTick / rAF 后測量窗口變化后錯(cuò)位視口重排影響坐標(biāo)resize 后重新測量、監(jiān)聽容器變化5. 工程級落地選型、度量與團(tuán)隊(duì)協(xié)作5.1 自己寫還是用現(xiàn)成動(dòng)畫庫FLIP 看起來代碼不多但工程級落地時(shí)會(huì)牽扯到測量時(shí)機(jī)、動(dòng)畫調(diào)度、子元素變形、斷點(diǎn)恢復(fù)等問題。是維護(hù)一套自己寫的工具庫還是直接用一個(gè)成熟的動(dòng)畫庫我認(rèn)為取決于團(tuán)隊(duì)對性能控制和定制深度的需求。自己寫的好處是邏輯完全可控沒有額外依賴代碼量也不少但坑得自己踩一遍動(dòng)畫庫那些已經(jīng)打磨好的細(xì)節(jié)比如連續(xù)動(dòng)畫調(diào)度、滾動(dòng)牽連、子元素反向補(bǔ)償你得重新實(shí)現(xiàn)。成熟的動(dòng)畫庫把大部分常見場景封裝好了你可以用很短的聲明式代碼完成列表排序和布局過渡但代價(jià)是體積、學(xué)習(xí)成本和潛在的內(nèi)部黑盒。如果只是偶爾用一兩次直接封裝一個(gè)工具函數(shù)或者引入成熟庫都行如果整個(gè)項(xiàng)目里到處都需要列表布局動(dòng)畫我會(huì)先把團(tuán)隊(duì)里一段公共的 FlipController 維護(hù)好穩(wěn)定之后再考慮是否替換為更完整的能力。5.2 性能度量與回歸觀測把 FLIP 寫進(jìn)項(xiàng)目之后不要只靠肉眼確認(rèn)“看起來挺順”要用數(shù)據(jù)量化主線程上的壓力。打開瀏覽器的 Performance 面板錄制一段動(dòng)畫過程觀察 Main 任務(wù)的火焰圖里有沒有大塊的 Layout 和 Paint 任務(wù)。如果動(dòng)畫期間經(jīng)常出現(xiàn)長任務(wù)超過 50ms說明還有東西在拖后腿需要回去檢查 Last 測量是否集中、transition 是否寫到了 transform 上、有沒有別的屬性被意外帶動(dòng)重排。我習(xí)慣在動(dòng)畫工具里打兩個(gè)日志一個(gè)記錄強(qiáng)制同步布局的時(shí)間一個(gè)記錄 requestAnimationFrame 和前一個(gè) rAF 的時(shí)間差。如果 rAF 的間隔經(jīng)常超過 16ms說明主線程確實(shí)忙不過來這時(shí)不一定是 FLIP 本身的問題而是頁面上有太多動(dòng)畫或者業(yè)務(wù)代碼在跟渲染搶時(shí)間片。把這些度量留在開發(fā)環(huán)境里發(fā)布前跑一輪能防止后續(xù)業(yè)務(wù)代碼改動(dòng)把動(dòng)畫性能悄悄拉垮。動(dòng)畫性能的退化通常不是突然發(fā)生的而是慢慢累積的所以回歸觀測比一次性的優(yōu)化更重要。5.3 團(tuán)隊(duì)協(xié)作時(shí)的幾個(gè)約定工程級 FLIP 落到團(tuán)隊(duì)里我會(huì)強(qiáng)制約定三件事。第一所有參與 FLIP 的元素必須有統(tǒng)一的>