oogle Docs宣布將會把HTML遷移到基于Canvas渲染,這一消息的出現再次把幾年前隨HTML5誕生的標簽重新推到了人們視線之中。Canvas在剛推出時主打的優勢就是更快的渲染速度,堪稱HTML屆的“小飛人”,刷新了人們對Web頁面元素繪制速度的印象。但Canvas的優勢僅限于此嗎?
(圖片來源于網絡)
Canvas是HTML5時代引入的“新”標簽。與很多標簽不同,Canvas不具有自己的行為,只將一組API 展現給客戶端 JavaScript ,讓開發者使用腳本把想繪制的東西畫到一張畫布上。
在HTML5之前,人們通常使用SVG來在頁面上繪制出圖形。SVG使用XML來定義圖形,就像使用HTML標簽和樣式定義DIV一樣,我們也可以將一個空白的DIV想象為長方形的SVG,兩者的設計思想是相通的,SVG的本質就是一個DOM元素。而Canvas則不同,Canvas提供的是 JavaScript 的繪圖 API,而不是像 SVG那樣使用XML 描述繪圖,通過JavaScript API直接完成繪制,比起修改XML來說要更簡便、更直接。
除了定義的方式不同,Canvas和DOM(當然也包含SVG)的差異更多的體現在瀏覽器的渲染方式上。
瀏覽器在做頁面渲染時,Dom元素是作為矢量圖進行渲染的。每一個元素的邊距都需要單獨處理,瀏覽器需要將它們全都處理成像素才能輸出到屏幕上,計算量十分龐大。當頁面上內容非常多,存在大量DOM元素的時候,這些內容的渲染速度就會變得很慢。
而Canvas與DOM的區別則是Canvas的本質就是一張位圖,類似img標簽,或者一個div加了一張背景圖(background-image)。所以,DOM那種矢量圖在渲染中存在的問題換到Canvas身上就完全不同了。在渲染Canvas時,瀏覽器只需要在JavaScript引擎中執行繪制邏輯,在內存中構建出畫布,然后遍歷整個畫布里所有像素點的顏色,直接輸出到屏幕就可以了。不管Canvas里面的元素有多少個,瀏覽器在渲染階段也僅需要處理一張畫布。
然而這樣更加強大的功能,不可避免的讓使用canvas渲染有很高的門檻。Google Docs在構建Canvas的過程中重新定義了往常已經被人們所熟悉的內容,例如精確定位、文本選擇、拼寫檢查、重畫調優等。為什么更多開發者還是選擇了接納Canvas這個門檻更高的技術路線呢?這就得回到Canvas的最大優勢:渲染性能。
這里的渲染是指瀏覽器將頁面的代碼呈現為屏幕上內容的過程。Canvas和Dom的渲染模式完全不同,搞清楚這個差異對理解Canvas的性能優勢至關重要。
Dom:駐留模式
駐留模式(Retained Mode)是Dom在瀏覽器中的渲染模式。下圖粗略展示了這一過程的工作流程。
DOM的核心是標簽,一種文本標記型語言,多樣性很強且多個標簽之間存在各種關聯(如在同一個DIV下設置為float的子DIV)。瀏覽器為了更好的處理這些DOM元素,減少對繪制API的調用,就設計了一套將中間結果存放于內存的“駐留模式”。首先,瀏覽器會將解析DOM相關的全部內容(包含HTML標簽、樣式和JavaScript),將其轉化為場景(scene)和模型(model)存儲到內存中,然后再調用系統的繪制API(如Windows程序員熟悉的GDI/GDI+),把這些中間產物繪制到屏幕。
駐留模式通過場景和模型緩存減少了對繪制API的調用頻次,將性能壓力轉移到場景和模型生成階段,即瀏覽器需要根據DOM上下文和BOM中的尺寸數據,“自行判斷”每一個元素的繪制結果。
Canvas:快速模式
Canvas采用了和DOM不同的快速模式(Immediate Mode),讓我們先來看看快速模式是如工作的:
與駐留模式相比,快速模式將場景和模型的生成從瀏覽器移交給了開發者。開發者在設計頁面時,就通過Canvas的JavaScript API定義了畫布內所有元素的繪制方式。瀏覽器只需要簡單的執行這些腳本即可,而不需要像渲染DOM一樣逐個處理子元素了。
在快速模式中,頁面的繪制性能得到了大幅提升。但開發者不僅需要指定什么需要畫,還要創建和維護一個模型。此外,開發者還需要管理好當前場景重繪時帶來的改變,以及響應用戶的點擊或輸入操作等。
上面介紹的兩種不同的模式直接造成了Dom和Canvas的性能差異。對于使用快速模式渲染的Canvas而言,瀏覽器的每次重繪都是基于代碼的,不存在能讓處理流程變慢的多層解析,所以它真的很快。除了快之外,Canvas的靈活性也大大超出DOM。我們可以通過代碼精確的控制如何、何時繪制出我們想要的效果。
在資源消耗上,DOM的駐留模式意味著場景中每增加一點東西就需要額外消耗一些內存,而Canvas并沒有這個問題。這個差異會隨著頁面元素的數量增多而愈加明顯。以B端的企業應用場景為例,表單那種數據量比較小的場景,不同渲染模式帶來的效果差異并不明顯;但在工業制造、金融財會等類Excel電子表格操作的場景下,單元格數量動輒便是上百萬(5萬行x 20列)甚至上億個,瀏覽器需要對表格所有單元格本身內容進行渲染,同時還涉及到豐富的數據處理,情況就完全不同了。
(Web頁面上的電子表格,包含1百萬個單元格)
在Canvas出現之前,在前端渲染表格時只能通過構建復雜的DOM來實現。這種方式下,瀏覽器的性能成為了Web應用瓶頸,讓很多開發者放棄了在瀏覽器上實現電子表格的想法。
在Canvas出現后,快速模式帶來的性能優勢無疑是一個巨大的亮點,大量、復雜的DOM渲染處理帶來的性能問題終于有了解決途徑。
回到電子表格的應用場景,業內已經出現了使用Canvas繪制畫布的表格組件,這類組件在渲染數據層時不僅無需重復創建和銷毀DOM元素,在畫布的繪制過程中,也比Dom元素渲染的限制更少。除了表格之外,Canvas也為數字孿生可視化大屏、頁面游戲等場景帶來了變革。
(數字孿生大屏,精確控制各種形狀、樣式)
總結一下,在渲染模式上,Canvas站在了DOM的對面,瀏覽器對其內容一無所知,一切渲染的權利回到了開發者的手上,這個改變帶來了顯著的性能優勢。此外,我們可以使用Canvas繪制種類更為豐富的UI元素,如線形、特殊圖形等,通過畫法邏輯,還可以實現更加精準的UI界面渲染,解決了瀏覽器差異造成的樣式誤差,讓更多應用場景可以順利遷移到Web平臺上來。
想必學習前端的同學們對Canvas 都不陌生,它是 HTML5 新增的“畫布”元素,可以使用JavaScript來繪制圖形。
Canvas元素是在HTML5中新增的標簽用于在網頁實時生成圖像,并且可以操作圖像內容,基本上它是一個可以用JavaScript操作的位圖(bitmap)。Canvas 由一個可繪制區域HTML代碼中的屬性定義決定高度和寬度。JavaScript代碼可以訪問該區域,通過一套完整的繪圖功能的API生成動態的圖形。
HTML5 在 2012 年已形成了穩定的版本,在此之前很長一段時間,開發者們繪制圖形選擇的方案更多是SVG來實現。SVG使用XML來定義圖形,就像使用HTML標簽一樣來控制元素的排布,SVG的本質就是一個DOM元素。當圖形內容太過豐富后,性能和內存上就會大打折扣。一旦涉及頻繁的圖片繪制場景,這個實現對于用戶的體驗將是毀滅性的。
渲染動畫的基本原理,無非是反復地擦除和重繪。為了動畫的流暢,留給開發者渲染一幀的時間,只有短短的 16.67ms。在這16.67ms中,我不僅需要處理一些繪制邏輯,計算每個對象的位置、狀態,還需要把它們都畫出來。如果消耗的時間稍稍多了一些,用戶就會感受到“卡頓”。所以,在編寫動畫時,開發者們無時無刻不擔憂著動畫的性能,唯恐渲染的耗時過長。
在現代 Web 開發中,開發者們更多的會借助 Canvas 提供的API去繪制上下文,可以自由繪制各種2D和3D圖形,創建富有視覺沖擊力的游戲場景和角色。Canvas的使用可以使得游戲能夠實現流暢的動態效果和用戶交互。無論是簡單的小游戲還是復雜的游戲引擎,Canvas 都被廣泛應用。
下面是做的一個簡單的對比試驗,可以很明顯感受到兩者的差距,分別使用SVG和Canvas繪制一個包含著100w個圓形的500*500的圖片,根據耗時計算對比,Canvas耗費的時間幾乎只有SVG的一半:
把動畫的一幀渲染出來,需要經過以下步驟:
之前提到過,在動畫設計和開發中,每幀只有16.67毫秒的時間用于渲染。這個數值是通過計算每秒60幀得出的平均每幀渲染時間。實際上,并不是所有設備都能夠穩定地達到60FPS。因此,為了確保在不同設備上實現一致性的動畫效果,最好將每幀的渲染時間控制在10毫秒以內。
大家都知道,通常情況下,渲染的開銷遠大于計算(相差3~4個量級)。除非使用了一些時間復雜度很高的算法,否則不需要過于深入優化計算環節。Canvas的渲染是在JavaScript引擎中執行繪制邏輯,通過構建畫布在內存中,并遍歷所有像素點的顏色,最終輸出到屏幕上。這種強大的功能可能會增加學習成本,但如今仍然有很多開發者選擇和接受Canvas,這要歸功于Canvas最大的優勢:渲染性能的出色表現。
當談論圖形渲染技術時,就不得不提到DOM駐留模式和Canvas快速模式。
DOM駐留模式
DOM駐留模式是一種基于文檔對象模型(DOM)的渲染技術。在DOM駐留模式下,頁面的布局和樣式是由DOM樹來掌管的。當頁面需要更新時,瀏覽器會重新計算布局和樣式并重新渲染。此模式非常靈活,特別適用于處理動態頁面交互和多樣化的樣式控制。然而,由于需要頻繁地重新計算布局和樣式,對于復雜的圖形渲染任務來說,性能開銷相對較高。
Canvas快速模式
Canvas快速模式利用HTML5的Canvas元素進行圖形渲染。在這種模式下,開發者可以使用Canvas提供的2D或3D繪圖API直接在畫布上繪制圖形。相比于DOM駐留模式,Canvas快速模式更加高效。它不關心頁面的布局和樣式,而是在需要時只重繪受影響的部分。這樣就避免了頻繁的布局和樣式計算,提高了渲染性能。
分層提高Canvas性能
開發者們通過分析大量實際場景,總結出一套可以進一步提升Canvas性能的策略,即對變化較少和變化較多的內容進行分開渲染。這種策略就是所謂的分層Canvas。它能夠顯著降低完全沒有必要的渲染性能開銷。分層渲染的思想被廣泛應用于各種圖形相關的領域,從古老的皮影戲、套色印刷術,到現代電影/游戲工業以及虛擬現實領域等等。而分層Canvas只是分層渲染思想在Canvas動畫上的一個基礎應用。
分層Canvas的核心理念是,動態頁面中的每種元素(層)對于渲染頻率的需求是不同的。對于許多金融會計等大數據行業的從業者來說,主要數據內容的變化頻率和幅度較大(他們通常面臨數據變動和頻繁計算),而背景表格樣式的變化頻率或幅度相對較?。ɑ静蛔?,或者變化緩慢,或者僅在特定時機變化)。因此,需要頻繁更新和重繪數據,但對于背景,可能只需要繪制一次,或者每隔200毫秒才重繪一次,而沒有必要每16毫秒就重繪一次。
視野之外的繪制
在許多情況下,Canvas 僅僅作為數據展示頁面的一部分,充當著一個“窗口”的角色。如果在每次數據更新時,都將所有數據完全繪制到 Canvas 上,很可能會出現大量內容繪制到Canvas 范圍之外的情況。雖然調用了繪制 API,但實際上并沒有產生任何效果。
因此,判斷對象是否位于 Canvas 范圍內需要進行額外的計算(例如,需要通過對游戲角色的全局模型矩陣求逆來得出對象的世界坐標,這是一項相對耗時的操作),同時也會增加代碼的復雜性。因此,關鍵是是否需要這樣做。
通過在本地代碼中進行測試,比較了在視野內和視野外分別繪制100萬個圓的耗時。在視野內繪制耗時8936ms,而在視野外繪制耗時2540ms??紤]到計算和繪制之間的耗時差距在3~4個數量級,因此通過計算來判斷并避免繪制視野外的內容是一種非常有效的方法。
之前探討了SVG和Canvas的繪制性能差異以及Canvas常見的優化方法。知道,對于使用快速模式渲染的Canvas來說,瀏覽器的每次重繪都是由代碼驅動的,無須進行多層解析,因此它的速度非常快。除了速度快之外,Canvas的靈活性也顯著優于DOM。可以通過代碼精確控制何時以及如何繪制出期望的效果。
在資源消耗方面,DOM的駐留模式意味著場景中的每一個新增元素都會導致額外的內存消耗,而Canvas則沒有這個問題。這種差異在頁面元素數量增多時尤為明顯。
在Canvas出現之前,前端渲染表格只能通過構建復雜的DOM來實現。然而,這種方式會導致瀏覽器性能成為Web應用的瓶頸,許多開發人員因此放棄了在瀏覽器上實現電子表格的想法。
Canvas出現后,其快速模式帶來的出色性能優勢成為了一大亮點,大量、復雜的DOM渲染處理所帶來的性能問題因此有了解決之道。
回到電子表格的應用場景,現在已經出現了使用Canvas繪制畫布的表格組件。這類組件在渲染數據層時無須重復創建和銷毀DOM元素,而且在畫布的繪制過程中受到的限制也比DOM元素渲染更少。其中,葡萄城公司的純前端表格控件——SpreadJS就用到了Canvas實現表格繪制,除了表格之外,Canvas也為數字孿生可視化大屏、頁面游戲等應用場景帶來了變革(如下圖所示)。
本文通過介紹Canvas的原理、Canvas的重要性、Canvas在計算與渲染上的作用、Canvas渲染性能優勢和Canvas的應用這五個部分,全面而系統地闡述了HTML Canvas在高性能渲染方面的相關知識和技巧。希望讀者通過閱讀本文能夠深入了解Canvas的基本原理和特性,認識到Canvas在Web開發中的重要性,并掌握Canvas在計算與渲染上的作用。
lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<html>
<body>
<canvas id='canvas'></canvas>
<div id="write"></div>
</body>
</html>
<script src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
<script>
//畫布
var c=document.getElementById('canvas');
var ctx=c.getContext('2d');
//畫布尺寸
var h=650;
var w=800;
c.width=w;
c.height=h;
//背景數量
var num=100;
//大紅尺寸
var gh=h/num;
var gw=w/num;
//小綠尺寸
var gamex=40;
var gamey=30;
//背景布置
function bk(){
for(var x=0;x<num;x++){
for(var y=0;y<num;y++){
ctx.fillStyle="green";
ctx.fillRect(10*(x-1)+x,10*(y-1)+y,gw,gh);
}
}
}
//定義小綠數量
var sts=new Array();
//定義小紅數量
var drs=new Array();
//小紅小綠范圍內相遇刪除對方
function dels(){
if(sts.length>0){
for(var i=0;i<sts.length;i++){
//范圍大小
var a=sts[i]['x']+20;
var b=sts[i]['x']-20;
var aa=sts[i]['y']+20;
var bb=sts[i]['y']-20;
$('#write').text(a+'---'+b);
for(var s=0;s<drs.length;s++){
//判斷是否在范圍內
if((drs[s]['x']<a && drs[s]['x']>b) && (drs[s]['y']<aa && drs[s]['y']>bb)){
//sts.splice(i,1);//刪除小綠
drs.splice(s,1);//刪除小紅
}
}
}
}
}
//小紅數量循環
function drss(){
var dr=new Array();
dr['x']=Math.floor((Math.random()*w)+1);
dr['y']=0;
//dr['y']=Math.floor((Math.random()*h)+1);
drs.push(dr);
if(drs.length>0){
for(var i=0;i<drs.length;i++){
if(drs[i]['y']>h){
drs.splice(i,1);
}else{
drs[i]['y']+=1;
}
ctx.fillStyle="orange";
ctx.fillRect(drs[i]['x'],drs[i]['y'],gw,gh);
}
}
}
//小綠數量循環
function st(){
ctx.fillStyle="black";
var st=new Array();
st['x']=10*(gamex-1)+gamex+10;
st['y']=10*(gamey-1)+gamey-10;
sts.push(st);
ctx.fillRect(10*(gamex-1)+gamex+10,10*(gamey-1)+gamey-10,gw,gh);
}
//小綠移動
function stsup(){
if(sts.length>0){
for(var i=0;i<sts.length;i++){
if(sts[i]['y']<0){
sts.splice(i,1);
}else{
sts[i]['y']-=1;
}
ctx.fillStyle="red";
ctx.fillRect(sts[i]['x'],sts[i]['y'],gw,gh);
}
}
}
//大紅位置移動
function game(gamex,gamey){
ctx.fillStyle="red";
//ctx.fillRect(10*(gamex-1)+gamex,10*(gamey-1)+gamey,gw,gh);
ctx.fillRect(10*(gamex-1)+gamex,10*(gamey-1)+gamey,20,20);
}
bk();
game(gamex,gamey);
//時間戳
setInterval(function(){
//按鍵判斷
document.onkeydown=function(event){
var e = event || window.event || arguments.callee.caller.arguments[0];
if(e.keyCode=='37'){
gamex=gamex-1;
}
else if(e.keyCode=='38'){
gamey=gamey-1;
}
else if(e.keyCode=='39'){
gamex=gamex+1;
}
else if(e.keyCode=='40'){
gamey=gamey+1;
}
if(e.keyCode=='32'){
st();
}
}
//清空畫布
c.width=w;
c.height=h;
bk();
game(gamex,gamey);
drss();
stsup();
dels();
},10);
</script>
*請認真填寫需求信息,我們會在24小時內與您取得聯系。