簡介這是一款基于 uni-app 與純 canvas 實現(xiàn)的跨端轉(zhuǎn)盤項目面向微信小程序、支付寶小程序、抖音小程序等全端開發(fā)場景幫助開發(fā)者免去從零造輪子直接獲得可運行的自定義抽獎/選擇轉(zhuǎn)盤。壓縮包共13個文件包含vue頁面與組件、json工程配置、js業(yè)務(wù)邏輯、scss樣式、png圖標及readme說明文檔整體僅19KB使用 HbuilderX 導(dǎo)入即可運行文件分工明確、結(jié)構(gòu)輕量便于快速定位和二次修改。功能方面支持輪盤轉(zhuǎn)動、自定義轉(zhuǎn)盤選項、按權(quán)重抽獎、轉(zhuǎn)速減速模擬真實轉(zhuǎn)動以及選項顏色設(shè)置自定義選項支持任意數(shù)量的內(nèi)容錄入權(quán)重設(shè)置可靈活調(diào)整中獎概率內(nèi)容也可自由替換既能用于線上抽獎、抓鬮也能用于日常生活中的“今天吃什么”“周末去哪玩”等選擇場景。readme 中附有基礎(chǔ)使用說明可幫助你理解配置和擴展方式方便快速集成到現(xiàn)有小程序項目。對于想學(xué)習(xí) uni-app 跨端開發(fā)或 canvas 繪圖的中初級開發(fā)者這是一套易于閱讀和改造的實用模板也可作為畢業(yè)設(shè)計或功能模塊的參考起點。目前已有319人學(xué)習(xí)下載。1. 純canvas轉(zhuǎn)盤uni-app小程序里最不該用插件的地方做小程序抽獎轉(zhuǎn)盤很多人第一反應(yīng)是去插件市場找現(xiàn)成的但實際接進來才發(fā)現(xiàn)插件體積大、樣式和業(yè)務(wù)耦合深想改個配色、加個概率控制都得看別人臉色。更重要的是轉(zhuǎn)盤的核心邏輯其實就兩件事——畫扇形和轉(zhuǎn)動畫用canvas手寫兩百行足夠而且概率可以做到完全可控。這篇筆記要拆的就是uni-app 小程序原生canvas從零實現(xiàn)轉(zhuǎn)盤的完整過程包含繪制、動畫、概率分配、真機兼容性排查以及封裝成組件的進階做法。適合那些想自己掌控抽獎邏輯、不想被第三方插件綁定的開發(fā)者也適合剛接觸canvas但想直接落地一個實戰(zhàn)項目的從業(yè)者。2. 轉(zhuǎn)盤繪制與概率模型先把canvas坐標系和份額算清楚2.1 從角度到弧長canvas繪制轉(zhuǎn)盤的最小幾何體系canvas的坐標系原點在左上角x軸向右y軸向下。這對繪制轉(zhuǎn)盤二維圓形沒有影響只要你把圓心定位在畫布中心(r, r)一切圍繞圓心轉(zhuǎn)。真正需要費心的是角度canvas的arc方法用的是弧度制一個完整圓是2π而不是360。很多從css動畫轉(zhuǎn)過來的同學(xué)會在這里卡住習(xí)慣性地用360 / 獎品數(shù)量結(jié)果畫出來要么缺了一塊要么扇區(qū)重疊。轉(zhuǎn)盤的每個扇區(qū)本質(zhì)上是一個從startAngle到endAngle的圓弧封口扇形。假如你有 N 個獎品每個獎品對應(yīng)的扇區(qū)角度就是該獎品權(quán)重占總權(quán)重的比例乘以2π。假設(shè)獎品數(shù)組為const prizes [ { name: 一等獎, weight: 1 }, { name: 二等獎, weight: 2 }, { name: 三等獎, weight: 3 }, { name: 謝謝參與, weight: 4 } ]那么總權(quán)重是1 2 3 4 10“謝謝參與”的扇區(qū)角度就是4 / 10 * 2π 0.4 * 2π。這個比例直接決定了指針停在它上面的概率不要再去寫一堆if (random 0.1)之類的判斷全部交給權(quán)重換算即可。繪制扇區(qū)時使用ctx.arc(centerX, centerY, radius, startAngle, endAngle)。但要注意arc的角度默認是從三點鐘方向開始也就是0弧度對應(yīng)正右方。而轉(zhuǎn)盤的指針通常在正上方所以需要把起始角度整體偏移-π/2讓第一個扇區(qū)從十二點鐘方向開始。這個偏移是canvas轉(zhuǎn)盤最容易忽略的細節(jié)我見過不止一個開發(fā)者因為少了這個偏移導(dǎo)致轉(zhuǎn)盤視覺上旋轉(zhuǎn)了一個象限。2.2 權(quán)重與概率讓每個獎品的中獎率嚴格可控實現(xiàn)可控概率有兩種思路一種是先隨機生成角度再判斷這個角度落在哪個扇區(qū)另一種是先按權(quán)重抽出獎品再反推轉(zhuǎn)盤要停的位置。后者更常用因為你提前知道中獎結(jié)果可以避免前端隨機數(shù)導(dǎo)致“一等獎連續(xù)中了三次”這種尷尬情況。先按權(quán)重抽獎function getPrizeIndex() { const totalWeight prizes.reduce((sum, item) sum item.weight, 0) let random Math.random() * totalWeight for (let i 0; i prizes.length; i) { random - prizes[i].weight if (random 0) return i } return prizes.length - 1 }邏輯很直白把總權(quán)重放在一條數(shù)軸上每次減去當前獎品的權(quán)重減到小于等于零時說明隨機數(shù)落在當前獎品的區(qū)間。這樣每個獎品的中獎概率嚴格等于weight / totalWeight。抽中索引后要計算轉(zhuǎn)盤最終停在哪個角度。假設(shè)指針固定在正上方即畫布坐標系里的-π/2弧度。那么為了讓第i個扇區(qū)的中心恰好對準指針需要的整體旋轉(zhuǎn)角度等于const perAngle 2 * Math.PI / totalWeight const centerAngle -Math.PI / 2 (sumWeightBefore prizes[i].weight / 2) * perAngle // 讓轉(zhuǎn)盤額外轉(zhuǎn)幾圈視覺上更自然 const extraCircles 5 Math.floor(Math.random() * 4) const targetAngle -centerAngle extraCircles * 2 * Math.PI這里的sumWeightBefore是當前獎品之前所有獎品的權(quán)重之和。把centerAngle取負是因為旋轉(zhuǎn)的累計值要抵消扇區(qū)原本的角度指數(shù)針最終指向扇區(qū)的中心。extraCircles指定額外轉(zhuǎn)動的圈數(shù)通常在 5 到 8 圈之間太少顯得沒勁太多會讓人等待煩躁。這一步做完你就已經(jīng)握住了轉(zhuǎn)盤的“物理引擎”。剩下的動畫只不過是把當前角度從 0 平滑地過渡到targetAngle而已。3. uni-app里從零實現(xiàn)轉(zhuǎn)盤繪制、動畫、回調(diào)用完整代碼拆給你3.1 在uni-app中創(chuàng)建canvas并適配不同屏幕uni-app 在小程序端會編譯成原生 canvas 組件所以在模板里使用canvas canvas-idprizeCanvas而不是 H5 的canvas id...。這意味著不能通過document.getElementById獲取必須使用uni.createCanvasContext(canvasId, this)。第二個參數(shù)this在 Vue 組件中不可省略否則在組件內(nèi)會找不到 canvas這是一個需要留意的小細節(jié)。canvas 的默認尺寸是 300x150若不做適配轉(zhuǎn)盤會被壓扁。我會在data里聲明canvasSize并在onReady中根據(jù)屏幕寬度動態(tài)計算canvas canvas-idprizeCanvas :stylewidth: canvasSize px;height: canvasSize px/canvasdata() { return { canvasSize: 300, ctx: null, isDrawing: false } }, onReady() { const { windowWidth } uni.getSystemInfoSync() this.canvasSize Math.floor(windowWidth * 0.8) this.ctx uni.createCanvasContext(prizeCanvas, this) this.drawWheel(0) }canvasSize取屏幕寬度的 80%是因為轉(zhuǎn)盤周圍往往還要放按鈕和文案留一點安全邊距。如果你在 PC 端瀏覽器調(diào)試windowWidth可能大于 750轉(zhuǎn)盤會大得離譜這時可以加一個Math.min(width, 600)限制最大尺寸。繪圖坐標系直接使用這個canvasSize而把它作為圓心計算基準。drawWheel(0)是首次繪制傳入0表示當前累計旋轉(zhuǎn)角度為零。注意canvas 繪制是異步的uni.createCanvasContext獲取的上下文在onReady里通常已經(jīng)可用但如果遇到偶發(fā)獲取不到的情況可以用setTimeout包一層或者調(diào)用uni.nextTick。3.2 繪制扇區(qū)與文字循環(huán)里的坐標系變換是關(guān)鍵繪制轉(zhuǎn)盤的核心函數(shù)是drawWheel它接受一個rotation參數(shù)表示當前累計旋轉(zhuǎn)了多少弧度。所有扇區(qū)的起始角度都要加上這個旋轉(zhuǎn)量這樣才能讓整個轉(zhuǎn)盤看起來在轉(zhuǎn)動。drawWheel(rotation) { const ctx this.ctx const r this.canvasSize / 2 ctx.clearRect(0, 0, this.canvasSize, this.canvasSize) const totalWeight this.prizes.reduce((sum, j) sum j.weight, 0) let startAngle -Math.PI / 2 rotation this.prizes.forEach((item, index) { const sliceAngle (item.weight / totalWeight) * 2 * Math.PI const endAngle startAngle sliceAngle // 繪制扇形區(qū)域 ctx.beginPath() ctx.moveTo(r, r) ctx.arc(r, r, r - 10, startAngle, endAngle) ctx.closePath() ctx.fillStyle item.color ctx.fill() // 在扇區(qū)中央繪制文字 ctx.save() ctx.translate(r, r) ctx.rotate(startAngle sliceAngle / 2) ctx.textAlign right ctx.fillStyle #fff ctx.font 14px sans-serif ctx.fillText(item.name, r - 20, 5) ctx.restore() startAngle endAngle }) // 繪制中心點綴圓 ctx.beginPath() ctx.arc(r, r, 18, 0, 2 * Math.PI) ctx.fillStyle #fff ctx.fill() ctx.draw() }這里有兩個關(guān)鍵點需要說明。一是扇區(qū)繪制moveTo(r, r)讓路徑從圓心開始arc繪制從圓心到圓弧的邊界closePath閉合形成扇形。r - 10是扇區(qū)的繪制半徑留出 10px 給轉(zhuǎn)盤外圈或描邊避免扇區(qū)頂?shù)?canvas 邊緣。如果你希望圓盤外圈有邊框可以額外再arc描邊。二是文字繪制save保存當前狀態(tài)translate(r, r)把坐標系原點移到圓心rotate旋轉(zhuǎn)到扇區(qū)的中心角。這時fillText的基準點在圓心通過textAlign right讓文字在半徑方向向外對齊。fillText(name, r - 20, 5)中的r - 20是文字距離圓心的長度20 可以保證文字不貼著外邊緣5是垂直偏移用于微調(diào)文字基線。如果你的獎品名稱較長比如六個字以上可以把r - 20改成r * 0.65或者手動傳入文字大小。注意startAngle在循環(huán)中被賦值成endAngle這是為了讓每個扇區(qū)連續(xù)銜接。如果某個產(chǎn)品經(jīng)理臨時要求獎品間有分隔線可以在每兩個扇區(qū)之間加一個ctx.strokeStyle #fff; ctx.stroke()但那樣需要在arc后不closePath直接描邊路徑這個細節(jié)可以根據(jù)實際需求調(diào)整。3.3 轉(zhuǎn)盤旋轉(zhuǎn)動畫用緩動函數(shù)控制速度和圈數(shù)動畫的目標是讓rotation從 0 平滑增長到targetAngle。直接線性遞增會顯得機械真實的轉(zhuǎn)盤應(yīng)該是先快后慢所以我采用一個簡單的緩動函數(shù)easeOutQuart它的表達式是1 - Math.pow(1 - progress, 4)。這個函數(shù)的曲線是前期速度快、后期速度慢非常接近常見抽獎轉(zhuǎn)盤的減速效果。startDraw() { if (this.isDrawing) return this.isDrawing true const prizeIndex this.getPrizeIndex() this.targetRotation this.calcTargetRotation(prizeIndex) this.currentRotation 0 this.animationFrame 0 this.totalFrames 60 this.timer setInterval(() { this.animationFrame const progress Math.min(this.animationFrame / this.totalFrames, 1) const eased 1 - Math.pow(1 - progress, 4) const currentRotation this.targetRotation * eased this.drawWheel(currentRotation) if (progress 1) { clearInterval(this.timer) this.isDrawing false const prize this.prizes[prizeIndex] uni.showToast({ title: prize.name, icon: none }) } }, 16) }這里有幾個細節(jié)值得注意。首先totalFrames控制動畫總時長。每幀間隔 16mstotalFrames 60時總時長約為 960ms加上前后偏差基本在一秒左右。如果你的產(chǎn)品經(jīng)理要求轉(zhuǎn)得更久直接把totalFrames加大到 90 或 120同時記得targetRotation中也要有足夠的整圈數(shù)來支撐這么長的時長。其次currentRotation每次都從 0 重新計算而不是在上一幀基礎(chǔ)上累加。這是因為eased在末期增長非常緩慢如果用currentRotation step的方式容易出現(xiàn)最后停留角度輕微抖動。而使用targetRotation * eased可以保證最后一幀恰好等于targetRotation不會出現(xiàn)因為浮點誤差導(dǎo)致指針偏離的問題。第三setInterval的間隔 16ms 在大部分設(shè)備上接近 60fps但小程序動畫幀算不上精確如果遇到卡頓可以看第 4 章的優(yōu)化。停止動畫的條件是progress 1此時立即清除定時器并回調(diào)結(jié)果。在實際項目中你多半要把uni.showToast換成自定義彈窗并把這個回調(diào)暴露給業(yè)務(wù)層。3.4 抽獎事件與結(jié)果回調(diào)把指針位置翻譯成獎品抽獎按鈕的click事件里調(diào)用startDraw同時要加鎖避免連點。上面的代碼已經(jīng)用this.isDrawing做了判斷但還有一個邊界如果用戶在動畫還沒結(jié)束時再次點擊會被直接return。這雖然解決了并發(fā)問題但更好的交互是按鈕置灰或顯示“旋轉(zhuǎn)中”狀態(tài)。我會在data里增加一個disabled狀態(tài)在動畫開始時設(shè)為true結(jié)束后再置回false。結(jié)果回調(diào)不一定都用uni.showToast更優(yōu)雅的方式是讓startDraw接收一個回調(diào)函數(shù)或者通過this.$emit拋給父組件。例如startDraw() { // ... if (progress 1) { clearInterval(this.timer) this.isDrawing false this.$emit(draw-end, prize) } }這樣頁面里只需要監(jiān)聽draw-endhandleDrawEnd就能拿到中獎獎品。注意如果轉(zhuǎn)盤組件里的獎品配置是異步從后端接口獲取的那么繪制函數(shù)必須等待數(shù)據(jù)到達后再調(diào)用drawWheel。也就是說onReady時先檢查prizes是否為空空則只繪制一個空白圓環(huán)接口返回后重新賦值并再次drawWheel(0)否則會出現(xiàn)“看得到按鈕但轉(zhuǎn)盤空白”的僵尸狀態(tài)。此外有關(guān)概率計算的代碼可以單獨抽成一個模塊而不寫在組件內(nèi)部。因為不同活動對獎品概率的要求可能完全不同有的需要后端強制校驗有的只要前端本地隨機。把getPrizeIndex和calcTargetRotation放到純函數(shù)文件里單元測試也會更容易寫。4. 避坑手冊canvas轉(zhuǎn)盤在小程序端最容易翻車的五個細節(jié)4.1 現(xiàn)象真機上報錯“canvas is not defined”或“Cannot read property draw of undefined”模擬器和開發(fā)工具上轉(zhuǎn)盤正常但真機報錯多半是ctx獲取的時機不對。uni-app 在某些安卓機型上onReady時 canvas 組件尚未完全掛載立刻createCanvasContext返回的上下文是不完整的。原因canvas 是原生組件渲染優(yōu)先級與 webview 不同開發(fā)者工具里因為同步渲染所以沒問題但真機上原生 canvas 的初始化有異步延遲。解決不要迷信onReady。穩(wěn)妥的做法是把首次繪制放到setTimeout中比如延遲 100ms 再初始化onReady() { setTimeout(() { this.ctx uni.createCanvasContext(prizeCanvas, this) this.drawWheel(0) }, 100) }如果 100ms 后仍然失敗再排查 canvas-id 是否和頁面中其他 canvas 重名。多個頁面或組件共用同一個 canvas 組件的實例時canvas-id 必須全局唯一不能只在頁面內(nèi)唯一。4.2 現(xiàn)象繪制文字后字體變模糊尤其iPhone真機字體模糊的原因不是 canvas 的問題而是ctx.font里直接用14px sans-serif在小程序端可能被縮放。iPhone 6 及以后機型都使用高倍屏如果沒有把 canvas 的物理像素對齊到屏幕像素繪制出來的文字就會發(fā)虛。原因canvas 組件的 css 尺寸和畫布內(nèi)部實際像素沒有匹配。小程序舊版 canvas 默認把畫布尺寸設(shè)置成 css 尺寸乘以devicePixelRatio但如果你通過createCanvasContext使用其中一套坐標系就會出現(xiàn)模糊。解決不要在大尺寸轉(zhuǎn)盤上用 14px 這么小的字盡量把文字加大到 16px 以上。同時在設(shè)置 canvas 樣式尺寸時可以在canvasSize上乘以pixelRatio并給 canvas 標簽設(shè)置widthcanvasSize * pixelRatio、height...但這樣做對舊版 canvas 反而容易出問題。我實踐后最省心的方法是不要追求物理像素完美直接投資在字號和字重上比如ctx.font bold 18px sans-serif這樣即使有輕微縮放視覺上依然是清晰的。如果你堅持要高清適配建議改用新版 canvas 2D 接口type2d但那會帶來更多兼容問題本章后面再討論。4.3 現(xiàn)象旋轉(zhuǎn)動畫在部分安卓機上卡頓甚至閃屏動畫卡頓通常不是因為復(fù)雜繪制而是setInterval在小程序后臺或低端機上不穩(wěn)定。安卓低端機的setInterval實際間隔可能超過 30ms導(dǎo)致動畫掉幀。原因原生 canvas 每次ctx.draw()都會觸發(fā)渲染動畫期間每秒約 60 次重繪如果代碼里還有uni.createSelectorQuery之類的頻繁調(diào)用主線程會被占滿。解決去掉動畫幀里的無關(guān)操作例如不要在drawWheel內(nèi)每次重新計算this.prizes的總權(quán)重把它提前到data初始化時算好并緩存。同時把setInterval換成requestAnimationFrame的封裝uni-app 全局沒有標準的requestAnimationFrame但可以通過nextFrame實現(xiàn)function nextFrame(callback) { setTimeout(callback, 16) }然后在動畫循環(huán)里遞歸調(diào)用nextFrame而不是setInterval。這樣在頁面不可見時自動暫停遞歸調(diào)用減少無意義的消耗。4.4 現(xiàn)象轉(zhuǎn)盤停在了按鈕的正下方而不是指針位置這是角度偏移導(dǎo)致的經(jīng)典問題。指針固定在正上方但旋轉(zhuǎn)目標角度計算時少減了一個-Math.PI / 2的基準偏移導(dǎo)致最終停的位置剛好差 90 度。原因繪制時已經(jīng)加了-Math.PI / 2作為起始偏移但計算centerAngle時沒有考慮這個偏移或者反過來重復(fù)計算。解決統(tǒng)一用“指針指向正上方”作為唯一的基準。我通常會封裝一個函數(shù)計算某個獎品中心的目標旋轉(zhuǎn)角calcTargetRotation(index) { const totalWeight this.totalWeight let sumBefore 0 for (let i 0; i index; i) { sumBefore this.prizes[i].weight } const centerAngle -Math.PI / 2 (sumBefore this.prizes[index].weight / 2) * (2 * Math.PI / totalWeight) const extraCircles 5 Math.floor(Math.random() * 4) return -centerAngle extraCircles * 2 * Math.PI }注意centerAngle以-Math.PI / 2開頭最后取負后負負得正這樣targetRotation永遠是正數(shù)表示順時針轉(zhuǎn)動。如果你希望逆時針旋轉(zhuǎn)直接改成正的centerAngle取負邏輯即可但記住扇區(qū)繪制時的角度方向也隨之變化。4.5 現(xiàn)象修改獎品列表后canvas沒有刷新轉(zhuǎn)盤的獎品列表如果是動態(tài)的比如用戶參與前從后端拉取名稱和權(quán)重那么繪制時必須重置startAngle到-Math.PI / 2然后用新的獎品數(shù)組重新計算。常見錯誤是直接調(diào)用drawWheel(this.currentRotation)但currentRotation可能還保留了舊動畫的旋轉(zhuǎn)角度導(dǎo)致兩套獎品疊加在一起。原因canvas 繪制是即時的如果你不清空舊的扇區(qū)形狀還在畫布上。clearRect雖然清空了但下一次循環(huán)如果沒有從初始角度開始就會在上一次扇區(qū)結(jié)束角度基礎(chǔ)上繼續(xù)畫扇區(qū)角度越積越多。解決在setPrizes(newPrizes)方法里強制重置setPrizes(newPrizes) { this.prizes newPrizes const totalWeight newPrizes.reduce((sum, item) sum item.weight, 0) this.totalWeight totalWeight this.currentRotation 0 this.drawWheel(0) }并且要把totalWeight緩存起來不要在drawWheel每次計算。養(yǎng)成這個習(xí)慣后再遇到數(shù)據(jù)動態(tài)更新只要調(diào)用setPrizes轉(zhuǎn)盤就會干凈地重繪。5. 進階把轉(zhuǎn)盤封裝成可復(fù)用組件順便解決主題定制與性能5.1 組件化設(shè)計參數(shù)驅(qū)動繪制轉(zhuǎn)盤做一次容易但在多個活動頁里復(fù)用就麻煩了。我會把它封裝成一個CanvasWheel組件通過props接收獎品列表、指針位置、旋轉(zhuǎn)動畫時長通過events回傳中獎結(jié)果。這樣業(yè)務(wù)頁面里只需要維護一個獎品數(shù)組不用關(guān)心 canvas 的繪制細節(jié)。組件內(nèi)部的核心邏輯是監(jiān)聽prizes的深度變化自動調(diào)用setPrizes。特別注意的是不要把prizes的默認值寫成[]然后直接內(nèi)聯(lián)修改務(wù)必通過watch監(jiān)聽props: { prizes: { type: Array, required: true } }, watch: { prizes: { handler(newVal) { this.setPrizes(newVal) }, deep: true, immediate: true } }immediate: true讓組件在創(chuàng)建時就執(zhí)行第一次繪制不用等onReady手動調(diào)用。配合第 3 章的setTimeout初始化就能保證按鈕出現(xiàn)前畫布已經(jīng)就緒。5.2 自定義品牌色與獎品圖片默認的純色扇區(qū)太單調(diào)。常見需求是扇區(qū)背景使用漸變色或品牌 logo 圖片。小程序 canvas 同樣支持ctx.createLinearGradient但背景圖片需要先用uni.getImageInfo拿到本地路徑再用ctx.drawImage繪制。要注意繪制圖片時如果圖片尚未緩存drawImage會靜默失敗所以我會把圖片預(yù)加載和扇形繪制分開async preloadImages(list) { const images [] for (const item of list) { if (item.image) { const info await uni.getImageInfo({ src: item.image }) images.push(info.path) } else { images.push() } } return images }繪制時先填充色作為底色再在扇區(qū)邊界內(nèi)裁剪并繪制圖片。這里需要ctx.save()ctx.arc()ctx.clip()的組合讓圖片只出現(xiàn)在當前扇區(qū)內(nèi)否則圖片會溢出到相鄰扇區(qū)。這個裁剪操作比直接畫圖片更可控也是自定義轉(zhuǎn)盤的高頻技巧。5.3 性能優(yōu)化離屏繪制與動畫節(jié)流如果轉(zhuǎn)盤獎品多、圖片多每幀都重新繪制所有扇區(qū)和圖片低端機會卡。常見優(yōu)化是把靜止層扇區(qū)、文字、背景圖先繪制到離屏 canvas 上動畫時只旋轉(zhuǎn)整個離屏畫布而不是重新繪制扇區(qū)。小程序?qū)﹄x屏 canvas 的支持不如 H5 完整但可以使用同一個canvas-id配合setTransform實現(xiàn)類似效果或者在動畫期間把drawWheel的重繪頻率降低到每秒 30 次。我個人常用的做法動畫前把靜態(tài)扇區(qū)繪制到單獨一張 canvas 并緩存離屏數(shù)據(jù)動畫時用ctx.drawImage把緩存繪制到主 canvas再在主 canvas 上繪制指針。這樣每幀只需要繪制一次圖片和指針繪制成本大幅下降。不過這個優(yōu)化有前提——獎品數(shù)不能變化扇區(qū)角度固定。一旦獎品權(quán)重變化離屏緩存必須重建。有一次我在一個抽獎活動里偷懶沒有做緩動直接用線性動畫結(jié)果產(chǎn)品經(jīng)理反饋“轉(zhuǎn)盤停下來的那一瞬間特別生硬”。后來我把easeOutQuart換成了更陡的easeOutQuint效果才自然。從那以后我每次做轉(zhuǎn)盤都強制走一遍概率計算和動畫緩動驗證確認落點準確再交付。希望這些踩坑經(jīng)驗?zāi)軒湍闵僮邚澛啡绻阋矞蕚湓?uni-app 小程序里落地轉(zhuǎn)盤不妨先把第 2 章的角度模型在草稿紙上推一遍再開始碼代碼多花十分鐘后面能省你好幾個小時。本文還有配套的精品資源點擊獲取