本文內容大綱：?
1、輕量級圖形渲染引擎與應用?
2、渲染引擎演進與優化之路?
3、渲染引擎未來的發展方向

GCanvas 的定位是遵循 w3c 標準的跨平臺的輕量級圖形渲染引擎。有清晰的定位和目標，并且緊貼現有的業務，為業務提供豐富表現形式。

GCanvas 發展

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

淘系無線架構的不斷升級迭代，GCanvas 隨之保持著更新迭代的步調，在多個業務場景中使用，了解下一些應用案例。

應用案例

GCanvas 的目標人群是業務開發者，滿足業務的功能需求，對開發者也非常友好，尤其是前端開發者。熟悉 H5 Canvas 的同學，很容易上手，無任何學習成本。

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

天貓未來店
天貓未來店的智能電子標簽，基于 GCanvas JSBinding 的智能電子標簽

小游戲
野生小伙伴，基于GCanvas小游戲應用

Sketch Render
Demo+ 中的 Sketch Render ，基于 GCanvas 實現的服務端渲染 Sketch 文件

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

淘寶商家應用AR試妝 - WebGL

架構演進與優化

以業務先贏的基本原則，保證業務的前提下，架構容器和升級變化過程中，GCanvas 引擎也經歷了演進和升級優化。

2017年的架構
以插件為主的實現，僅支持移動端

最新架構
提供標準接口，鏈路升級，API升級，不僅支持移動端還支持服務端

架構變化主要有以下幾個方面：

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

? 內功修煉

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

JS 到 Native 鏈路優化

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

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

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

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

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

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

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

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

簡單的耗時測試數據對比：

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

JS 與 Native 對象生命周期
JSBinding 的對象生命周期管理，JS 對象與 Native 對象一一對應，在 JS 對象創建觸發 JSObjectInitializeCallback 回調，創建 Native 對象，并將 JS 與 Native 建立關聯。JS 的 GC 回收對象觸發 JSObjectFinalizeCallback 的回調中去釋放對應 Native 對象。

幀率優化
除了調用鏈路對幀率的提升，單幀繪制的 CPU 和 GPU 耗時相關的優化點

• 頂點數據計算，頂點數據合并提交
• 優化緩存策略，優化文字相關紋理的緩存
• 增加狀態管理，減少 GPU 提交數據和頻次
• 優化多邊形填充效率
• 抗鋸齒等耗時特性可選

w3c 標準完善

• 支持陰影
• 支持虛線
• 支持多Clip區域嵌套
• 支持Winding Rule支持

擴展能力，擴展一些非標接口支持 Sketch 渲染

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

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

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

• 內存數據使用更高效，內存數據可共享，
• 盡可能的榨取更多 GPU 性能
• 擺脫 OpenGL 的狀態機，更友好的面向對象編程
• 蘋果后續的持續投入和更新
• 豐富的調試工具，能精確到每個頂點數據和每個素點顏色
• 便捷調試這著色器語言(Metal Shader Language)

在內核升級優化的過程中，也有很多同學積極參與其中來在此表示感謝。

穩定性

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

未來的方向

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

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。