HTML界的“蘇炳添”——詳解Canvas優越效能和實際應用

葡萄城技術團隊發表於2021-08-24

Google Docs宣佈將會把HTML遷移到基於Canvas渲染,這一訊息的出現再次把幾年前隨HTML5誕生的標籤重新推到了人們視線之中。Canvas在剛推出時主打的優勢就是更快的渲染速度,堪稱HTML屆的“蘇炳添”,重新整理了人們對Web頁面元素繪製速度的印象。但Canvas的優勢僅限於此嗎?

(蘇炳添,亞洲百米第一人)

HTML繪圖屆的前輩:SVG

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)

而Canvas與DOM的區別則是Canvas的本質就是一張點陣圖,類似img標籤,或者一個div加了一張背景圖(background-image)。所以,DOM那種向量圖在渲染中存在的問題換到Canvas身上就完全不同了。在渲染Canvas時,瀏覽器只需要在JavaScript引擎中執行繪製邏輯,在記憶體中構建出畫布,然後遍歷整個畫布裡所有畫素點的顏色,直接輸出到螢幕就可以了。不管Canvas裡面的元素有多少個,瀏覽器在渲染階段也僅需要處理一張畫布。

然而這樣更加強大的功能,不可避免的讓使用canvas渲染有很高的門檻。Google Docs在構建Canvas的過程中重新定義了往常已經被人們所熟悉的內容,例如精確定位、文字選擇、拼寫檢查、重畫調優等。為什麼更多開發者還是選擇了接納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的應用優點

上面介紹的兩種不同的模式直接造成了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的Wiki介紹

·       Canvas社群

·       基於Canvas表格元件 SpreadJS

轉載請註明出處:葡萄城官網,葡萄城為開發者提供專業的開發工具、解決方案和服務,賦能開發者。

相關文章