近年来，基于自渲染的跨平台框架成为大前端开发的热点之一。如何基于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】即可直接领取。
