RenderingNG | Chromium | Chrome for Developers

與其他瀏覽器轉譯引擎的比較

Gecko 和 WebKit 也實作了這些網誌文章中所述的大部分相同架構功能，在某些情況下甚至比 Chromium 更早加入這些功能。

任何瀏覽器的速度和可靠性提升，都是值得慶祝的喜訊，也能帶來實際影響。最終目標是提升所有瀏覽器的基準，讓開發人員能信賴這些基準。

成功金字塔

我的理念是，要想成功，就必須先達成可靠性，然後是可擴充的效能，最後是可擴充性。

就像現實生活中的金字塔一樣，每個層級都為上層提供必要的穩固基礎。

如要提供豐富且複雜的使用者體驗，我們首先需要的是穩固的平台。核心功能和基礎架構必須正常運作，並持續運作。同樣重要的是，這些功能必須能良好組合，且不會出現奇怪的邊緣情況行為或錯誤。

因此，穩定性是 RenderingNG 最重要的部分。可靠性則是良好測試、優質的意見回饋循環、指標和軟體設計模式的結果。

為了讓大家瞭解我認為可靠性有多重要，我們在過去八年大部分的時間都專注於這個部分。首先，我們深入瞭解系統的運作方式，從錯誤報告中找出弱點並加以修正，啟動全面測試，並瞭解網站的效能需求和 Chromium 效能的限制。接著，我們仔細地逐步設計並推出主要設計模式和資料結構。只有在那個時候，我們才準備好為回應式設計、可擴充性和算繪自訂化，新增真正新一代的基礎元素。

這並非表示 Chromium 在那段期間沒有任何改善。事實上，反之亦然！在那段期間，我們逐步重構並推出各項改善措施，可靠性和效能持續提升。

測試和指標

過去 8 年來，我們新增了數萬個單元、效能和整合測試。此外，我們也開發了全面的指標，可評估 Chromium 在本機測試、效能基準測試，以及實際網站上實際使用者和裝置的運算行為。

不過，無論 RenderingNG (或其他瀏覽器的轉譯引擎) 有多強大，如果瀏覽器之間存在許多錯誤或行為差異，開發人員仍無法輕鬆為網頁進行開發。為解決這個問題，我們也會盡可能使用網頁平台測試。每項測試都會驗證網站平台的使用模式，所有瀏覽器都應以通過測試為目標。我們也會密切監控指標，隨著時間的推移通過更多測試，並提高核心相容性。

Web Platform 測試是一項合作計畫。舉例來說，Chromium 工程師只新增了 CSS 功能的 10% 總 WPT 測試；其他瀏覽器供應商、獨立貢獻者和規格作者則負責其餘的部分。我們需要集結眾人之力，才能打造可互通的網路！

良好的軟體設計模式

如果程式碼易於理解，並以盡可能減少錯誤的設計方式進行編寫，就能更輕鬆地提供可靠的優質軟體。我們會在後續的網誌文章中，進一步說明 RenderingNG 的軟體設計。

可調整的效能

在速度、記憶體和電力使用量等方面，達成出色的效能，是 RenderingNG 的次要重點。我們希望與所有網站的互動都能順暢且即時回應，但不會犧牲裝置的穩定性。

但我們不只想要效能，我們想要的是可擴充的效能，也就是在低階和高階機器上，以及跨作業系統平台上，都能穩定發揮效能的架構。我稱之為「向上調整」(利用硬體裝置可達成的所有功能) 和「向下調整」(盡可能提高效率，並在必要時降低系統需求)。

為達到這個目標，我們需要盡可能善用快取、效能隔離和 GPU 硬體加速功能。我們來逐一探討。為了讓這項概念更具體，我們來思考一下，每個因素如何影響網頁上一個非常重要的互動：捲動。

在動態互動式 UI 平台 (例如網頁) 中，快取是大幅改善效能的唯一重要方法。瀏覽器中最常見的快取類型是 HTTP 快取，但轉譯也有許多快取。捲動畫面時最重要的快取是快取的 GPU 材質和顯示清單，可讓捲動畫面時速度極快，同時盡量減少電池耗電量，並在各種裝置上正常運作。

快取可延長電池續航力，並提高捲動動畫的幀率，但更重要的是，它可解除主執行緒的效能隔離。

在現代化的電腦上，您不必擔心背景應用程式會拖慢您正在使用的應用程式。這是因為預先執行多工作，這也是一種效能隔離形式：確保獨立工作不會互相拖慢。

在網路上，捲動畫面是最佳的效能隔離範例。即使網站的 JavaScript 速度緩慢，捲動畫面也能非常順暢，因為這項功能會在不同的執行緒上執行，不必依賴 JavaScript 和版面配置執行緒。我們在 RenderingNG 上投入大量心力，確保每個可能的捲動動作都會以多執行緒執行，並透過快取功能，將顯示清單的複雜度提升至更高層級。例如代表固定和固定位置元素的程式碼、被動事件監聽器，以及高品質文字轉譯。

GPU 加速

GPU 可大幅加快產生像素及繪製至螢幕的速度。在許多情況下，每個像素都能與其他像素並行繪製，因此速度會大幅提升。RenderingNG 的關鍵元件是 GPU 光柵和隨處繪製。這項功能會在所有平台和裝置上使用 GPU，以便加速轉譯及動畫化網頁內容。這點對於低階或高階裝置尤其重要，因為這類裝置的 GPU 通常比裝置的其他部分更強大。

可擴充性：適合工作需求的工具

在確保穩定性和可擴充的效能後，我們現在可以利用多項工具，協助開發人員擴充 HTML、CSS 和 Canvas 內建的部分，且不會犧牲任何辛苦獲得的效能和穩定性。

其中包括內建的 API 和 JavaScript 公開 API，可用於回應式設計、漸進式算繪、流暢度和回應速度，以及多執行緒算繪等進階用途。

以下是 Chromium 大力提倡的開放式網路 API，這些 API 原本被視為不可能實現，但現在則得益於 RenderingNG 而得以實現。

這些功能都是根據開放規格開發，並與開放網路合作夥伴 (其他瀏覽器的工程師、專家和網頁開發人員) 合作開發。在後續的網誌文章中，我們將深入探討這些功能，並說明 RenderingNG 如何實現這些功能。

content-visibility ：讓網站輕鬆避免為畫面外內容進行轉譯作業，並快取目前未顯示的單頁應用程式檢視畫面的轉譯作業。

OffscreenCanvas ：可讓畫布轉譯 (包括 2D 畫布 API 和 WebGL) 在其專屬執行緒上執行，以確保可靠的優異效能。這個專案也是網頁的另一個重大里程碑，因為這是第一個允許 JavaScript (或 WebAssembly) 從多個執行緒轉譯單一網頁文件的網頁 API。

容器查詢：允許單一元件以回應式方式自行版面配置，解除整個即插即用元件的封鎖 (目前為實驗性質的實作)。

來源隔離：允許網站選擇在 iframe 之間進行更多成效隔離。

主執行緒外繪圖工作項：開發人員可透過在轉譯器執行緒上執行的程式碼，擴充元素的繪圖方式。

除了明確的網頁 API 之外，RenderingNG 也讓我們能夠提供多項對所有網站都有益的「自動功能」：

網站隔離：將跨來源 iframe 放入不同的 CPU 程序，以提升安全性和效能隔離。

Vulkan 、 D3D12 和 Metal ：利用較低層級 API 的優勢，比 OpenGL 更有效率地使用 GPU。

更多合成的動畫： SVG 、背景顏色。

RenderingNG 解除封鎖的其他即將推出的功能，包括：

捲動連結動畫。

隱藏但可搜尋及存取的 DOM 。

共用元素轉場效果。

自訂版面配置。

主執行緒外合成；分離執行緒和合成。

組成 RenderingNG 的主要專案

以下是 RenderingNG 中的主要專案清單。

CompositeAfterPaint

CompositeAfterPaint 會將合成作業與樣式、版面配置和繪製作業分開，讓可靠性和可預測的效能大幅提升，並提高傳輸量，同時減少記憶體用量，而不犧牲效能。

OOP-D

離線顯示合成器。顯示合成是與作業系統合成器相同類型的活動。這表示在 Viz 程序中執行，而非在網頁的轉譯程序或瀏覽器 UI 程序中執行。

OOP-R

離線處理算繪。轉成點陣圖會將顯示清單轉換為像素。這表示在 Viz 程序中執行，而非在網頁的轉譯程序中執行。

SkiaRenderer

新的顯示器合成器實作項目，可支援在各種不同的基礎 GPU API 上執行，例如 Vulkan、D3D12 或 Metal。

以多執行緒和加速方式轉譯無框畫

這是讓 OffscreenCanvas 成為可能的專案。

除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《 Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。

上次更新時間：2021-06-22 (世界標準時間)。

[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2021-06-22 (世界標準時間)。"],[],[],null,[]]