跨游戏引擎的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来管理，