本文內(nèi)容大綱：?
1、輕量級圖形渲染引擎與應(yīng)用?
2、渲染引擎演進與優(yōu)化之路?
3、渲染引擎未來的發(fā)展方向

GCanvas 的定位是遵循 w3c 標(biāo)準(zhǔn)的跨平臺的輕量級圖形渲染引擎。有清晰的定位和目標(biāo)，并且緊貼現(xiàn)有的業(yè)務(wù)，為業(yè)務(wù)提供豐富表現(xiàn)形式。

GCanvas 發(fā)展

GCanvas 引擎從早期的 H5 性能加速，到 Weex 業(yè)務(wù)落地，從小游戲的業(yè)務(wù)探索，到服務(wù)端渲染，再到小程序。經(jīng)過幾個階段的發(fā)展后日漸成熟。

淘系無線架構(gòu)的不斷升級迭代，GCanvas 隨之保持著更新迭代的步調(diào)，在多個業(yè)務(wù)場景中使用，了解下一些應(yīng)用案例。

應(yīng)用案例

GCanvas 的目標(biāo)人群是業(yè)務(wù)開發(fā)者，滿足業(yè)務(wù)的功能需求，對開發(fā)者也非常友好，尤其是前端開發(fā)者。熟悉 H5 Canvas 的同學(xué)，很容易上手，無任何學(xué)習(xí)成本。

Weex
2017年雙十一預(yù)熱會場，GCanvas 與魔影合作的版頭動畫

天貓未來店
天貓未來店的智能電子標(biāo)簽，基于 GCanvas JSBinding 的智能電子標(biāo)簽

小游戲
野生小伙伴，基于GCanvas小游戲應(yīng)用

Sketch Render
Demo+ 中的 Sketch Render ，基于 GCanvas 實現(xiàn)的服務(wù)端渲染 Sketch 文件

支付寶小程序/淘寶商家應(yīng)用Canvas
基于支付寶小程序/淘系商家應(yīng)用同層渲染組件
支付寶小程序諸葛找房 - 2D

淘寶商家應(yīng)用AR試妝 - WebGL

架構(gòu)演進與優(yōu)化

以業(yè)務(wù)先贏的基本原則，保證業(yè)務(wù)的前提下，架構(gòu)容器和升級變化過程中，GCanvas 引擎也經(jīng)歷了演進和升級優(yōu)化。

2017年的架構(gòu)
以插件為主的實現(xiàn)，僅支持移動端

最新架構(gòu)
提供標(biāo)準(zhǔn)接口，鏈路升級，API升級，不僅支持移動端還支持服務(wù)端

架構(gòu)變化主要有以下幾個方面：

• 適配支持更多的 JS 框架和庫
• JS 到 Native 調(diào)用通路，從模塊路由反射升級到 JSBinding
• 渲染 API 支持 Metal
• 增加 MacOS 和 Linux 平臺支持

? 內(nèi)功修煉

在快速迭代過重中，保持修煉內(nèi)功。為保證高性能這個根本，在鏈路、內(nèi)核以及底層圖形 API 等方面也都做了不少優(yōu)化與升級。

JS 到 Native 鏈路優(yōu)化

從 Weex 調(diào)用鏈路到 JSBinding，Weex 容器的 JS 到 Native 的通路采用模塊路由和反射的調(diào)用方式調(diào)用具體的模塊和組件。在 UI 和一些非高頻的場景完全能滿足需求。

但是對于連續(xù)操作、連續(xù)動畫等高頻的 JS 到 Native 通訊的場景，鏈路上的耗時非常大，導(dǎo)致卡頓產(chǎn)生。這也是為什會 BindingX 和 GCanvas 的 JSBinding 的出現(xiàn)。

BindingX是另一種解決頻發(fā)通訊消耗的方案，有興趣的可以看下BindingX。

GCanvas 的 JSBinding 的實現(xiàn)：通過鏈路調(diào)用的改造，整體幀率平均提升10幀左右。Android 和 iOS 的 JSBinding 實現(xiàn)方案類似。

以 iOS 舉例說明：iOS 嘗試使用 JSExport 和全局方法，兩種 JSBinding 方案。

• 第一種方案，使用 JSExport 和 JSExportAS

• 第二種方案，使用 C Export 將方法和屬性用 JSStaticFunction 和 JSStaticValue 進行綁定

兩種實現(xiàn)方案，經(jīng)過測試對比第二種方案在性能更好。原因在于靜態(tài) JS 方法是通過方法名到 Native 函數(shù)的直接映射，而 JSExport 的方案則需要類型檢查，協(xié)議校驗，再調(diào)用 Native 方法中間經(jīng)過額外的處理。

簡單的耗時測試數(shù)據(jù)對比：

JS 到 Native 數(shù)據(jù)傳輸
方法調(diào)用與屬性訪問之外，參數(shù)數(shù)據(jù)的傳輸也影響每幀耗時，尤其是在 WebGL 的場景，通常有很大頂 點數(shù)據(jù)需要處理，有幾萬-幾十萬字節(jié)，甚至更多。JS 到 Native 的大數(shù)據(jù)傳輸避免內(nèi)存拷貝。

JS 與 Native 對象生命周期
JSBinding 的對象生命周期管理，JS 對象與 Native 對象一一對應(yīng)，在 JS 對象創(chuàng)建觸發(fā) JSObjectInitializeCallback 回調(diào)，創(chuàng)建 Native 對象，并將 JS 與 Native 建立關(guān)聯(lián)。JS 的 GC 回收對象觸發(fā) JSObjectFinalizeCallback 的回調(diào)中去釋放對應(yīng) Native 對象。

幀率優(yōu)化
除了調(diào)用鏈路對幀率的提升，單幀繪制的 CPU 和 GPU 耗時相關(guān)的優(yōu)化點

• 頂點數(shù)據(jù)計算，頂點數(shù)據(jù)合并提交
• 優(yōu)化緩存策略，優(yōu)化文字相關(guān)紋理的緩存
• 增加狀態(tài)管理，減少 GPU 提交數(shù)據(jù)和頻次
• 優(yōu)化多邊形填充效率
• 抗鋸齒等耗時特性可選

w3c 標(biāo)準(zhǔn)完善

• 支持陰影
• 支持虛線
• 支持多Clip區(qū)域嵌套
• 支持Winding Rule支持

擴展能力，擴展一些非標(biāo)接口支持 Sketch 渲染

• 陰影的擴散
• 路徑的圖案填充
• 路徑的高斯模糊
• 路徑的內(nèi)描邊和外描邊

底層圖形API升級
在 iOS12 之后，蘋果將 OpenGL ES API 設(shè)為廢棄，在已支持的設(shè)備上 OpenGL ES 的調(diào)用都已映射到 Metal 相應(yīng)的后端實現(xiàn)，Metal 替換 OpenGL 勢在必行。GCanvas 也已投入開發(fā) Metal，可選擇使用 Metal 作為渲染的后端。已完成了 2D 的絕大部分能力。

選擇 Metal 會帶來以下方面的收益：

• 內(nèi)存數(shù)據(jù)使用更高效，內(nèi)存數(shù)據(jù)可共享，
• 盡可能的榨取更多 GPU 性能
• 擺脫 OpenGL 的狀態(tài)機，更友好的面向?qū)ο缶幊?/li>
• 蘋果后續(xù)的持續(xù)投入和更新
• 豐富的調(diào)試工具，能精確到每個頂點數(shù)據(jù)和每個素點顏色
• 便捷調(diào)試這著色器語言(Metal Shader Language)

在內(nèi)核升級優(yōu)化的過程中，也有很多同學(xué)積極參與其中來在此表示感謝。

穩(wěn)定性

增加了 API 的自動化測試以及 CI 建立保障穩(wěn)定性。

未來的方向

• GCanvas 開源社區(qū)加大投入增加社區(qū)影響力, 請大家積極關(guān)注并star
• 更多紋理壓縮格式的支持
• Vulkan 的持續(xù)演進
• 更多平臺的支持，IoT 設(shè)備上應(yīng)用
• 與云端渲染的融合，提供 Fass 能力
• WebGPU 以及 GPU 計算方向探索
• WebAssembly 的應(yīng)用

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的5分钟带你看懂 GCanvas渲染引擎的演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。