CN106325866B - 跨引擎调用方法及装置 - Google Patents

Abstract

本发明公开了一种跨引擎调用方法及装置。其中，该方法包括：第一引擎获取第一数据集合，其中，第一引擎采用编译型编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；第一引擎向第二引擎传入第一数据集合，其中，第二引擎采用脚本编程语言；第一引擎接收来自于第二引擎的第二数据集合，其中，第二数据集合包括：对游戏对象的操作指令的序列化结果。本发明解决了相关技术中提供的在Unity引擎中嵌入Lua脚本系统的技术方案的跨语言调用速度较慢，执行效率较低的技术问题。

Description

跨引擎调用方法及装置

技术领域

本发明涉及计算机领域，具体而言，涉及一种跨引擎调用方法及装置。

背景技术

目前，相关技术中提供的Unity(其为一种游戏引擎的名称)引擎由于使用的是编译型编程语言C#，因此，在开发过程中，无法及时在实体设备上查询最新的程序运行效果，而需要经历漫长的编译安装等待，由此造成开发效率较低。此外，在提交移动终端应用程序(App)发布渠道后，无法修改游戏逻辑。如果存在漏洞(bug)需要修复，则必须重新提交App审核，由此造成修复周期较长。

对于上述问题，如果能够在Unity引擎中嵌入脚本编程语言Lua脚本系统，则可以跳过编译，快速更新安装在实体设备上的程序，同时还可以绕过App发布渠道即时进行bug修复。

由于Unity引擎中没有提供编译型编程语言C应用程序编程接口(API)，而只存在C#API。为此，相关技术中所提出的技术方案都是采用Lua C API将C#类导出至Lua中。Lua调用C#的方式是采用Lua代理对象来操作对应的C#对象。而C#调用Lua的方式则是直接通过Lua C API调用Lua函数。

然而，相关技术中所提出的上述解决方案存在如下技术缺陷：

(1)Lua绑定C#类的开销较大，其原因在于：一方面是由于每个Lua与C#跨语言调用都会产生多个Lua C API调用，从而使得跨语言调用的速度较慢；另一方面是由于Lua与C#跨语言互相引用对象会产生额外的对象管理开销，例如：对象存入引用字典、对象查询、对象类型转换、对象销毁。

(2)因执行效率较低易导致相关技术中大多数使用Lua脚本系统的Unity游戏脚本化程度较低。采用Lua控制的部分主要集中于菜单界面、网络通信部分，而战斗部分、资源加载部分则很少使用Lua脚本控制，由此造成实体设备上高速开发的部分较为局限，并且绕过App发布而使用脚本修正的bug范围也十分有限。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种跨引擎调用方法及装置，以至少解决相关技术中提供的在Unity引擎中嵌入Lua脚本系统的技术方案的跨语言调用速度较慢，执行效率较低的技术问题。

根据本发明实施例的一个方面，提供了一种跨引擎调用方法，包括：

第一引擎获取第一数据集合，其中，第一引擎采用编译型编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；第一引擎向第二引擎传入第一数据集合，其中，第二引擎采用脚本编程语言；第一引擎接收来自于第二引擎的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果。

可选地，第一引擎获取第一数据集合包括：第一引擎获取待操作的一个或多个游戏对象；第一引擎分别收集与每种游戏对象对应的回调事件，并分别对收集到的回调事件进行序列化处理，得到待拼接的序列化结果；第一引擎将得到的与每种游戏对象对应的待拼接的序列化结果进行拼接，获取第一数据集合，其中，第一数据集合记录每个回调事件所归属的游戏对象。

可选地，第一引擎获取第一数据集合还包括：第一引擎获取当前存在的全部帧事件，其中，帧事件包括以下至少之一：渲染帧更新事件、逻辑帧更新事件；第一引擎将获取到的帧事件拼接至第一数据集合。

可选地，第一引擎向第二引擎传入第一数据集合包括：第一引擎对一种或多种类型回调事件执行序列化操作，得到二进制数据块；第一引擎将二进制数据块的内存指针和长度传入第二引擎。

可选地，在第一引擎接收来自于第二引擎的第二数据集合之后，还包括：第一引擎从第二数据集合中获取对一个或多个游戏对象的操作指令；第一引擎分别确定每条操作指令对应的游戏对象，并将每条操作指令分发至对应的游戏对象。

可选地，一种或多种类型回调事件包括以下至少之一：帧事件、游戏对象生命周期事件、物理事件、界面操作事件。

根据本发明实施例的另一方面，还提供了另一种跨引擎调用方法，包括：

第二引擎接收来自于第一引擎的第一数据集合，其中，第一引擎采用编译型编程语言，第二引擎采用脚本编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；第二引擎获取与第一数据集合对应的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；第二引擎将第二数据集合返回至第一引擎。

可选地，第二引擎接收来自于第一引擎的第一数据集合包括：第二引擎获取在第一引擎对一种或多种类型回调事件进行序列化处理后得到的二进制数据块的内存指针和长度；第二引擎根据内存指针和长度接收第一数据集合。

可选地，第二引擎获取第二数据集合包括：第二引擎从预设对应关系中确定一种或多种类型回调事件中每个回调事件对应的处理组件，其中，预设对应关系中存储有与每个回调事件归属的游戏对象标识与处理组件的对应关系；第二引擎将每个回调事件分发至确定的处理组件；第二引擎获取全部确定的处理组件反馈的操作指令，得到第二数据集合。

可选地，第二引擎获取全部确定的处理组件反馈的操作指令，得到第二数据集合包括：第二引擎将获取到的每条操作指令序列化成指令标识和指令参数的组合方式，其中，指令标识用于指示待调用的函数，指令参数用于指示在待调用的函数中待操作的参数；第二引擎按照序列化后操作指令的数据类型执行内存对齐操作，得到第二数据集合。

可选地，第二引擎将第二数据集合返回至第一引擎包括：第二引擎获取通过对所述一个或多个游戏对象的操作指令进行序列化处理得到的序列化结果的内存地址和长度数据；第二引擎将内存地址和长度数据返回至第一引擎。

根据本发明实施例的又一方面，提供了一种跨引擎调用装置，包括：

第一获取模块，用于获取第一数据集合，其中，第一引擎采用编译型编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；处理模块，用于向第二引擎传入第一数据集合，其中，第二引擎采用脚本编程语言；接收模块，用于接收来自于第二引擎的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果。

可选地，第一获取模块包括：第一获取单元，用于获取待操作的一个或多个的游戏对象；收集单元，用于分别收集与每种游戏对象对应的回调事件，并分别对收集到的回调事件进行序列化处理，得到待拼接的序列化结果；第二获取单元，用于将得到的与每种游戏对象对应的待拼接的序列化结果进行拼接，获取第一数据集合，其中，第一数据集合记录每个回调事件所归属的游戏对象。

可选地，第一获取模块还包括：第三获取单元，用于获取当前存在的全部帧事件，其中，帧事件包括以下至少之一：渲染帧更新事件、逻辑帧更新事件；第四获取单元，用于将获取到的帧事件拼接至第一数据集合。

可选地，处理模块包括：第一处理单元，用于对一种或多种类型回调事件执行序列化操作，得到二进制数据块；第二处理单元，用于将二进制数据块的内存指针和长度传入第二引擎。

可选地，上述装置还包括：第二获取模块，用于从第二数据集合中获取对一个或多个游戏对象的操作指令；分发模块，用于分别确定每条操作指令对应的游戏对象，并将每条操作指令分发至对应的游戏对象。

可选地，一种或多种类型回调事件包括以下至少之一：帧事件、游戏对象生命周期事件、物理事件、界面操作事件。

根据本发明实施例的再一方面，还提供了另一种跨引擎调用装置，包括：

处理模块，用于接收来自于第一引擎的第一数据集合，其中，第一引擎采用编译型编程语言，第二引擎采用脚本编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；获取模块，用于获取与第一数据集合对应的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；反馈模块，用于将第二数据集合返回至第一引擎。

可选地，处理模块包括：第一获取单元，用于获取在第一引擎对一种或多种类型回调事件进行序列化处理后得到的二进制数据块的内存指针和长度；接收单元，用于根据内存指针和长度接收第一数据集合。

可选地，获取模块包括：第一确定单元，用于从预设对应关系中确定一种或多种类型回调事件中每个回调事件对应的处理组件，其中，预设对应关系中存储有与每个回调事件归属的游戏对象标识与处理组件的对应关系；分发单元，用于将每个回调事件分发至确定的处理组件；第二获取单元，用于获取全部确定的处理组件反馈的操作指令，得到第二数据集合。

可选地，第二获取单元包括：处理子单元，用于将获取到的每条操作指令序列化成指令标识和指令参数的组合方式，其中，指令标识用于指示待调用的函数，指令参数用于指示在待调用的函数中待操作的参数；获取子单元，用于按照序列化后操作指令的数据类型执行内存对齐操作，得到第二数据集合。

可选地，反馈模块包括：第二确定单元，用于获取通过对所述一个或多个游戏对象的操作指令进行序列化处理得到的序列化结果的内存地址和长度数据；反馈单元，用于将内存地址和长度数据返回至第一引擎。

在本发明实施例中，采用编译型编程语言的第一引擎获取包括一种或多种类型回调事件的序列化结果的第一数据集合，通过第一引擎向采用脚本编程语言的第二引擎传入第一数据集合，然后再接收来自于第二引擎的包括对一个或多个游戏对象的操作指令的序列化结果的第二数据集合，从而实现了减少跨语言调用次数，达到了增加跨语言调用的速度的目的，缩短消耗在跨语言调用上的时间以及提高跨语言调用的执行效率的技术效果，进而解决了相关技术中提供的在Unity引擎中嵌入Lua脚本系统的技术方案的跨语言调用速度较慢，执行效率较低的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的跨引擎调用方法的流程图；

图2是根据本发明优选实施例的批量调用实现过程的示意图；

图3是根据本发明实施例的另一种跨引擎调用方法的流程图；

图4是根据本发明优选实施例的混杂指令内存对齐方式的示意图；

图5是根据本发明实施例的一种跨引擎调用装置的流程图；

图6是根据本发明优选实施例的一种跨引擎调用装置的流程图；

图7是根据本发明实施例的另一种跨引擎调用装置的流程图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明实施例，提供了一种跨引擎调用方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的跨引擎调用方法的流程图，如图1所示，该方法包括如下步骤：

步骤S12，第一引擎获取第一数据集合，其中，第一引擎采用编译型编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；

步骤S14，第一引擎向第二引擎传入第一数据集合，其中，第二引擎采用脚本编程语言；

步骤S16，第一引擎接收来自于第二引擎的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果。

通过上述步骤，采用编译型编程语言的第一引擎获取包括一种或多种类型回调事件的序列化结果的第一数据集合，通过第一引擎向第二引擎传入第一数据集合，然后再接收来自于第二引擎的包括对一个或多个游戏对象的操作指令的序列化结果的第二数据集合，达到了Unity游戏引擎(相当于上述第一引擎)只需要一次调用Lua游戏引擎(相当于上述第二引擎)，便可以批量地完成多个Unity游戏引擎(下文中称为C#端)到Lua游戏引擎(下文中称为Lua端)的事件回调以及多个Lua端对C#端API的调用，以增加跨语言调用的速度的目的，从而实现了减少跨语言调用次数，缩短消耗在跨语言调用上的时间以及提高跨语言调用的执行效率的技术效果，进而解决了相关技术中提供的在Unity引擎中嵌入Lua脚本系统的技术方案的跨语言调用速度较慢，执行效率较低的技术问题。

在优选实施过程中，上述一种或多种类型回调事件可以包括但不限于以下至少之一：

(1)帧事件；

(2)游戏对象生命周期事件；

(3)物理事件；

(4)界面操作事件。

游戏对象(GameObject)是Unity游戏引擎的一种基础物体，其上可以挂接多种组件(Component)，GameObject下可以存在很多子GameObject，以构成树状结构，GameObject具有enable和disable状态；Component必须挂接在GameObject上，不能单独存在，当其所挂接的GameObject被销毁时，Component也会随之一同被销毁，Component可以实现3D模型显示、动画、粒子等多种功能。

MonoBehaviour是Unity提供的一个C#基类，通过继承它，可以创建自定义类型的Component，其可以监听多种回调事件，这些回调事件可以包括但不限于：帧事件(例如：Unity的渲染帧更新事件、Unity的逻辑帧更新事件)，生命周期事件(例如：OnEnable事件、OnDisable事件、OnDestroy事件)，物理事件(例如：OnCollisionEnter2D事件、OnCollisionExit2D事件)，界面相关的操作事件。这些事件的来源是当前MonoBehaviour所挂接的GameObject，以及其上挂接的其它Component。

分批处理的游戏对象(BatchedGameObject)组件是优选实施例实现的一个Component，用于通过它控制它所挂接的GameObject，以及收集此GameObject的各种回调事件。

在通常情况下，常见的必选的回调事件可以包括：Unity中的GameObject生命周期相关的回调，即OnEnable,OnDisable,OnDestroy。另外，常见的可选回调事件可以包括但不限于：物理相关的碰撞检测事件，界面相关的操作事件。

可选地，在步骤S12中，第一引擎获取第一数据集合可以包括以下执行步骤：

步骤S121，第一引擎获取待操作的一个或多个游戏对象(例如：BatchedGameObject)组件；

步骤S122，第一引擎分别收集与每种BatchedGameObject组件对应的回调事件，并分别对收集到的回调事件进行序列化处理，得到待拼接的序列化结果；

步骤S123，第一引擎将得到的与每种BatchedGameObject组件对应的待拼接的序列化结果进行拼接，获取第一数据集合，其中，第一数据集合记录每个回调事件所归属的BatchedGameObject组件。

图2是根据本发明优选实施例的批量调用实现过程的示意图。如图2所示，BatchedGameObject和Lua Behaviour的创建和销毁过程如下：

BatchedGameObject是由Lua代码通过现有的Lua调用C#的过程，从Prefab创建的。因为该创建操作不会过于频繁，所以可以直接采用现有的跨语言调用方式即可。在BatchedGameObject创建完成后，会生成一个对应的BatchedGameObject ID来标识该BatchedGameObject，C#中的批量调用管理器会将其加入至BatchedGameObject字典。此外，Lua中也会创建一个Lua Behaviour与该BatchedGameObject进行绑定，其绑定方式便是将BatchedGameObject ID添加至Lua的Lua Behaviour表中。

当BatchedGameObject被销毁时，其对应的OnDestroy事件将会通过批量回调队列传入至Lua，Lua批量调用管理器就会将Lua Behaviour表中对应的Lua Behavour加以清除。

综上所述，批量调用的跨语言内存管理规则可以简化为：完全是基于C#中的BatchedGameObject字典和Lua中的Lua Behaviour表，并且Lua Behaviour的创建与销毁完全依赖于BatchedGameObject的创建与销毁。

C#端的批量调用管理器将回调事件缓存至批量回调队列(相当于上述第一数据集合)中。C#端的批量调用管理器是可以通过MonoBehaviour实现的一个Component。在整个游戏过程中需要确保其永远不被销毁。由游戏逻辑监听到的全部Unity引擎事件都需要由C#端的批量调用管理器来收集，游戏逻辑所发出的所有引擎操作指令也都需要由C#端的批量调用管理器来分发。

在优选实施例中，批量回调队列的结构如下：

每种回调类型分别对应一个特定的批量回调队列。由此回调过程通常是不需要考虑先后顺序的，按照类型存放收集到的回调事件可以对相同数据结构进行集中存储和处理，从而提高程序运行效率。

对于C#端的批量调用管理器而言，可以将具有相同数据结构的回调事件设置在一起进行批量序列化处理。而对于Lua端的批量调用管理器而言，相同类型的回调事件会在一起集中批量处理。例如：BatchedGameObject组件可以收集OnEnable事件并存入对应的OnEnable事件队列中，还可以收集OnDisable事件存入对应的OnDisable事件队列中。在对回调事件队列进行序列化处理时，每个不同类型的批量回调队列会分别序列化，然后拼接在一起组成一个完整的批量回调事件队列序列化结果。

进一步地，存储的回调事件信息需要包含的一项重要内容便是：BatchedGameObject ID，用于表明每个存储的回调事件是由哪个BatchedGameObject对象发出的。这样，Lua端的批量调用管理器才能够将其分发到对应的Lua Behavour。当然，不同的回调事件也可能会包含其他信息，例如：物理碰撞事件的信息还可以包含：进入碰撞的另一个是什么物体。

可选地，在步骤S12中，第一引擎获取第一数据集合还可以包括以下执行步骤：

步骤S124，第一引擎获取当前存在的全部帧事件，其中，帧事件包括以下至少之一：渲染帧更新事件、逻辑帧更新事件；

步骤S125，第一引擎将获取到的帧事件拼接至第一数据集合。

Unity中的渲染帧更新事件和逻辑帧更新事件分别被称为Update事件和FixedUpdate事件。由于Update与FixedUpdate这两个回调事件的产生频率非常高，Unity会在每个渲染帧触发全部Update事件，以及会在每个逻辑帧触发全部FixedUpdate事件，因此，批量调用管理器无需收集每个Batched GameObject的Update与FixedUpdate回调事件。而是仅仅在C#端的批量调用管理器的Update或FixedUpdate事件时将一个总Update事件或总FixedUpdate事件放入批量回调队列。总Update事件或总FixedUpdate事件仅意味着当前所有的Update事件或FixedUpdate事件需要被触发，这个事件数据里面并没有记录具体要触发哪些Lua Behaviour的Update或FixedUpdate事件。Lua端的批量调用管理器一旦接收到总Update事件或总FixedUpdate事件，就会向各个Lua Behaviour发送Update事件或FixedUpdate事件。

可选地，在步骤S14中，第一引擎向第二引擎传入第一数据集合可以包括以下执行步骤：

步骤S141，第一引擎运行启动脚本，获取第二引擎入口函数；

步骤S142，第一引擎调用第二引擎入口函数，向第二引擎传入第一数据集合。

如图2所示，在Unity的游戏循环的Update和FixedUpdate时机，C#端的批量调用管理器将会调用Lua端的批量调用管理器入口函数，并将批量回调队列的内容传入Lua端的批量调用管理器。

Unity会在每个渲染帧触发全部Update事件，以及会在每个逻辑帧触发全部FixedUpdate事件。C#端的批量调用管理器本身是基于MonoBehaviour实现的一个Component，其可以接收到Update和FixedUpdate事件。当C#端的批量调用管理器接收到Update事件时，便说明当前正处于Unity游戏循环的Update时机，这时将会调用Lua端的批量调用管理器入口函数，并将批量回调队列的内容传入Lua端的批量调用管理器。当C#端的批量调用管理器接收到FixedUpdate事件时，便说明当前正处于Unity游戏循环的FixedUpdate时机，这时将会调用Lua端的批量调用管理器入口函数，并将批量回调队列的内容传入Lua端的批量调用管理器。

C#端的批量调用管理器首次获取Lua端的批量调用管理器的入口函数的方式在于：C#端的批量调用管理器在启动时执行的第一个Lua脚本函数的返回值，即为Lua端的批量调用管理器的入口函数。随后，C#端的批量调用管理器会将这个函数存储至Lua端的Register中。以后，每次需要调用Lua端的批量调用管理器的入口函数时，都可以通过Lua端的Register来获取。

批量回调队列原本属于C#的数据结构，其传入Lua端的方式在于：先将批量回调队列序列化成二进制数据块，然后将这个数据块的内存指针和长度作为函数参数传入Lua端的入口函数。

可选地，在步骤S142中，第一引擎向第二引擎传入第一数据集合可以包括以下执行步骤：

步骤S1421，第一引擎对一种或多种类型回调事件执行序列化操作，得到二进制数据块；

步骤S1422，第一引擎将二进制数据块的内存指针和长度传入第二引擎入口函数。

上述序列化处理过程会将C#的数据结构转换为一个C#byte数组。使用C#的GCHandle可以将这个C#byte数组锁定并获取内存指针。该内存指针可以转换为Lua lightuserdata，从而可以作为Lua端的批量调用管理器的入口函数的参数传入。

可选地，在步骤S16，第一引擎接收来自于第二引擎的第二数据集合之后，还可以包括以下执行步骤：

步骤S17，第一引擎从第二数据集合中获取对BatchedGameObject组件的操作指令；

步骤S18，第一引擎分别确定每条操作指令对应的BatchedGameObject组件，并将每条操作指令分发至对应的BatchedGameObject组件。

如图2所示，C#端的批量调用管理器从批量调用队列(相当于上述第二数据集合)中读取操作指令、分发并执行各个操作指令，其中，批量调用队列与批量回调队列的区别在于：两者的数据传输方向和传输内容是不同的。

批量调用管理器内预先设置有一个BatchedGameObject的字典，可以根据BatchedGameObject ID查找对应的BatchedGameObject。于是，可以根据操作指令中的BatchedGameObject ID信息将特定操作指令分发至对应的BatchedGameObject。

在优选实施过程中，上述操作指令可以包括但不限于以下至少之一：

1)GameObject相关指令

(1)设置active状态；

2)Transform相关指令

(1)设置位置；

(2)设置缩放；

(3)设置欧拉角；

(4)设置四元数；

3)刚体相关指令

(1)设置位置；

(2)设置移动目标；

4)ICommonController控制指令

为了使得脚本能够进行丰富地效果控制，本发明优选实施例提供了一种ICommonController指令。Lua Behaviour可以通过发送指令来控制对应的BatchedGameObject的，其既可以实现一些简单的控制效果,例如：设置Enable状态、设置空间变换、移动Rigidbody，实现这类控制效果的指令格式和内容是相对固定的，所产生的控制效果也随之固定；又可以实现一些复杂的控制效果，例如：动画、粒子、声音的控制。一个Batched GameObject可能需要控制多种动画、粒子、声音的播放、而且播放的设置参数也有很多，故而这些效果适用于用ICommonController指令来进行控制。这种指令在代码层面没有设定具体的控制规则，而是会由BatchedGameObject分发给一系列ICommonController组件，以产生相应的控制效果。BatchedGameObject分发ICommonController指令的范围是BatchedGameObject所在的GameObject及其所有子GameObject上挂接的ICommonController组件。ICommonController组件是指实现了ICommonController接口的组件。根据ICommonController组件的类型不同，可以控制动画、粒子、声音等效果。这些组件可以通过编辑器来设定具体的控制效果。故而，相同的ICommonController指令根据ICommonController组件的不同设置，可能会产生不同的效果。

游戏角色表现可以包括但不限于：动画效果、粒子效果、声音效果，需要控制的引擎功能非常多。为了简化API以及增加编辑器灵活性，可以将角色相关的控制统一编成ICommonController接口。至此，ICommonController指令即为调用ICommonController接口的指令。

ICommonController接口均需要实现方法CommonControl，该方法的第一个参数是一个32bit整数，用于表示效果名称，该参数是由表示这个效果名字的字符串哈希计算得到的，后面几个参数则是几个任意32bit浮点数，用于表示效果参数。不同的效果需要的参数数量以及参数的含义各不相同。

下面将通过以下几个具体示例对ICommonController接口的使用方式加以说明。

示例一、Animator是一种Component，由Unity内置提供，其可以控制动画的播放，实现多段动画素材的复杂融合，可以提供给程序控制动画的接口是一组动画事件参数。外部程序需要通过指定动画事件参数的名字和值，来修改特定动画事件参数的值。不同的动画事件参数值的组合，可能会产生不同的动画控制效果。因此，可以制作一个实现ICommonController接口的动画控制器组件AnimatorController。CommonControl的效果名称即对应Animator的参数名，效果参数对应Animator的参数值。

示例二、粒子表示三维计算机图形学中模拟一些特定的模糊现象的技术，而这些现象是采用其它传统的渲染技术难以实现的具有真实感的游戏图形。经常使用粒子系统模拟的现象可以包括但不限于：火、爆炸、烟、水流、火花、落叶、云、雾、雪、尘、流星尾迹或者如发光轨迹这样的抽象视觉效果。由此，可以制作一个实现ICommonController接口的粒子控制器组件ParticleController。CommonControl的效果名对应控制特定粒子的播放，效果参数对应开始播放还是停止播放。

示例三、可以制作一个实现ICommonController接口的声音控制器组件AudioController。CommonControl的效果名对应控制特定音效的播放，效果参数对应开始播放还是停止播放，以及设置音效的参数。

示例四、可以制作一个实现ICommonController接口的总体效果控制组件MainController。通过组合模式将一系列子ICommonController组件的功能组合在一起。当CommonControl方法接收到一个调用时，便可将这个调用分发给所有子ICommonController组件，于是所有相同效果名称的效果都会被激发。例如：MainController接收到一个效果名称叫attack的指令，那么其所有子ICommonController组件中名称叫attack的动画效果、粒子效果以及声音效果都会被同时播放。

这种控制方法可以使得Lua代码更加专注于逻辑，而不必过多考虑具体效果控制。另外，效果表现则可以通过Unity编辑器实现完整定义，而不必考虑代码编写。

5)界面相关指令

(1)设置active状态

(2)设置文字

(3)设置位置

(4)设置大小

需要说明的是，由于批量调用是为了解决高频引擎API调用瓶颈而设计的，因此，指令设计仅包含了高频操作，而其它使用频率较低的跨语言调用，则仍然可以采用普通的C#与Lua互相调用的方式来实现。

根据本发明实施例，还提供了另一种跨引擎调用方法的实施例，图3是根据本发明实施例的另一种跨引擎调用方法的流程图，如图3所示，该方法包括如下步骤：

步骤S32，第二引擎响应第一引擎的调用指令，并接收来自于第一引擎的第一数据集合，其中，第一引擎采用编译型编程语言，第二引擎采用脚本编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；

步骤S34，第二引擎获取与第一数据集合对应的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；

步骤S36，第二引擎将第二数据集合返回至第一引擎。

可选地，在步骤S32中，第二引擎接收来自于第一引擎的第一数据集合可以包括以下执行步骤：

步骤S321，第二引擎获取在第一引擎对一种或多种类型回调事件进行序列化处理后得到的二进制数据块的内存指针和长度；

步骤S322，第二引擎根据内存指针和长度接收第一数据集合。

Lua端的批量调用管理器将回调事件分发至对应的Lua Behaviour。在LuaBehaviour处理接收到的回调事件时，Lua Behaviour也会向其所对应的BatchedGameObject发出一些操作指令。Lua端的批量调用管理器会收集这些操作指令到批量调用队列中。

在优选实施例中，可以使用C语言实现一个被称为binaryblock的Lua模块，只要通过Lua light userdata传入内存地址，便可以将该内存地址之后的任意内存偏移作为8bit整数,16bit整数,32bit整数或32bit浮点数进行解析，进而返回Lua数值。为了减少这个Lua模块的调用次数，Lua模块还支持直接将一段内存作为数据进行解析，进而返回Lua表。另外，该Lua模块也可以将一段内存转换为Lua string对象。

在Lua中存在一个Lua Behaviour表，用于存储BatchedGameObject ID与LuaBehaviour之间的映射关系。对于大部分回调事件，Lua端的批量调用管理器可以通过这个table查找到对应的Lua Behaviour。

但对于总Update事件和总FixedUpdate事件，这两类事件是没有指定BatchedGameObject ID的，其可以采用另外一种机制进行分发。有一个Lua表存储了所有处于enable状态的Lua Behavour。总Update事件和总FixedUpdate事件会分发到这个列表中的所有Lua Behavour。

可选地，在步骤S34中，第二引擎获取第二数据集合可以包括以下执行步骤：

步骤S341，第二引擎从预设对应关系中确定一种或多种类型回调事件中每个回调事件对应的处理组件，其中，预设对应关系中存储有与每个回调事件归属的BatchedGameObject组件标识与处理组件的对应关系；

步骤S342，第二引擎将每个回调事件分发至确定的处理组件；第二引擎获取全部确定的处理组件反馈的操作指令，得到第二数据集合。

为了简化跨语言内存管理，本发明优选实施例采用了“BatchedGameObject-LuaBehaviour”高层内存管理模式，BatchedGameObject是根据本发明实施例实现的一个Unity的Component，用于控制其所挂接的GameObject以及这个GameObject的所有的子GameObject。全部BatchedGameObject均存储在C#端批量调用管理器的BatchedGameObject的字典中，其中，key为每个BatchedGameObject对应的BatchedGameObject ID。

Lua Behaviour是Lua引擎中的一个对象。Lua游戏逻辑通过Lua Behaviour来控制BatchedGameObject。全部Lua Behaviour存储在Lua端的批量调用管理器的Lua Behaviour字典中，key为每个BatchedGameObject对应的BatchedGameObject ID，并且具有相同的BatchedGameObject ID的Lua Behaviour与BatchedGameObject是存在一一对应关系的。Lua Behaviour可以发送指令控制对应的BatchedGameObject的各种行为(包括但不限于：设置Enable状态、设置空间变换、移动Rigidbody、播放动画、播放粒子效果、播放声音)，也可以接收与该Lua Behaviour相关的各种回调事件。另外，当销毁BatchedGameObject时，Lua Behaviour可以从BatchedGameObject接收到销毁(Destroy)事件，从而对自身进行销毁。

在对Lua端的批量调用队列进行序列化的过程中，每个指令都可以序列化为指令标识加指令内容的形式。例如：如果指令的参数类型依次为：16bit整数、8bit整数、32bit整数、32bit浮点数，那么，在序列化过程中，可以先将指令号序列化成8bit整数，后面再加上指令内容的二进制序列化(16bit整数、8bit整数、32bit整数、32bit浮点数)即可。使用C实现的Lua模块binaryblock，可以分配一个内存块，并在这个内存块中写入这些二进制数据。

然而，如果直接将上述混杂在一起的不同类型的指令序列化，然后按顺序紧密排列，那么便会造成大量数据内存不对齐，进而降低数据读写效率，这对于运行效率需求较高的批量调用而言，需要在很短时间内实现大量指令的序列化与反序列化。于是，在本发明优选实施例中，可以使用混杂指令内存对齐方式以使得这些混杂的指令能够实现内存对齐。

可选地，在步骤S342中，第二引擎获取全部确定的处理组件反馈的操作指令，得到第二数据集合可以包括以下执行步骤：

步骤S3421，第二引擎将获取到的每条操作指令序列化成指令标识和指令参数的组合方式，其中，指令标识用于指示待调用的函数，指令参数用于指示在待调用的函数中待操作的参数；

步骤S3422，第二引擎按照序列化后操作指令的数据类型执行内存对齐操作，得到第二数据集合。

Lua如果需要对BatchedGameObject进行操作，都需要通过调用batchcall模块提供的批量调用函数来操作。

这些函数的第一个参数均为BatchedGameObject ID，用于指定需要操作的对应BatchedGameObject，后续几个参数则为实际操作参数。例如：设置位置的函数可以采用bc_transform_set_position(batch_id,x,y,z)。

这个函数所要执行的操作即为将相应的调用指定存入批量调用队列。

每个批量调用的信息中的必须参数可以包括但不限于：

(1)Command ID，用于表明其所调用的对应函数；

(2)BatchedGameObject ID，用于表明其所操作的对应BatchedGameObject。

需要说明的是，上述批量调用过程是需要保持调用顺序的，因此，不同类型的调用需要混合在一起，并按先后顺序存储于同一个队列中。另外，还需要说明的是，批量调用的信息流永远是从Lua发送至C#。因此，尽量不要让Lua读取引擎中的Transform、Rigidbody的位置、角度等数据，而是将位置、角度等数据存储在Lua中，以使这些数据只从Lua传输至C#中，而不是从C#反向传输至Lua。

如果确实需要Lua读取引擎中的Transform、Rigidbody的位置、角度等数据，则可以通过现有的Lua调用C#的方式来读取。但是务必将这种操作的次数将至最低，否则会影响程序运行效率。

Rigidbody是一种Component，由Unity内置提供，其可以实现惯性物理效果，也是物理碰撞检测所必需的Component。对于Rigidbody而言，其位置可能会受到碰撞影响，由此易造成与Lua中存储的位置信息不同步。为此，可以在物理碰撞回调信息中包含Rigidbody的位置,Lua Behaviour接收到物理碰撞回调后便可调整其内部记录的位置信息。这样便能够确保Lua中的Rigidbody位置信息与引擎中的Rigidbody位置完全同步。

图4是根据本发明优选实施例的混杂指令内存对齐方式的示意图。如图4所示，为了便于说明上述混杂指令内存对齐方式，此处使用一个字母加一个数字来代表一个二进制数据基本元素，其中，首字母B代表8bit整数、首字母h代表16bit整数、首字母i代表32bit整数、首字母f代表32bit浮点数，第二个字符的数字用于区分不同的数据块。

假设有三个指令需要序列化：(1)B1 h1 B2 i1 f1,(2)B3 h2 f2 h3和(3)B4 B5i2；直接得到的序列化结果便是直接将上述三个指令进行连接，由此得到：B1 h1 B2 i1 f1B3 h2 f2 h3 B4 B5 i2。

而如果采用上述混杂指令内存对齐方式，则会将上述三个指令按照不同基本数据类型分类分别进行排列，由此得到：B1 B2 B3 B4 B5,h1 h2 h3,i1 i2,f1 f2。然后，再按照宽数据类型到窄数据类型将这四个队列进行连接，继而得到f1 f2 i1 i2 h1 h2 h3 B1 B2B3 B4 B5。最终实现所有数据的内存对齐。

读取每个指令时都是先读取指令标识，再读取指令参数。而每个指令标识所对应的参数类型是固定的。例如：指令标识i2，规定其指令参数的类型依次为16bit整数、8bit整数、32bit整数、32bit浮点数，则在执行反序列化操作的过程中，一旦读取到指令标识i2，那么接下来就一定需要按顺序读取出16bit整数、8bit整数、32bit整数、32bit浮点数这4个类型的参数。由此反复执行读取指令标识、读取指令参数、读取指令标识、读取指令参数……，便可以按顺序反序列化出所有的指令，其相当于所有基本数据类型的读取顺序都是可知的。

这个读取方式对于直接序列化得到的二进制序列和混杂指令内存对齐之后的二进制序列，都是有效的。以图4为例，可以先从8bit整数队列中读取出B1，此时便能够推断出这条指令的参数类型为16bit整数、8bit整数、32bit整数、32bit浮点数，接下来按序执行：从32bit整数队列中取出h1、从8bit整数队列取出B2、从32bit整数队列中取出i1以及从32bit浮点数队列中取出f1，于是这条指令就被成功反序列化。

可选地，在步骤S36中，第二引擎将第二数据集合返回至第一引擎可以包括以下执行步骤：

步骤S361，第二引擎获取通过对所述一个或多个游戏对象的操作指令进行序列化处理得到的序列化结果的内存地址和长度数据；

步骤S362，第二引擎将内存地址和长度数据返回至第一引擎。

在将Lua中的二进制数据返回至C#的过程中，假设已经将序列化结果存储至binaryblock模块所创建的内存块中，此时便可以采用Lua light userdata表示这块内存的地址以及采用数字表示这块内存的大小，这两个数据可以作为Lua端的批量调用管理器入口函数的返回值以返回至C#端的批量调用管理器。由此，C#端的批量调用管理器便可以通过Lua的C API函数lua_topointer将Lua light userdata转换成内存指针，继而使用C#的unsafe功能，可以直接从上述内存指针指向的内存中读取出相关数据。

根据本发明实施例，提供了一种跨引擎调用装置的实施例，图5是根据本发明实施例的一种跨引擎调用装置的流程图，如图5所示，该装置包括：第一获取模块50，用于获取第一数据集合，其中，第一引擎采用编译型编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；处理模块52，用于向第二引擎传入第一数据集合，其中，第二引擎采用脚本编程语言；接收模块54，用于接收来自于第二引擎的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果。

在优选实施过程中，上述一种或多种类型回调事件可以包括但不限于以下至少之一：

(1)帧事件；

(2)游戏对象生命周期事件；

(3)物理事件；

(4)界面操作事件。

可选地，第一获取模块50可以包括：第一获取单元(图中未示出)，用于获取待操作的一个或多个BatchedGameObject组件；收集单元(图中未示出)，用于分别收集与每种BatchedGameObject组件对应的回调事件，并分别对收集到的回调事件进行序列化处理，得到待拼接的序列化结果；第二获取单元(图中未示出)，用于将得到的与每种BatchedGameObject组件对应的待拼接的序列化结果进行拼接，获取第一数据集合，其中，第一数据集合记录每个回调事件所归属的BatchedGameObject组件。

可选地，第一获取模块50还可以包括：第三获取单元(图中未示出)，用于获取当前存在的全部帧事件，其中，帧事件包括以下至少之一：Update事件、FixedUpdate事件；第四获取单元(图中未示出)，用于将获取到的帧事件拼接至第一数据集合。

可选地，处理模块52，用于运行启动脚本后得到第二引擎入口函数，并调用第二引擎入口函数，向第二引擎传入第一数据集合。

可选地，处理模块52可以包括：第一处理单元(图中未示出)，用于对一种或多种类型回调事件执行序列化操作，得到二进制数据块；第二处理单元(图中未示出)，用于将二进制数据块的内存指针和长度传入第二引擎。

可选地，图6是根据本发明优选实施例的一种跨引擎调用装置的流程图，如图6所示，上述装置还可以包括：第二获取模块56，用于从第二数据集合中获取对BatchedGameObject组件的操作指令；分发模块58，用于分别确定每条操作指令对应的BatchedGameObject组件，并将每条操作指令分发至对应的BatchedGameObject组件。

根据本发明实施例，还提供了另一种跨引擎调用装置的实施例，图7是根据本发明实施例的另一种跨引擎调用装置的流程图，如图7所示，该装置包括：处理模块70，用于接收来自于第一引擎的第一数据集合，其中，第一引擎采用编译型编程语言，第二引擎采用脚本编程语言，第一数据集合包括一种或多种类型回调事件的序列化结果；获取模块72，用于获取与第一数据集合对应的第二数据集合，其中，第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；反馈模块74，用于将第二数据集合返回至第一引擎。

可选地，处理模块70可以包括：第一获取单元(图中未示出)，用于获取在第一引擎对一种或多种类型回调事件进行序列化处理后得到的二进制数据块的内存指针和长度；接收单元(图中未示出)，用于根据内存指针和长度接收第一数据集合。

可选地，获取模块72可以包括：第一确定单元(图中未示出)，用于从预设对应关系中确定一种或多种类型回调事件中每个回调事件对应的处理组件，其中，预设对应关系中存储有与每个回调事件归属的BatchedGameObject组件标识与处理组件的对应关系；分发单元(图中未示出)，用于将每个回调事件分发至确定的处理组件；第二获取单元(图中未示出)，用于获取全部确定的处理组件反馈的操作指令，得到第二数据集合。

可选地，第二获取单元可以包括：处理子单元(图中未示出)，用于将获取到的每条操作指令序列化成指令标识和指令参数的组合方式，其中，指令标识用于指示待调用的函数，指令参数用于指示在待调用的函数中待操作的参数；获取子单元(图中未示出)，用于按照序列化后操作指令的数据类型执行内存对齐操作，得到第二数据集合。

可选地，反馈模块74可以包括：第二确定单元(图中未示出)，用于获取通过对所述一个或多个游戏对象的操作指令进行序列化处理得到的序列化结果的内存地址和长度数据；反馈单元(图中未示出)，用于将内存地址和长度数据返回至第一引擎。

与相关技术中所提供的技术方案相比，通过本发明实施例所提供的批量调用方式，可以直接减少Lua与C#之间的调用次数，从而降低跨语言调用的时间消耗，进而使得游戏逻辑可以完全采用Lua编写，继而使得更新游戏逻辑和资源变得即为便利；无需重新编译App，而只需重新启动即可更新任意游戏逻辑和资源；在开发游戏的过程中，可以迅速在移动终端上观看试运行效果，以减少测试反馈时间，加快开发进度；在游戏发布之后，可以绕过App发布直接通过补丁来更新和修复游戏中存在的bug，以增加游戏产品的改进速度。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (18)

1.一种跨引擎调用方法，其特征在于，包括：

第一引擎获取第一数据集合，其中，所述第一引擎采用编译型编程语言，所述第一数据集合包括一种或多种类型回调事件的序列化结果；

所述第一引擎向第二引擎传入所述第一数据集合，其中，所述第二引擎采用脚本编程语言；

所述第一引擎接收来自于所述第二引擎的第二数据集合，其中，所述第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；

其中，所述第一引擎获取所述第一数据集合包括：

所述第一引擎获取待操作的一个或多个游戏对象；

所述第一引擎分别收集与每种游戏对象对应的回调事件，并分别对收集到的回调事件进行序列化处理，得到待拼接的序列化结果；

所述第一引擎将得到的与每种游戏对象对应的待拼接的序列化结果进行拼接，获取所述第一数据集合，其中，所述第一数据集合记录每个回调事件所归属的游戏对象。

2.根据权利要求1所述的方法，其特征在于，所述第一引擎获取所述第一数据集合还包括：

所述第一引擎获取当前存在的全部帧事件，其中，所述帧事件包括以下至少之一：渲染帧更新事件、逻辑帧更新事件；

所述第一引擎将获取到的帧事件拼接至所述第一数据集合。

3.根据权利要求1所述的方法，其特征在于，所述第一引擎向所述第二引擎传入所述第一数据集合包括：

所述第一引擎对所述一种或多种类型回调事件执行序列化操作，得到二进制数据块；

所述第一引擎将所述二进制数据块的内存指针和长度传入所述第二引擎。

4.根据权利要求1所述的方法，其特征在于，在所述第一引擎接收来自于所述第二引擎的所述第二数据集合之后，还包括：

所述第一引擎从所述第二数据集合中获取对所述一个或多个游戏对象的操作指令；

所述第一引擎分别确定每条操作指令对应的游戏对象，并将每条操作指令分发至对应的游戏对象。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述一种或多种类型回调事件包括以下至少之一：

帧事件、游戏对象生命周期事件、物理事件、界面操作事件。

6.一种跨引擎调用方法，其特征在于，包括：

第二引擎接收来自于第一引擎的第一数据集合，其中，所述第一引擎采用编译型编程语言，所述第二引擎采用脚本编程语言，所述第一数据集合包括一种或多种类型回调事件的序列化结果；

所述第二引擎获取与所述第一数据集合对应的第二数据集合，其中，所述第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；

所述第二引擎将所述第二数据集合返回至所述第一引擎；

其中，所述第二引擎接收来自于所述第一引擎的所述第一数据集合包括：

所述第二引擎获取在所述第一引擎对所述一种或多种类型回调事件进行序列化处理后得到的二进制数据块的内存指针和长度；

所述第二引擎根据所述内存指针和所述长度接收所述第一数据集合。

7.根据权利要求6所述的方法，其特征在于，所述第二引擎获取所述第二数据集合包括：

所述第二引擎从预设对应关系中确定所述一种或多种类型回调事件中每个回调事件对应的处理组件，其中，所述预设对应关系中存储有与每个回调事件归属的游戏对象标识与处理组件的对应关系；

所述第二引擎将每个回调事件分发至确定的处理组件；

所述第二引擎获取全部确定的处理组件反馈的操作指令，得到所述第二数据集合。

8.根据权利要求7所述的方法，其特征在于，所述第二引擎获取所述全部确定的处理组件反馈的操作指令，得到所述第二数据集合包括：

所述第二引擎将获取到的每条操作指令序列化成指令标识和指令参数的组合方式，其中，所述指令标识用于指示待调用的函数，所述指令参数用于指示在所述待调用的函数中待操作的参数；

所述第二引擎按照序列化后操作指令的数据类型执行内存对齐操作，得到所述第二数据集合。

9.根据权利要求6所述的方法，其特征在于，所述第二引擎将所述第二数据集合返回至所述第一引擎包括：

所述第二引擎获取通过对所述一个或多个游戏对象的操作指令进行序列化处理得到的序列化结果的内存地址和长度数据；

所述第二引擎将所述内存地址和所述长度数据返回至所述第一引擎。

10.一种跨引擎调用装置，其特征在于，应用于第一引擎，包括：

第一获取模块，用于获取第一数据集合，其中，所述第一引擎采用编译型编程语言，所述第一数据集合包括一种或多种类型回调事件的序列化结果；

处理模块，用于向第二引擎传入所述第一数据集合，其中，所述第二引擎采用脚本编程语言；

接收模块，用于接收来自于所述第二引擎的第二数据集合，其中，所述第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；

其中，所述第一获取模块包括：

第一获取单元，用于获取待操作的一个或多个游戏对象；

收集单元，用于分别收集与每种游戏对象对应的回调事件，并分别对收集到的回调事件进行序列化处理，得到待拼接的序列化结果；

第二获取单元，用于将得到的与每种游戏对象对应的待拼接的序列化结果进行拼接，获取所述第一数据集合，其中，所述第一数据集合记录每个回调事件所归属的游戏对象。

11.根据权利要求10所述的装置，其特征在于，所述第一获取模块还包括：

第三获取单元，用于获取当前存在的全部帧事件，其中，所述帧事件包括以下至少之一：渲染帧更新事件、逻辑帧更新事件；

第四获取单元，用于将获取到的帧事件拼接至所述第一数据集合。

12.根据权利要求10所述的装置，其特征在于，所述处理模块包括：

第一处理单元，用于对所述一种或多种类型回调事件执行序列化操作，得到二进制数据块；

第二处理单元，用于将所述二进制数据块的内存指针和长度传入所述第二引擎。

13.根据权利要求10所述的装置，其特征在于，所述装置还包括：

第二获取模块，用于从所述第二数据集合中获取对所述一个或多个游戏对象的操作指令；

分发模块，用于分别确定每条操作指令对应的游戏对象，并将每条操作指令分发至对应的游戏对象。

14.根据权利要求10至13中任一项所述的装置，其特征在于，所述一种或多种类型回调事件包括以下至少之一：

帧事件、游戏对象生命周期事件、物理事件、界面操作事件。

15.一种跨引擎调用装置，其特征在于，应用于第二引擎，包括：

处理模块，用于接收来自于第一引擎的第一数据集合，其中，所述第一引擎采用编译型编程语言，所述第二引擎采用脚本编程语言，所述第一数据集合包括一种或多种类型回调事件的序列化结果；

获取模块，用于获取与所述第一数据集合对应的第二数据集合，其中，所述第二数据集合包括：对一个或多个游戏对象的操作指令的序列化结果；

反馈模块，用于将所述第二数据集合返回至所述第一引擎；

其中，所述处理模块包括：

第一获取单元，用于获取在所述第一引擎对所述一种或多种类型回调事件进行序列化处理后得到的二进制数据块的内存指针和长度；

接收单元，用于根据所述内存指针和所述长度接收所述第一数据集合。

16.根据权利要求15所述的装置，其特征在于，所述获取模块包括：

第一确定单元，用于从预设对应关系中确定所述一种或多种类型回调事件中每个回调事件对应的处理组件，其中，所述预设对应关系中存储有与每个回调事件归属的游戏对象标识与处理组件的对应关系；

分发单元，用于将每个回调事件分发至确定的处理组件；

第二获取单元，用于获取全部确定的处理组件反馈的操作指令，得到所述第二数据集合。

17.根据权利要求16所述的装置，其特征在于，所述第二获取单元包括：

处理子单元，用于将获取到的每条操作指令序列化成指令标识和指令参数的组合方式，其中，所述指令标识用于指示待调用的函数，所述指令参数用于指示在所述待调用的函数中待操作的参数；

获取子单元，用于按照序列化后操作指令的数据类型执行内存对齐操作，得到所述第二数据集合。

18.根据权利要求15所述的装置，其特征在于，所述反馈模块包括：

第二确定单元，用于获取通过对所述一个或多个游戏对象的操作指令进行序列化处理得到的序列化结果的内存地址和长度数据；

反馈单元，用于将所述内存地址和所述长度数据返回至所述第一引擎。