近年來，基于自渲染的跨平臺框架成為大前端開發(fā)的熱點之一。如何基于Web生態(tài)的WebGL和Wasm，將Mobile/PC平臺的跨端體驗以最小成本、最高性能的方式移植到Web平臺，成為跨平臺大前端開發(fā)中遇到的主要挑戰(zhàn)。

在WOT全球技術(shù)創(chuàng)新大會2023《大前端最佳實踐》專場中，騰訊客戶端工程師趙裕帶來了《跨平臺自渲染UI引擎在Web平臺的探索之旅》的主題分享，全面介紹了跨平臺、WebGL、Wasm等前沿技術(shù)的落地過程。

牛刀小試：從Mobile/PC到Web

將運行在PC平臺和Mobile平臺上的自渲染跨平臺UI引擎移植到Web端，是趙裕此次分享的重點內(nèi)容。趙裕表示，跨端一定不只是瞄準跨Mobile(Android/iOS)、跨PC(Windows/MacOS/Linux)，而且還要跨Web，例如騰訊文檔，就是一個跨多端的應(yīng)用，阿里的語雀文檔和飛書，也都有Web應(yīng)用場景。

那么，如何才能更好地支持Web。第一個種思路就是用最原始的Web開發(fā)方式，用HTML+CSS+JS對項目進行重寫，但從成本角度考慮顯然不行。第二種思路就是利用WebAssembly。

雖然使用WebAssembly能夠更容易寫出高性能的代碼，但同樣會面臨著以下四個挑戰(zhàn)：

1）項目文件多，依賴關(guān)系相對復雜，通常基于CMake/GN/Bazel組織。

2）每個平臺存在一定數(shù)量的膠水代碼，如Java / OC / JS / TS。

3）存在對三方庫的依賴(.a / .so) ，需要構(gòu)建對應(yīng)的Wasm制品。

4）本身的場景與宿主有復雜的交互，不是一個功能單一的模塊。

解決挑戰(zhàn)的方法是利用Clang的交叉編譯。如果編譯成WebAssembly，則只需要用cmcmake+emmake工具進行包裝之后，再進行編譯即可。

趙裕表示，將所有C++編譯到另外一個目標平臺的二進制文件，歸根結(jié)底就是一個交叉編譯的過程。這個CMake交叉編譯文件把我們經(jīng)常用到的Clang、Clang++工具改成了emc++和emcc去編譯。由于C++文件并不能直接轉(zhuǎn)譯成WebAssembly，因此借助LLVM的中間形式的字節(jié)碼，先通過Clang把它轉(zhuǎn)移成中間的表達形式，然后才能把這個中間的表達形式翻譯成asm.js。

除此之外，還可以利用Binaryen工具將asm.js翻譯成WebAssembly。不過，用WebAssembly編譯C++時，因為要有一個中轉(zhuǎn)過程，所以構(gòu)建耗時比Native平臺要慢很多。目前，LLVM組織開發(fā)了一個能直接把C++轉(zhuǎn)譯成WebAssembly的功能，讓編譯效率變得更快。

在接下來的時間里，趙裕從Wasm線程的局限性與適配、C++與JavaScript的互操作、渲染與WebGL、圖片與文字(基于Skia)四個維度，詳細介紹了Web適配和渲染適配的詳細過程，分享了工作中的經(jīng)驗。

趙裕認為，從Mobile/PC到Web，一要基于強大的LLVM實現(xiàn)交叉構(gòu)建；二要在跨平臺的設(shè)計中，快速適配線程、交互、WebGL等限制；三要解決Web平臺限制為后續(xù)留下的包大小、性能、擴展性等隱患。

深度優(yōu)化：從可用到好用

判斷跨平臺自渲染UI引擎在Web平臺是否好用，主要有三個依據(jù)：

首先要具備更快的啟動時間，尤其是加載+顯示第一幀的時間要足夠快；其次要具備穩(wěn)定流暢的幀率；最后CPU/內(nèi)存的占用率要做到更低。

趙裕表示，從可用到好用，必須從各個維度進行深度優(yōu)化。在接下來的時間里，趙裕詳細介紹了包大小的優(yōu)化思路。

首先是從Skia到TGFX。Skia是一個2D渲染引擎，底層為OpenGL，并提供了更上層的接口。Skia擁有功能完備、質(zhì)量穩(wěn)定、生態(tài)成熟三大特點，但也會導致Web平臺的包體積過大。

作為一個開源的產(chǎn)品，TGFX是一個動畫庫的底層組件，它更加專注于硬件渲染能力，并兼容軟繪。能夠讓用戶充分利用平臺能力精簡庫增量，充分復用現(xiàn)代硬件的高并發(fā)等特性。與Skia相比，TGFX更加安全，環(huán)境管理更加便捷，內(nèi)部團隊的溝通協(xié)作也更加方便。

兩者的不同點在于，Skia用了freetype、ICU、Harfbuzz，TGFX則用了Core Graphics（在Apple平臺），這是蘋果自己的API，可以用來畫文字。

其次，在圖片解碼方面，如果利用Skia解碼一張PNG圖片，就要先把PNG庫導入，再用C++進行解碼，這種方式將會占用包大小。那么，有沒有一種能做到相同功能，但是又沒那么占用包大小的方式呢？答案是，可以使用Web自帶的解碼能力進行實現(xiàn)。實際上，在Android/iOS等平臺上可以使用類似的方式，復用原生平臺的圖片編解碼能力，裁剪包大小。

最后，在文字渲染方面，往往面臨著特殊樣式、特殊字符、特殊語言、縮放下的像素級對齊、系統(tǒng)字體與回退兜底和多種編碼等挑戰(zhàn)，在進行自渲染時，一般可以利用文字渲染的三兄弟： ICU+Harfbuzz+Freetype。

趙裕表示，把一段文字直接渲染成UI，可以利用Freetype+Harfbuzz。其中，Harfbuzz是加載之后計算文字在某一個特定大小下的寬高，把它渲染出來之后，就會知道每一個文字渲染在哪個位置。因此，把每個文字渲染的位置用Harfbuzz計算出來，Freetype就會根據(jù)這個字體里面的矢量路徑將光柵化變成位圖，然后得出渲染結(jié)果。

落地展望：從技術(shù)到業(yè)務(wù)

自渲染技術(shù)如何更好地推動業(yè)務(wù)發(fā)展，趙裕也分享了自己的一些看法。

趙裕表示，做好自渲染平臺之后，之前Hippy想要在Web平臺渲染，需要寫一個Web Render。但是，有了WebAssembly能力之后，我們可以去對接Hippy底層，把DomTree直接渲染到Web Canvas上。

此外，趙裕還演示了如何在一個嵌入式系統(tǒng)落地這套框架。

通過WebAssembly的適配工作，讓基于我們框架開發(fā)的業(yè)務(wù)不僅能夠在移動端運行，在PC端運行，也能在Web上運行，甚至能讓這個圖表在一塊嵌入式設(shè)備運行。這樣，就可以快速部署到各式各樣的場景（從一塊嵌入式終端設(shè)備到各大場景的瀏覽器）中。

“我們雖然在渲染這塊做了一些優(yōu)化，但是總體來說還有很多Web的能力需要探索和優(yōu)化，例如動態(tài)加載、多線程等。” 演講最后，趙裕強調(diào)，在Web的探索上，正如萬里長征，我們只邁出了一小步。

本文整理自騰訊客戶端工程師趙裕在WOT2023大會上的主題分享，更多精彩內(nèi)容及現(xiàn)場PPT，請關(guān)注《51CTO技術(shù)?！饭娞枺l(fā)消息【W(wǎng)OT2023PPT】即可直接領(lǐng)取。