近年來，基于自渲染的跨平臺框架成為大前端開發的熱點之一。如何基于Web生態的WebGL和Wasm，將Mobile/PC平臺的跨端體驗以最小成本、最高性能的方式移植到Web平臺，成為跨平臺大前端開發中遇到的主要挑戰。
在WOT全球技術創新大會2023《大前端最佳實踐》專場中，騰訊客戶端工程師趙裕帶來了《跨平臺自渲染UI引擎在Web平臺的探索之旅》的主題分享，全面介紹了跨平臺、WebGL、Wasm等前沿技術的落地過程。
牛刀小試：從Mobile/PC到Web
將運行在PC平臺和Mobile平臺上的自渲染跨平臺UI引擎移植到Web端，是趙裕此次分享的重點內容。趙裕表示，跨端一定不只是瞄準跨Mobile(Android/iOS)、跨PC(Windows/MacOS/Linux)，而且還要跨Web，例如騰訊文檔，就是一個跨多端的應用，阿里的語雀文檔和飛書，也都有Web應用場景。
那么，如何才能更好地支持Web。第一個種思路就是用最原始的Web開發方式，用HTML+CSS+JS對項目進行重寫，但從成本角度考慮顯然不行。第二種思路就是利用WebAssembly。
雖然使用WebAssembly能夠更容易寫出高性能的代碼，但同樣會面臨著以下四個挑戰：
1）項目文件多，依賴關系相對復雜，通常基于CMake/GN/Bazel組織。
2）每個平臺存在一定數量的膠水代碼，如Java / OC / JS / TS。
3）存在對三方庫的依賴(.a / .so) ，需要構建對應的Wasm制品。
4）本身的場景與宿主有復雜的交互，不是一個功能單一的模塊。
解決挑戰的方法是利用Clang的交叉編譯。如果編譯成WebAssembly，則只需要用cmcmake+emmake工具進行包裝之后，再進行編譯即可。
趙裕表示，將所有C++編譯到另外一個目標平臺的二進制文件，歸根結底就是一個交叉編譯的過程。這個CMake交叉編譯文件把我們經常用到的Clang、Clang++工具改成了emc++和emcc去編譯。由于C++文件并不能直接轉譯成WebAssembly，因此借助LLVM的中間形式的字節碼，先通過Clang把它轉移成中間的表達形式，然后才能把這個中間的表達形式翻譯成asm.js。
除此之外，還可以利用Binaryen工具將asm.js翻譯成WebAssembly。不過，用WebAssembly編譯C++時，因為要有一個中轉過程，所以構建耗時比Native平臺要慢很多。目前，LLVM組織開發了一個能直接把C++轉譯成WebAssembly的功能，讓編譯效率變得更快。
在接下來的時間里，趙裕從Wasm線程的局限性與適配、C++與JavaScript的互操作、渲染與WebGL、圖片與文字(基于Skia)四個維度，詳細介紹了Web適配和渲染適配的詳細過程，分享了工作中的經驗。
趙裕認為，從Mobile/PC到Web，一要基于強大的LLVM實現交叉構建；二要在跨平臺的設計中，快速適配線程、交互、WebGL等限制；三要解決Web平臺限制為后續留下的包大小、性能、擴展性等隱患。
深度優化：從可用到好用
判斷跨平臺自渲染UI引擎在Web平臺是否好用，主要有三個依據：
首先要具備更快的啟動時間，尤其是加載+顯示第一幀的時間要足夠快；其次要具備穩定流暢的幀率；最后CPU/內存的占用率要做到更低。
趙裕表示，從可用到好用，必須從各個維度進行深度優化。在接下來的時間里，趙裕詳細介紹了包大小的優化思路。
首先是從Skia到TGFX。Skia是一個2D渲染引擎，底層為OpenGL，并提供了更上層的接口。Skia擁有功能完備、質量穩定、生態成熟三大特點，但也會導致Web平臺的包體積過大。
作為一個開源的產品，TGFX是一個動畫庫的底層組件，它更加專注于硬件渲染能力，并兼容軟繪。能夠讓用戶充分利用平臺能力精簡庫增量，充分復用現代硬件的高并發等特性。與Skia相比，TGFX更加安全，環境管理更加便捷，內部團隊的溝通協作也更加方便。
兩者的不同點在于，Skia用了freetype、ICU、Harfbuzz，TGFX則用了Core Graphics（在Apple平臺），這是蘋果自己的API，可以用來畫文字。
其次，在圖片解碼方面，如果利用Skia解碼一張PNG圖片，就要先把PNG庫導入，再用C++進行解碼，這種方式將會占用包大小。那么，有沒有一種能做到相同功能，但是又沒那么占用包大小的方式呢？答案是，可以使用Web自帶的解碼能力進行實現。實際上，在Android/iOS等平臺上可以使用類似的方式，復用原生平臺的圖片編解碼能力，裁剪包大小。
最后，在文字渲染方面，往往面臨著特殊樣式、特殊字符、特殊語言、縮放下的像素級對齊、系統字體與回退兜底和多種編碼等挑戰，在進行自渲染時，一般可以利用文字渲染的三兄弟： ICU+Harfbuzz+Freetype。
趙裕表示，把一段文字直接渲染成UI，可以利用Freetype+Harfbuzz。其中，Harfbuzz是加載之后計算文字在某一個特定大小下的寬高，把它渲染出來之后，就會知道每一個文字渲染在哪個位置。因此，把每個文字渲染的位置用Harfbuzz計算出來，Freetype就會根據這個字體里面的矢量路徑將光柵化變成位圖，然后得出渲染結果。
落地展望：從技術到業務
自渲染技術如何更好地推動業務發展，趙裕也分享了自己的一些看法。
趙裕表示，做好自渲染平臺之后，之前Hippy想要在Web平臺渲染，需要寫一個Web Render。但是，有了WebAssembly能力之后，我們可以去對接Hippy底層，把DomTree直接渲染到Web Canvas上。
此外，趙裕還演示了如何在一個嵌入式系統落地這套框架。
通過WebAssembly的適配工作，讓基于我們框架開發的業務不僅能夠在移動端運行，在PC端運行，也能在Web上運行，甚至能讓這個圖表在一塊嵌入式設備運行。這樣，就可以快速部署到各式各樣的場景（從一塊嵌入式終端設備到各大場景的瀏覽器）中。
“我們雖然在渲染這塊做了一些優化，但是總體來說還有很多Web的能力需要探索和優化，例如動態加載、多線程等。” 演講最后，趙裕強調，在Web的探索上，正如萬里長征，我們只邁出了一小步。
本文整理自騰訊客戶端工程師趙裕在WOT2023大會上的主題分享，更多精彩內容及現場PPT，請關注《51CTO技術棧》公眾號，發消息【WOT2023PPT】即可直接領取。
