1.計算與渲染
把影片的一幀渲染出來，需要經過以下步驟：
- 計算：處理電子表格邏輯，計算 workbook 的狀態，不涉及 DOM 操作（當然也包含對 Canvas 背景關系的操作），
- 渲染：真正把物件繪制出來，
- JavaScript 呼叫 DOM API（包括 Canvas API）以進行渲染，
- 瀏覽器 把渲染后的結果呈現在螢屏上的程序，
2.canvas 繪制間隔策略
- 主動觸發重繪 canvas （電子表格）
- 定時器回圈重繪 canvas （影片，游戲推薦）, requestAnimationFrame 相對于 setinterval 處理影片有以下幾個優勢：
- 經過瀏覽器優化，影片更流暢
- 視窗沒激活時，影片將停止，省計算資源
- 更省電，尤其是對移動終端
3.分層 Canvas
- 分層 Canvas 的出發點是，影片中的元素（層），對渲染和影片的要求是不一樣的
- 實作 UI 重疊的視覺效果（案例：騰訊檔案 word 畫布）
4. canvas scale() 天然支持放大縮小
5.離屏繪制，使用快取
繪制同樣的一塊區域，如果資料源是一張大圖上的一部分，性能就會比較差，因為每一次繪制還包含了裁剪作業，可以先把待繪制的區域裁剪好，保存起來，這樣每次繪制時就能輕松很多，
drawImage 方法的第一個引數不僅可以接收 Image 物件，也可以接收另一個 Canvas 物件，而且，使用 Canvas 物件繪制的開銷與使用 Image 物件的開銷幾乎完全一致，我們只需要實作將物件繪制在一個未插入頁面的 Canvas 中，然后每一幀使用這個 Canvas 來繪制，
并且離屏canvas也不能用的太泛濫，如果用太多離屏canvas也會有性能問題
6. 盡量少呼叫 canvasAPI ，盡可能集中繪制
提升 canvas 的性能最主要的還是得注意代碼的結構，減少不必要的API呼叫，在每一幀中減少復雜的運算或者把復雜運算由每一幀算一次改成數幀算一次，
7.避免使用高耗能的 API
- 清除畫布盡量使用 clearRect
- 避免浮點運算
一般情況下的性能： clearRect > fillRect > canvas.width=canvas.width;
8. 避免「阻塞」
偶爾的且較小的阻塞是可以接收的，頻繁或較大的阻塞是不可以接受的，也就是說，我們需要解決兩種阻塞：
- 頻繁（通常較小）的阻塞，其原因主要是過高的渲染性能開銷，在每一幀中做的事情太多，
- 較大（雖然偶爾發生）的阻塞，其原因主要是運行復雜演算法、大規模的 DOM 操作等等，
對前者，我們應當仔細地優化代碼，有時不得不降低影片的復雜（炫酷）程度，本文前幾節中的優化方案，解決的就是這個問題，
而對于后者，主要有以下兩種優化的策略，
- 使用 Web Worker，在另一個執行緒里進行計算，
- 將任務拆分為多個較小的任務，插在多幀中進行，
Web Worker 是好東西，性能很好，兼容性也不錯，瀏覽器用另一個執行緒來運行 Worker 中的 JavaScript 代碼，完全不會阻礙主執行緒的運行，影片（尤其是游戲）中難免會有一些時間復雜度比較高的演算法，用 Web Worker 來運行再合適不過了，
9. 不要頻繁設定繪圖背景關系的 font 屬性，
10. Canvas 視圖與事件模型封裝
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/255611.html
標籤：其他
上一篇：漢諾塔問題詳解
下一篇：JAVA-高頻面試題匯總:鏈表