跨游戏引擎的H5渲染解决方案（腾讯）

本文是腾讯的一篇H5 跨引擎解决方案的精炼。

介绍

本文通过实现基于精简版的HTML5（HyperText Mark Language 5）来屏蔽不同引擎，平台底层的差异。 好处： 采用H5的开发方式，可以将开发和运营分离，运营部门自主开发的运营活动不依赖于游戏发版本的节奏。

如需要开发游戏周边系统会遇到如下4个问题：

1 每个游戏使用不同引擎时，周边系统是否可以不考虑引擎差异

2 每个游戏都有自己的开发版本的节奏。运营开发是否可以不跟随。

3 不同游戏， 不同引擎 不同平台 开发方式是否可以保持一致

4 这套开发方式 是否可以和游戏引擎开发的系统在交互 操作 性能保持一致。

一个想法是在游戏内嵌入 WebView， 然而这种方式对于 4 这种方案不会支持。为了解决 4 这种方案，腾讯推出了新的解决方案。

H5 ES 标准提出（HTML 5 Embeded System）

精简的H5有如下能力

HTML CSS JS 代码的解析能力

核心标签的支持， 包括DIv, Script, Style, Img, Text.

核心DOM API 支持，事件机制

背景 边框 图片（GIF动图） 文本渲染

FlexBox

CSS Animation, Transform

视频播放，直播

WebSocket XMLHttpRequest 支持Wss Https。

为了实现上面提到的基元操作，可以考虑吧对应的操作抽象为一系列的接口，宿主程序实现对应的接口就可以完成对于的操作。有如下2中抽象模式

完全自己渲染

抽象为接口，要求宿主对应的实现

如果是完全自己渲染，则1需要考虑不同平台和图形系统，做法和游戏引擎自身实现的跨平台抽象是一致的。一般做法是抽象为RHI，RHI分装了 OpenGL Vulkan DirectX 等图形API，通过使用这样的抽象的APi来实现上层的UI渲染，吧UI渲染到RenderTarget，在不同引擎渲染RenderTarget，这样就可以实现不同引擎内跨平台的渲染一致的UI。

这样的作法有几个问题：

问题一： RHI的封装

要实现RHI，其实有很多问题。例如如何实现RHI， RHI需要多大Code Size， 如何保证RHI封装不会和其他的RHI引擎冲突。

首先我们使用的是GitHub上的一个开源的bgfx，它实现了对所有API封装，非常聚焦。

bgfx总共2.2MB代码段同时提供了 bimg和bx2个库，用于图形解码和函数基础库，这正好做UI必备。

修改bgfx的创建设备流程，使他可以接受一个外部图形API运行时的指针。还需要修改一些Clear， Present等流程。让bgfx在RenderTarget上工作。

用bgfx来桥接的话，（会有问题）会不会对引擎RHI状态侵入？例如，引擎自身的RHI通过逻辑而不是查询硬件状态记录了RenderState，那么bgfx跳过了RHI进行渲染，会不会破坏渲染状态？

问题二： 额外的RenderTarget负担

将UI渲染到贴图是需要额外的RenderTarget内存开销，这部分开销随渲染的UI的尺寸不同而不同。如果1024 * 768像素渲染一个整屏的UI，那么将需要 3MB 的内存， 目前主流手机分辨率一般都在2K以上，那么这部分内存可能超过10MB，这无论如何都无法接受。

如果不使用RenderTarget会怎么样？如果不使用RenderTarget，可以考虑的方案是吧UI直接渲染到BackBuffer上，一般在Present之前，就将UI覆盖在引擎所有画面之上，包括引擎自身的UI。

这种问题无法控制UI与现有的游戏引擎UI的层级关系，也无法让他嵌入现有的UI系统里协同工作，只能硬生生的覆盖在上面，这在实际的工作中是无法接受的。为此只能使用RenderTarget，从而避免UI层级和UI协同的问题，因为通过RenderTarget可以把UI渲染到任何现有UI层级之上，甚至渲染到3D场景中。

问题三： 抽象为接口问题

如果将绘制能力抽象为少数接口，并由宿主来完成，就不需要实现整套的RHI解决方案，这样能

减少运行时的代码段，不需要RenderTarget，减小运行时内存，还能灵活运用现有引擎的UI交互能力，不会出现层级问题，

在这里有3种思路， 如下：

* 抽象为RHI，要求宿主实现RHI

*抽象为对象接口，要求宿主实现图元对象

*抽象为图元绘制接口，要求宿主实现图元绘制能力

抽象RHI的代码如下：

class RHI
{
public:
    virtual VertexBuffer* CreateVertexBuffer(...) = 0;
    virtual Texture* CreateTexture(...) = 0;
    ...
};

基本想法就是要求宿主实现RHI，基于这些RHI完成绘制，并将最终的渲染指令流转到引擎的渲染管线。这个想法简单直接，非常易于集成，如果单独考虑Unreal Engine，那么基本上使用这种抽象就可以了。这种抽象形式时Unity引擎里不太容易控制，虽然Unity 提供了Low LevelPlugin 系统，但这套系统尚不完善，没有完成RHI的封装，需要自己制作，而且Low Level Plugin结果很难控制，无法和Unity本身的UI系统很好的结合。在Unity 5 之后，Unity引入一套Command Buffer系统，这套系统也可以完成自定义渲染，但问题是和Low LevelPlugin类似。

抽象为对象接口的代码如下：

class IH5Host
{
    public:
        Text* createText(...);
        Image* createImage(...);
        Border* createBorder(...);
}

这样抽象适合于Unity系统，可以把基本图元转换为·Unity系统里的Text，Image对象。这样抽象后会产生对象管理问题（生命周期， 对象控制），会产生不一致。

一种折中方案时根据DOM对象树来建立一颗渲染树，2边基于渲染树来渲染。

抽象为图元绘制接口：

class IH5Render
{
   public:
        void paintText(...);
        void paintImage(...); 
        void paintBackGround(...);
        void paintBorder(...); 
}

图元绘制接口和对象接口的差别是，图元绘制接口每帧都有需要调用，无状态，而对象接口构造调用一次，析构调用一次，有状态，需要自行管理生命周期。UE4就采用了我图元绘制接口，在FSlateDrawElement类种，抽象为图元绘制接口如下

class FSlateElement
{
	SLATECORE_API static void MakeBox( 
		FSlateWindowElementList& ElementList,
		uint32 InLayer,
		const FPaintGeometry& PaintGeometry,
		const FSlateBrush* InBrush,
		ESlateDrawEffect InDrawEffects = ESlateDrawEffect::None,
		const FLinearColor& InTint = FLinearColor::White );


	UE_DEPRECATED(4.20, "Storing and passing in a FSlateResourceHandle to MakeBox is no longer necessary.")
	SLATECORE_API static void MakeBox(
		FSlateWindowElementList& ElementList,
		uint32 InLayer, 
		const FPaintGeometry& PaintGeometry, 
		const FSlateBrush* InBrush, 
		const FSlateResourceHandle& InRenderingHandle, 
		ESlateDrawEffect InDrawEffects = ESlateDrawEffect::None, 
		const FLinearColor& InTint = FLinearColor::White );

	SLATECORE_API static void MakeRotatedBox(
		FSlateWindowElementList& ElementList,
		uint32 InLayer, 
		const FPaintGeometry& PaintGeometry, 
		const FSlateBrush* InBrush, 
		ESlateDrawEffect,
		float Angle,
		TOptional<FVector2d> InRotationPoint,
		ERotationSpace RotationSpace = RelativeToElement,
		const FLinearColor& InTint = FLinearColor::White );

	SLATECORE_API static void MakeRotatedBox(
		FSlateWindowElementList& ElementList,
		uint32 InLayer,
		const FPaintGeometry& PaintGeometry,
		const FSlateBrush* InBrush,
		ESlateDrawEffect InDrawEffects = ESlateDrawEffect::None,
		float Angle = 0.0f,
		TOptional<FVector2f> InRotationPoint = TOptional<FVector2f>(),
		ERotationSpace RotationSpace = RelativeToElement,
		const FLinearColor& InTint = FLinearColor::White);

........
}

这个类时图元绘制接口，UE4中的空间都是基于这个类提供的方法来绘制UI元素的，同时会根据绘制的调用顺序来考虑合批操作(Batch),这样调用的接口就自动具备了合批能力。

考虑到不同引擎的实现复杂度，包括在·自研引擎这种没有很好的对象体系来说明的引擎中容易集成，最终的做法是抽象为图元绘制接口。在UE4中可以无缝衔接，在Unity有点麻烦。

我们吧H5 ES页面的解析，加载，排版，渲染抽象等接口统称为UI前端，把不同引擎实现的渲染接口统称为后端，如图

渲染后端的实现

讨论完了架构，下面介绍如何在当前主流的2个商业引擎和自研引擎上具体实现相关功能。

UE4

UE4引擎提供Plugin机制，能够轻松将扩展功能放入Plugin插件中，基于Plugin的模式可以很好的实现UE4后端渲染。作为UE4扩展UI的组件需要遵循以下3个原则：

1 去除引擎定制化功能，版本需要通用。

2 符合UE4的UI通用风格。

3 保持渲染效率和性能一致性。

通过参考UE4的Slate UI的实现方式，在满足以上3个原则的同时可以自定义封装一个UMG的UI控件，用户可以在编辑蓝图的可视化时使用，并在蓝图中调用相关的接口功能。

1 UE4的渲染实现

继承UWidget（UMG基类）和SWidget（SlateUI基类）这2个基类，并实现自定义Custom UI组件。

FSlateDrawElement::MakeText // 绘制字体
FSlateDrawElement::MakeLines // 绘制线条
FSlateDrawElement::MakeBox // 绘制图片 矩形

2 UE4的资源管理

核心的资源管理通过句柄来关联，资源的生命周期通过引用计数来控制，目前用到的句柄分为一下3种。

绘制上下文：此外指临时上下文，由绘制方自行管理，H5的内核绘制·只进行上下文透传处理。

贴图资源：贴图绘制的资源对象

字体资源：文字绘制的资源对象

H5的内核通过句柄对象的引用计数来管理对应句柄的生命周期。例如，打开动态页面A使用font和image就会通过资源管理器获取是否存在，存在引用就会加加，如果则调用对应的创建接口来通知引擎需要创建资源，引擎通过创建返回句柄值。

绘制上下文是一个临时句柄对象，内核不需要创建此对象，并且使用比较简单。在UE4中由SWidget::OnPaint发起绘制时，调用H5::Paint(HANDLE device)就可以指定device对象对应绘制就会将此参数作为绘制参数传回。。如H5::DrawText(HANDLE device, ..);

资源使用如下：

贴图资源，（字体资源也一样）在UE4中，UTexture2D时用来管理贴图资源对象。当H5内核驱动来创建对象的时候，UE4端会将UTexture2D地址值最为参数传回给H5内核。将此贴图对象加入一个内核管理列表，通过H5的抽象绘制接口（DrawImage）将句柄信息关联到对应的UTexture2D对象，然后提供给FSlateDrawElement::DrawBox的渲染接口使用。

句柄销毁如下

如果关闭了页面，那么对对象的引用就会减1，如果引用计数为01就会销毁句柄，并通知UE4销毁资源。

3 UE4的特殊绘制

在H5中实际使用会用到一些特殊的图元，例如圆角头像，圆角边框等。在UE4中原始图元接口并不能直接支持，我们需要使用Shader才能高效实现。FSlateBrush支持Shader画刷， FSlateMaterialBrush数据FSlateBrush的派生类，可以通过Shader方式来特殊绘制。（实现细节可以查看 腾讯游戏开发精粹2 P254-257 ）

4 UE4版本差异引发问题

接口变更可以根据不同宏去替换对应功能，以下是重点特例问题：

问题1： FSlateBrsuh绘制参数的保持问题。

UE4 4.21之前版本使用FSlateBrush画刷绘制时，FSlateDrawElement并未保存画刷中的一些参数问题（Margin， Tiling， Mirror， UVRegion， DrawAs），支持有FSlateBrush本身的指针地址，这样会带来2个问题。

• FSlateBrush 安全性不能保证，因为游戏线程和渲染线程时不同的线程。

• 相同的FSlateBrush不能使用在不同绘制参数上多次绘制。例如同一张贴图画刷 先绘制一张UVRegion从（0，0）到（1，1）的全图，在绘制一张 UVRegion（0.5，0.5）到（1，1）的半图，结果绘制了2张半图，因为在FSlateBrsh投递渲染指令到渲染队列的时候是以FSlateBrush指针的方式获取当前渲染指令的绘制参数的，所以相同的渲染队列里的相同FSlateBrush指针的渲染参数时相同的。

解决方案：

• 在FSlateDrawElement中保存渲染参数并在提交渲染指令的时候使用FSlateDrawElement保持的渲染参数，（在UE4.21以后的版本修复了 FSlateDrawElement 使用DataPayload拷贝FSlateBrush绘制参数） 。

• 当同一个FSlateBrush进行不同的渲染参数绘制时，使用新的FSlateBrush进行绘制；基本的方式是使用引用队列存储不同的绘制参数的FSlateBrush，并在绘制完成后Check FSlateBrsh****引用情况，对于没有引用的进行安全的延迟释放。

问题2：Slate UI的合批问题：

UE4.24之后的版本使用了新的合批算法，在进行文字合批的时候，遇到空格单字符 FSlateDrawElement不会计算字符绘制的顶点数和边数，而会把FSlateDrawElement当成一个未合批的缓存节点，如果最后一个绘制元素是字符空格，则此合批缓存节点的顶点偏移值恰好是缓存顶点队列的大小的值。在进行缓存节点合批时，不会判断需要合批节点是否是有效的值的顶点数，这样在合批的时候就会出现数组越界的情况，引发程序的Crash。

解决方案：

• 修改源代码，将绘制顶点数为0的节点不进行合批操作。

• Plugin插件，使用H5页面绘制遇到空格单字符跳过绘制。

UE3

UE3不像UE4有系统UI管理模块，需要自己管理。所以采样动态库加载的方式（减少与引擎代码耦合度和资源管理） UE3绘制UI通过Canvas来绘制，因此我们需要自定义一类Canvas来管理，

Unity

UE4绘制接口可以称为 Immediate Mode接口，Unity UI系统提供了Immediate Mode接口的GUI系统，，由于效率，此系统只使用在编辑器模式下，在游戏环境中，使用UGUI，这样需要考虑将创建对象的接口转换为Immediate mode接口，同时也要考虑 C#和C++交互。

1 C++和C#通信

C#调用C++ 通过使用C++动态库导出方法符号在C#使用DllImport 指定导入的方法名称。

2 Unity3D渲染

Unity3D提供Low Level Plugin机制来扩展渲染，这套机制在早期由许多Bug所以不能很好的结合。

3 Unity3D和H5渲染结合

在Unity3D中，H5的渲染接口要对应RHI更上层机制，要按照下图方式来渲染。（渲染Box模型的基础图元）

• 背景

• 边框

• 图片

• 文字

因为使用的时Immediate mode模式接口来实现封装渲染指令，每一帧都要发送的话，太费了，所以我们使用渲染队列

4 接口转换

Unity3D提供了UI框架UGUI，渲染文本UGUI提供了渲染组件Text，Text基本满足大部分的渲染需求，当收到H5的渲染指令的同时，先根据渲染指令类型，创建对应的UGUI组件，然后渲染指令的信息应用到组件上。

5 渲染基本图形

除了图片文字等可以直接通过接口转换，还有一些接口，无法在UGUI找到合适的组件，如渲染线段，虚线，边框等，在这里我们使用UGUI中的渲染矢量图形，MaskableGraphics这个类型支持直接修改顶点信息功能，

6 控制信息

Unity3D通过使用Mask组件来控制一些空间是否显示。

7 性能优化

方案 ：

• 预先创建若干个组件。

• 连接对应组件使用hash

• 运算压力大的异步执行

• 缓存预算结果

自研引擎

1 Present/Swap钩子

通过使用函数拦截可以在完成一帧渲染的同时执行额外的绘制指令，从而显示H5 UI

优点：

宿主无感知

没有额外的显存消耗

缺点：

产出无中间态，永远覆盖在最上层。无法融入宿主UI

2 使用Render Target

RenderTarget本质时一个离屏输出区域，使用RenderTarget，宿主可以自由i的操作多个嵌入式窗口实例，并对其结构进行灵活组装，以实现各种复杂的融合效果。

3 使用RHI在包装

我们使用了bgfx的第三方渲染库来实现自研引擎扩展H5。方式类似于（UE）具体详见 腾讯游戏开发精粹2 P267-269

网络库

标准H5由2大网络设施，XmlHttpRequest和WebSocket前者解决单次调用问题，后者解决服务器推送问题，这2者本质都是HTTP，需要良好的封装，社区有大量有封装好的开源库例如libcurl/libwebsocket.但是作为一个嵌入式引擎，为减少代码体积，成为关注问题。

总结

在·介绍H5 UI设计抽象的IH5Render接口，在2大流行的商业引擎和自研引擎实现方式，对比3种方式的异同。

• 在商业引擎中，我们关注如何找到商业引擎自带的绘制功能去表现H5的UI绘制单元，在自研引擎模式下，我们重做了一边商业引擎的路。

• 同为商业引擎，在Unity3D和UE4也有很大的差别，UE4提供的接口更偏向于底层，而Unity3D中的接口更偏向于中层，基本上是通过生成场景图的节点加功能组件来承接IH5Render的输出。