1、Canvas是html5新增的畫布元素，允許我們使用Js來繪製圖形

2、Canvas最常見的用途是渲染動畫。

渲染動畫的基本原理無非是反覆的擦除和重繪。

為了動畫的流暢，留了一幀的時間，我們需要在16ms完成遊戲邏輯的處理，物件位置、狀態的計算以及把他們畫出來。一旦消耗時間多了，使用者就會感覺卡頓。所以提高動畫的效能很重要

3、優化渲染效能總體思路：

• 在每一幀中，儘可能減少呼叫渲染相關的API次數
• 在每一幀中，儘可能呼叫那些渲染開銷較低的API
• 在每一幀中，儘可能以導致開銷最低的方式呼叫渲染相關API

4、Canvas API都在其上下文物件context上呼叫的。

	var context = drawing.getContext("2d");
 

①context是一個狀態機。

②幾乎所有的渲染操作都是在context上完成的，最終的效果與context本身的狀態有關係，例如：

context.lineWidth = 5;             //矩形邊框寬度
context.strokeStyle = "red";       //矩形邊框顏色
context.strokeRect(50,50,80,80);   //繪製一個矩形

以上程式碼的第一二行必須放在第三行上邊，要不然不起作用。

對context.lineWidth的賦值開銷遠遠大於對一個普通物件的賦值開銷。因為canvas上下文不是一個普通的物件。。當呼叫context.lineWidth=5時，瀏覽器需要立刻做一些事情，這樣你下次呼叫諸如strokeRect等API時，畫出來的線正好是5個畫素寬（這也是一種優化，否則，這些事情要等到下次stroke之前做，會更加影響效能）

③context的一些其他的屬性賦值開銷

與真正的繪製操作相比，改變context狀態的開銷已經算是比較小的，畢竟還沒有真正的開始繪製

5、分層Cancas

      出發點：動畫中每種元素對渲染和動畫的要求是不一樣的。比如遊戲，人物變化的頻率是很大的（因為他們通常是走來走去的），而背景變化的頻率則相對較小，很明顯我們需要頻繁更新和繪製人物，但是對於背景，我們也許只需有繪製一次，也許只需要每隔200ms才繪製一次，決沒有必要每16ms繪製一次。分層Canvas能夠大大降低完全不必要的渲染效能開銷。

      使用：生成多個canvas例項，把他們重疊放置，每個canvas使用不同的z-index來定義堆疊的次序，最後僅在需要繪製該層的時候進行繪製

      注意：堆疊在上方的canvas中的內容會覆蓋住下方canvas的內容

6、繪製圖像

context.drawImage();

①資料來源和繪製的效能

      由於我們可以把圖片的一部分繪製在canvas，所以很多時候，我們會把多個遊戲物件放在一張圖片上，以減少請求數量。這通常稱為精靈圖。但是，繪製區域與源影象尺寸相仿時的開銷小於繪製區域小於源影象尺寸的開銷。開銷差異正是裁剪這一操作

      優化：離屏繪製，我們可以把待繪製的區域裁剪好，儲存。

drawImage()方法的第一個引數不僅可以接受image物件，也可以接受另一個canvas物件，兩者繪製的開銷基本一致

//在離屏canvas上繪製
	var canvasOffscreen = document.createElement("canvas");
	canvasOffscreen.width = dw;
	canvasOffscreen.height = dh;
	canvasOffscreen.getContext("2d").drawImage(image,sx,sy,sw,sh,dx,dy,dw,dh);	
	
//在繪製每一幀的時候，繪製這個圖形
	context.drawImage(canvasOffscreen,x,y);

②視野之外的繪製

    有時候，canvas只是遊戲世界的一個視窗，如果我們每一幀都要把遊戲世界全部畫出來，勢必會有很多東西畫到canvas外，同樣呼叫了繪製API，但是沒有任何效果。但是我們也知道判斷一個物件是否在canvas會有額外的計算開銷，並且增加程式碼的複雜度

   我做了一個實驗，繪製一張 320x180 的圖片 10 4 次，當我每次都繪製在 Canvas 內部時，消耗了 40ms，而每次都繪製在 Canvas 外時，僅消耗了 8ms。大家可以掂量一下，考慮到計算的開銷與繪製的開銷相差 2~3 個數量級，我認為通過計算來過濾掉哪些畫布外的物件，仍然是很有必要的。

③避免阻塞

        所謂「阻塞」，可以理解為不間斷執行時間超過 16ms 的 JavaScript 程式碼，以及「導致瀏覽器花費超過 16ms 時間進行處理」的 JavaScript 程式碼。即使在沒有什麼動畫的頁面裡，阻塞也會被使用者立刻察覺到：阻塞會使頁面上的物件失去響應——按鈕按不下去，連結點不開，甚至標籤頁都無法關閉了。而在包含較多 JavaScript 動畫的頁面裡，阻塞會使動畫停止一段時間，直到阻塞恢復後才繼續執行。如果經常出現「小型」的阻塞（比如上述提及的這些優化沒有做好，渲染一幀的時間超過 16ms），那麼就會出現「丟幀」的情況，CSS3 動畫（ transition 與 animate ）不會受 JavaScript 阻塞的影響，但不是本文討論的重點。

需要解決的兩種阻塞：

• 頻繁（通常較小）的阻塞：主要原因是過高的渲染效能開銷，在每一幀中做的事情太多
• 偶爾（通常較大）的阻塞：主要原因是演算法複雜度、大規模的DOM操作等

對應前者的解決方案，本文前幾節中的優化方案

對於後者的解決方案：使用web Worker，在另一個執行緒中計算（無法操作DOM）；將任務拆分成多個較小的任務，插在多幀中進行（增長執行時間）

7、優化總結：

①將渲染階段的開銷轉嫁到計算階段

②少使用font屬性

③分層canvas

④

• 離屏繪製：將固定的內容預先繪製在離屏canvas
•  通過計算和判斷，避免無謂的繪製操作
• 使用webwoker和拆分任務的方法避免演算法複雜度過高則色動畫執行