簡介面向Web前端初學(xué)者與交互效果練習(xí)者的JavaScript圖片翻轉(zhuǎn)示例包圍繞點(diǎn)擊圖片沿X/Y軸翻轉(zhuǎn)并平滑恢復(fù)這一常見交互展開可用于理解DOM操作、事件監(jiān)聽與CSS變換的基礎(chǔ)配合。壓縮包共36個文件以26個gif和7個jpg圖片素材為主輔以2個html頁面和1個js腳本整體約413KB體量輕便適合直接解壓后對照頁面結(jié)構(gòu)與腳本邏輯學(xué)習(xí)。已有137人學(xué)習(xí)或?yàn)g覽可作為課堂演示、課后練習(xí)或前端小項(xiàng)目入門的參考。示例通過獲取圖片元素、綁定click事件在rotateX(180deg)與初始狀態(tài)間切換并借助transition讓翻轉(zhuǎn)過程更自然同時涉及翻轉(zhuǎn)狀態(tài)記錄避免連續(xù)點(diǎn)擊時邏輯混亂讀者可據(jù)此掌握樣式控制、狀態(tài)管理與簡單動畫的實(shí)現(xiàn)思路。1. 一張豎拍照片翻正后反而變糊JavaScript 圖片翻轉(zhuǎn)到底在翻什么前端做圖像處理JavaScript 圖片翻轉(zhuǎn)大概是出現(xiàn)頻率最高、也最容易被低估的需求用戶傳一張手機(jī)豎拍的照片預(yù)覽是躺倒的得轉(zhuǎn)正證件照工具要左右鏡像拼圖、貼紙、九宮格切圖要上下對調(diào)?？瓷先ブ皇莄tx.scale(-1, 1)一行的事真上手就會撞上畫布空白、邊緣發(fā)虛、透明底變黑、導(dǎo)出體積翻三倍這些事。這份資源把翻轉(zhuǎn)拆成兩層一層是 Canvas 繪制層面的坐標(biāo)變換一層是ImageData層面的像素搬運(yùn)。兩層各有各的邊界前者代碼少、能吃到 GPU 加速后者能在 Worker 里跑、不碰主線程。下面按我拆包時的順序走從坐標(biāo)系講起一路講到能自動跑的驗(yàn)收腳本。2. 坐標(biāo)系選型三種翻轉(zhuǎn)寫法與那個必踩的負(fù)縮放坑Canvas 的坐標(biāo)原點(diǎn)在左上角x 向右為正y 向下為正。所謂翻轉(zhuǎn)本質(zhì)是把對應(yīng)軸做一次取反讓繪制內(nèi)容落到負(fù)區(qū)間去。理解這一句后面所有為什么畫不出來的問題都能自己推出來。2.1 為什么 ctx.scale(-1, 1) 之后畫布是空的新手最常見的寫法是這個// 錯誤示范只做負(fù)縮放不補(bǔ)平移 const canvas document.createElement(canvas); canvas.width img.naturalWidth; canvas.height img.naturalHeight; const ctx canvas.getContext(2d); ctx.scale(-1, 1); // x 軸取反 ctx.drawImage(img, 0, 0); // 圖片被畫到 x ∈ [-w, 0] 區(qū)間畫布上什么都沒有scale(-1, 1)之后原本落在[0, w]的繪制內(nèi)容被映射到[-w, 0]整塊跑到畫布左邊界之外所以你看到的是一張空白圖。正確寫法要在縮放之前補(bǔ)一次平移// 水平翻轉(zhuǎn)左右鏡像 ctx.translate(canvas.width, 0); // 把原點(diǎn)挪到右上角 ctx.scale(-1, 1); // x 軸取反繪制區(qū)間重新回到 [0, w] ctx.drawImage(img, 0, 0); // 垂直翻轉(zhuǎn)上下對調(diào) // ctx.translate(0, canvas.height); // ctx.scale(1, -1); // 水平 垂直等價于旋轉(zhuǎn) 180 度 // ctx.translate(canvas.width, canvas.height); // ctx.scale(-1, -1);這里有個反直覺的點(diǎn)translate和scale的調(diào)用順序不能調(diào)換。Canvas 的變換矩陣是右乘累積的先translate(w, 0)再scale(-1, 1)得到的是T·S點(diǎn)p的最終位置是T·S·p也就是先縮放、再平移圖片先被翻到[-w, 0]再整體右移w正好落回畫布。如果先scale再translate平移量也跟著被取反了等于白翻。血淚經(jīng)驗(yàn)就一條平移量永遠(yuǎn)按目標(biāo)畫布尺寸給不要按源圖尺寸給兩者一旦不一致比如做了縮放適配翻轉(zhuǎn)方向就會錯得莫名其妙。2.2 三條實(shí)現(xiàn)路徑的成本對照同一個翻轉(zhuǎn)需求至少有三種落法選錯了不是能不能用的問題是性能和維護(hù)成本差一個量級的問題。路徑核心 API優(yōu)點(diǎn)代價適用場景CSS 變換transform: scaleX(-1)零代碼成本不占內(nèi)存只改顯示導(dǎo)出的文件仍是原圖純預(yù)覽、交互態(tài)鏡像Canvas 繪制ctx.translatectx.scaledrawImage能導(dǎo)出新圖瀏覽器內(nèi)部走 GPU 路徑需要處理尺寸、DPR、導(dǎo)出編碼上傳后要落盤、要下載的場景ImageData 搬運(yùn)getImageData 行/像素對調(diào)完全可控能塞進(jìn) Worker大圖內(nèi)存翻倍純 CPU批量處理、離屏計算、需要逐像素判斷的場景我一般的判斷標(biāo)準(zhǔn)是只要產(chǎn)物要交給后端或者觸發(fā)下載就走 Canvas 路徑只是頁面上看個鏡像效果CSS 夠了別為了一個scaleX(-1)去建一塊 canvas 再toDataURL白白多一次編碼。ImageData那條路只在兩種情況下值得動一是需要在翻轉(zhuǎn)的同時做像素級判斷比如摳圖后的邊緣處理二是圖很大、必須挪到 Worker 里避免主線程卡頓。順便說一個容易忽略的對比CSS 變換是顯示層鏡像Canvas 是數(shù)據(jù)層鏡像。曾有人用 CSS 做了鏡像預(yù)覽用戶點(diǎn)下載拿到的還是原圖反饋說翻轉(zhuǎn)沒生效。這不是 bug是選型錯了。2.3 參數(shù)怎么定尺寸、DPR 與平滑質(zhì)量Canvas 只有三個參數(shù)真正影響翻轉(zhuǎn)結(jié)果width、height和imageSmoothingQuality。width/height是畫布的像素緩沖區(qū)尺寸不是顯示尺寸。翻轉(zhuǎn)場景下它應(yīng)該等于源圖的naturalWidth/naturalHeight因?yàn)榉D(zhuǎn)不改變圖像大小任何額外的縮放都會引入一次重采樣圖就糊了。很多人為了讓預(yù)覽清晰把 canvas 的 CSS 寬高設(shè)成顯示尺寸、緩沖區(qū)設(shè)成顯示尺寸 * devicePixelRatio這在縮放預(yù)覽里是對的但在翻轉(zhuǎn)里是錯的——翻轉(zhuǎn)要的是 1:1 還原只在顯示時再用 CSS 縮下去// 翻轉(zhuǎn)場景的正確做法緩沖區(qū) 源圖尺寸顯示尺寸交給 CSS canvas.width img.naturalWidth; canvas.height img.naturalHeight; canvas.style.width 100%; // 顯示縮放與像素緩沖區(qū)解耦 canvas.style.maxWidth 480px;提示img.naturalWidth在有 EXIF 方向的照片上已經(jīng)是旋轉(zhuǎn)后的寬高直接用即可不要再拿img.width去乘什么系數(shù)。imageSmoothingQuality在翻轉(zhuǎn)本身用不上沒有縮放就沒有插值但如果你在同一條管線里順手做了縮略圖把它設(shè)成high會明顯好于默認(rèn)值。參數(shù)就三檔low | medium | high代價是耗時大圖批量處理時建議只對最終輸出設(shè) high中間草稿用 low。3. 從 File 到 Blob寫一個能直接用的 flipImage 模塊坐標(biāo)系搞清楚之后剩下的是一條完整的管線拿到File→ 解碼成可繪制的位圖 → 翻轉(zhuǎn) → 編碼成Blob交出去。這條鏈上每一步都有一個參數(shù)會咬人。3.1 解碼階段與 EXIF 方向的雙重旋轉(zhuǎn)問題手機(jī)拍的照片像素數(shù)據(jù)往往是橫著存的方向信息寫在 EXIF 里?，F(xiàn)代瀏覽器在渲染img時默認(rèn)就應(yīng)用了 EXIF 方向image-orientation: from-image是初始值所以img.naturalWidth已經(jīng)是轉(zhuǎn)正后的尺寸。問題出在解碼 API 上// 方案 A用 img 解碼瀏覽器已按 EXIF 方向渲染 async function loadViaImg(file) { const url URL.createObjectURL(file); const img new Image(); img.src url; await img.decode(); // decode() 比 onload 更可靠能拿到解碼失敗的原因 URL.revokeObjectURL(url); // 記得釋放否則 File 一直掛在內(nèi)存里 return img; // naturalWidth/Height 已經(jīng)是方向修正后的值 } // 方案 B用 createImageBitmap 解碼方向行為要顯式聲明 async function loadViaBitmap(file) { // imageOrientation: from-image 表示按 EXIF 應(yīng)用方向 // 若源圖已經(jīng)在 img 里被轉(zhuǎn)正過一次這里再加一次就是雙重旋轉(zhuǎn) return await createImageBitmap(file, { imageOrientation: from-image }); }這兩條路混用就會翻車先用img預(yù)覽已轉(zhuǎn)正再把原始File丟給createImageBitmap({imageOrientation:from-image})又轉(zhuǎn)一次結(jié)果照片被多轉(zhuǎn)了 90 度。我一般固定選一條路走到底——預(yù)覽和導(dǎo)出都用img或者都用createImageBitmap中間不換。createImageBitmap的好處是能直接喂給 Workerimg的好處是兼容性更穩(wěn)。3.2 flipImage 主函數(shù)與三種模式核心函數(shù)不長但每個分支都要照顧到翻轉(zhuǎn)后尺寸不變這個前提/** * param {ImageBitmap|HTMLImageElement} source 已解碼的圖像源 * param {horizontal|vertical|both} mode 翻轉(zhuǎn)模式 * returns {HTMLCanvasElement} */ function flipImage(source, mode horizontal) { const w source.width || source.naturalWidth; const h source.height || source.naturalHeight; const canvas document.createElement(canvas); canvas.width w; // 緩沖區(qū)尺寸等于源圖絕不縮放 canvas.height h; const ctx canvas.getContext(2d); // 按模式設(shè)置變換矩陣注意 translate 在前、scale 在后 if (mode horizontal) { ctx.translate(w, 0); ctx.scale(-1, 1); } else if (mode vertical) { ctx.translate(0, h); ctx.scale(1, -1); } else if (mode both) { ctx.translate(w, h); ctx.scale(-1, -1); // 兩次取反等價于旋轉(zhuǎn) 180 度 } ctx.drawImage(source, 0, 0, w, h); // 顯式傳目標(biāo)寬高避免 source 尺寸歧義 return canvas; }三個模式對應(yīng)的矩陣其實(shí)是一張表horizontal是x w - xvertical是y h - yboth是兩者疊加。drawImage里顯式寫(0, 0, w, h)而不是只傳(0, 0)是因?yàn)樵贗mageBitmap和HTMLImageElement混用時省略寬高會讓瀏覽器按源的自然尺寸去畫一旦源被縮放過就會錯位。如果要批量處理把這個函數(shù)里的document.createElement(canvas)換成復(fù)用的 canvas 實(shí)例同一個尺寸反復(fù)用能省掉大量 GC 壓力。3.3 導(dǎo)出參數(shù)格式、質(zhì)量與透明底最后一步是把 canvas 變成能下載的Blobfunction canvasToBlob(canvas, { type image/jpeg, quality 0.85 } {}) { return new Promise((resolve, reject) { canvas.toBlob( (blob) (blob ? resolve(blob) : reject(new Error(toBlob 返回 null))), type, quality // 只對 image/jpeg 和 image/webp 生效PNG 會忽略 ); }); } // 導(dǎo)出 JPEG 前必須補(bǔ)白底否則透明區(qū)域會被填成黑色 function flattenToWhite(canvas) { const ctx canvas.getContext(2d); ctx.save(); ctx.globalCompositeOperation destination-over; // 只在透明像素下面鋪底 ctx.fillStyle #ffffff; ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.restore(); return canvas; }三個參數(shù)要記牢type缺省是image/pngPNG 無損但體積大quality在 0 到 1 之間JPEG 建議 0.82 到 0.88再高體積漲得快、肉眼幾乎看不出差別globalCompositeOperation: destination-over是補(bǔ)底色的正確姿勢用source-over會在圖片上面糊一層白。注意toBlob的回調(diào)可能收到null常見原因是畫布尺寸為 0 或者圖片觸發(fā)了跨域污染。用img.crossOrigin anonymous加載外鏈圖并且服務(wù)端要回Access-Control-Allow-Origin缺一個都會讓畫布變成臟畫布toBlob/getImageData全部拋安全錯誤。4. 排查清單翻轉(zhuǎn)后發(fā)虛、偏色、體積翻倍的五個真實(shí)原因這一章按現(xiàn)象 → 原因 → 解決來都是我實(shí)際遇到過、并且能在五分鐘內(nèi)定位的問題。4.1 現(xiàn)象翻轉(zhuǎn)后邊緣發(fā)虛文字和細(xì)線糊成一團(tuán)原因基本只有一個畫布緩沖區(qū)尺寸和繪制尺寸不一致觸發(fā)了重采樣。典型寫法是canvas.width 300、canvas.height 300但drawImage(img, 0, 0)畫進(jìn)去的是一張 4000×3000 的圖瀏覽器先縮小一次或者反過來canvas.width設(shè)成了 CSS 顯示尺寸的像素值在 2 倍屏上被拉伸一次。還有一種隱蔽情況drawImage傳了目標(biāo)寬高但取的是img.width帶 CSS 縮放的顯示寬度而不是naturalWidth。解決辦法是固定一條鐵律——翻轉(zhuǎn)管線的 canvas 緩沖區(qū)必須等于naturalWidth/naturalHeight顯示用 CSS 兜。定位時可以在翻轉(zhuǎn)后打印canvas.width和img.naturalWidth兩個數(shù)不相等就是它。4.2 現(xiàn)象PNG 透明圖翻轉(zhuǎn)后透明區(qū)域變黑了原因不是翻轉(zhuǎn)是導(dǎo)出。toBlob(image/jpeg)或toDataURL(image/jpeg)用的 JPEG 不支持 alpha 通道Canvas 的透明區(qū)域在編碼時會被合成為黑色某些實(shí)現(xiàn)下是白或黑取決于瀏覽器。如果原圖是帶透明底的摳圖素材翻轉(zhuǎn)后直接導(dǎo) JPEG 就廢了。解決辦法要么堅持導(dǎo)出 PNG體積換正確性要么在導(dǎo)出前用destination-over鋪一層白底或品牌色底。判斷標(biāo)準(zhǔn)很簡單——源文件是 PNG/WebP 且可能帶透明通道就一定要做這一步別指望用戶理解。4.3 現(xiàn)象翻轉(zhuǎn)后文件體積從 800KB 漲到 3MB三種成因從高到低排一是格式從 JPEG 變成了 PNGtoBlob不傳type時的默認(rèn)行為就是 PNG無損編碼對有噪點(diǎn)的照片極其不友好二是quality用了 0.95 以上接近無損但體積爆炸三是把 canvas 尺寸按 DPR 放大了兩倍再導(dǎo)出像素數(shù)直接四倍。解決辦法顯式傳type照片類內(nèi)容統(tǒng)一走image/jpegquality: 0.85只有需要透明背景的素材才用 PNG。翻轉(zhuǎn)本身不產(chǎn)生新信息體積膨脹一定是編碼參數(shù)或者尺寸搞錯了。4.4 現(xiàn)象手機(jī)豎拍照片翻轉(zhuǎn)方向是錯的左右鏡像變成了上下顛倒典型原因是 EXIF 方向被應(yīng)用了兩次或零次。前面 3.1 講過img默認(rèn)按 EXIF 渲染createImageBitmap則取決于imageOrientation參數(shù)?；煊脙蓷l解碼路徑就會出現(xiàn)看起來是橫的翻完還是橫的但方向反了這種情況。解決辦法整條管線只保留一個解碼入口并且在入口處就把方向問題解決掉后續(xù)的翻轉(zhuǎn)只處理用戶主動要求的鏡像。定位方法是在drawImage之前打印source.width和source.height如果 4:3 的照片打印出 3:4說明方向已經(jīng)應(yīng)用過不要再轉(zhuǎn)。4.5 現(xiàn)象連續(xù)翻轉(zhuǎn)多次后圖片越來越糊這是有損編碼的累積效應(yīng)。每次翻轉(zhuǎn)都經(jīng)歷了一輪解碼 → 重繪 → JPEG 編碼每輪都會丟一點(diǎn)高頻信息翻十次就明顯糊了尤其是人像皮膚和大面積漸變色。解決辦法不要拿翻轉(zhuǎn)后的結(jié)果當(dāng)下一輪的輸入。原始File或原始ImageBitmap只解碼一次并常駐每次翻轉(zhuǎn)都從它出發(fā)最后只編碼一次。如果確實(shí)需要保留歷史步驟中間態(tài)用 PNG 或者ImageBitmap存別用 JPEG 存。這個坑我在一個圖片編輯器項(xiàng)目里踩過用戶反復(fù)撤銷重做之后畫質(zhì)肉眼可見地崩最后就是靠只保留原圖 操作?；胤沤鉀Q的。5. 像素級翻轉(zhuǎn)用 ImageData 手動對調(diào)順帶扔進(jìn) WorkerCanvas 變換吩咐了瀏覽器去做好處是快、代碼少但有些場景必須自己搬像素——需要在翻轉(zhuǎn)同時做逐像素判斷或者要繞開主線程的卡頓。這時候就得上ImageData。5.1 ImageData 逐行搬運(yùn)的三個細(xì)節(jié)ImageData.data是一個Uint8ClampedArray每個像素 4 字節(jié)RGBA順序是R, G, B, A平鋪。所以第 y 行、第 x 個像素的紅色分量下標(biāo)是(y * width x) * 4。水平翻轉(zhuǎn)是同一行內(nèi)左右對調(diào)像素垂直翻轉(zhuǎn)是整行對調(diào)。后者能整塊搬運(yùn)效率高得多/** * 垂直翻轉(zhuǎn)整行對調(diào)用 TypedArray 的 set 做塊拷貝 * param {ImageData} imageData 原地修改 */ function flipVerticalInPlace(imageData) { const { width, height, data } imageData; const rowBytes width * 4; // 一行占多少字節(jié) const temp new Uint8ClampedArray(rowBytes); // 復(fù)用一個行緩沖避免每行新建 for (let y 0; y Math.floor(height / 2); y) { const top y * rowBytes; const bottom (height - 1 - y) * rowBytes; temp.set(data.subarray(top, top rowBytes)); // 存上邊一行 data.copyWithin(top, bottom, bottom rowBytes); // 下邊搬到上邊 data.set(temp, bottom); // 上邊放到下邊 } return imageData; } /** * 水平翻轉(zhuǎn)行內(nèi)左右像素對調(diào)逐像素交換 4 個通道 */ function flipHorizontalInPlace(imageData) { const { width, height, data } imageData; for (let y 0; y height; y) { const rowStart y * width * 4; for (let x 0; x Math.floor(width / 2); x) { const left rowStart x * 4; const right rowStart (width - 1 - x) * 4; for (let c 0; c 4; c) { // 四個通道一起換漏一個就會偏色 const t data[left c]; data[left c] data[right c]; data[right c] t; } } } return imageData; }三個細(xì)節(jié)值得說一是循環(huán)只跑到height / 2或者width / 2跑到全長會把每對像素?fù)Q兩次、等于沒換二是copyWithin在同一塊 buffer 內(nèi)部搬運(yùn)比手寫循環(huán)快但它不能用于重疊區(qū)有風(fēng)險的方向所以上下對調(diào)要借助temp中轉(zhuǎn)三是四個通道必須一起換只換 RGB 不換 A帶透明漸變的圖會出現(xiàn)詭異的光暈。5.2 用 Worker OffscreenCanvas 拆掉主線程卡頓一張 4000×3000 的圖getImageData出來的數(shù)組是 48MB主線程上跑一遍雙重循環(huán)基本就是幾百毫秒的白屏。解決辦法是把畫布控制權(quán)交給 Worker// main.js —— 主線程只負(fù)責(zé)派活和收活 const worker new Worker(./flip.worker.js); async function flipInWorker(file, mode horizontal) { const bitmap await createImageBitmap(file); return new Promise((resolve, reject) { worker.onmessage (e) { if (e.data.error) return reject(new Error(e.data.error)); resolve(e.data.blob); }; // bitmap 是 transferable轉(zhuǎn)移后主線程不再持有零拷貝 worker.postMessage({ bitmap, mode }, [bitmap]); }); }// flip.worker.js —— 離屏畫布 像素搬運(yùn) self.onmessage async ({ data }) { const { bitmap, mode } data; try { const canvas new OffscreenCanvas(bitmap.width, bitmap.height); const ctx canvas.getContext(2d); ctx.drawImage(bitmap, 0, 0); const imageData ctx.getImageData(0, 0, bitmap.width, bitmap.height); if (mode vertical) flipVerticalInPlace(imageData); else flipHorizontalInPlace(imageData); ctx.putImageData(imageData, 0, 0); // OffscreenCanvas 支持 convertToBlob語義與 toBlob 一致 const blob await canvas.convertToBlob({ type: image/jpeg, quality: 0.85 }); self.postMessage({ blob }); } catch (err) { self.postMessage({ error: err.message }); } };要點(diǎn)有三個createImageBitmap產(chǎn)生的bitmap是 transferablepostMessage的第二個參數(shù)把它轉(zhuǎn)移過去主線程側(cè)的對象會被置空這是零拷貝的關(guān)鍵Worker 里沒有document只能用OffscreenCanvasconvertToBlob的參數(shù)和toBlob一致但返回的是 Promise不用再包一層。注意OffscreenCanvas在老版本 Safari 上是缺失的落地時要做特性檢測typeof OffscreenCanvas undefined就回退到主線程的canvas路徑?；赝朔种e省很多用戶的瀏覽器版本就是不支持。6. 驗(yàn)收與進(jìn)階兩個能自動跑的校驗(yàn)比肉眼靠譜翻轉(zhuǎn)這種東西肉眼驗(yàn)收極不可靠——左右鏡像和上下顛倒在沒有參照物的時候長得一模一樣我在一個批量處理腳本上就吃過這個虧跑了三千張圖人工抽查了二十張都說沒問題上線后用戶反饋一半的證件照是倒的。從那以后我強(qiáng)制自己給翻轉(zhuǎn)加兩個自動校驗(yàn)跑通才算完事。第一個是對稱性校驗(yàn)任何翻轉(zhuǎn)做兩次必須還原。用同一張帶明顯不對稱內(nèi)容的圖比如左上角有個色塊翻轉(zhuǎn)兩次后逐像素比對原圖差異率超過千分之一就說明矩陣寫錯了或者中間做過重采樣。// 翻轉(zhuǎn)兩次應(yīng)還原比較像素平均絕對誤差 function assertInvolution(img) { const once flipImage(img, horizontal); const twice flipImage(once, horizontal); const a once.getContext(2d).getImageData(0, 0, once.width, once.height).data; const b twice.getContext(2d).getImageData(0, 0, twice.width, twice.height).data; let diff 0; for (let i 0; i a.length; i) diff Math.abs(a[i] - b[i]); const mae diff / a.length; console.log(MAE , mae.toFixed(3)); // 有損編碼下 2 屬正常0 說明完全無損 return mae 2; }第二個是錨點(diǎn)校驗(yàn)翻轉(zhuǎn)前后取四個角各 10×10 的像素塊水平翻轉(zhuǎn)后左上塊應(yīng)該等于原來的右上塊。這個校驗(yàn)不需要原圖緩存適合在 CI 里對一組固定樣張跑回歸。兩個校驗(yàn)加起來不到五十行但能把方向錯和翻轉(zhuǎn)丟失這兩類問題全部攔住。進(jìn)階方向有兩個。一是把翻轉(zhuǎn)和旋轉(zhuǎn)合并成一個變換枚舉{flipH, flipV, rotate}一共 8 種組合用一張查找表映射到translate/scale/rotate的調(diào)用序列比一堆 if-else 好維護(hù)得多。二是批處理時復(fù)用同一塊 canvas 和同一個ImageData緩沖尺寸不變的情況下能省掉大量分配幾千張圖跑下來 GC 次數(shù)肉眼可見地下降。包里那份flipImage.js和驗(yàn)收腳本我放在同一目錄下照著第 3 章的管線接一遍、再用第 6 章的兩個校驗(yàn)跑一遍基本就能確認(rèn)它在你自己的圖上是靠譜的。翻轉(zhuǎn)這種小功能代碼量從來不是問題真正花時間的是那些看起來對但其實(shí)反了的邊界把校驗(yàn)掛上去比事后擦屁股省事得多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取