CN110262798B - 基于WebGL的图形绘制方法、装置、运行器及可读存储介质 - Google Patents

Abstract

本申请公开了一种基于WebGL的图形绘制方法、装置、运行器以及可读存储介质。该方法包括：运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象；运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。通过该技术方案，可以解决图形绘制整体效率较低的问题。

Description

基于WebGL的图形绘制方法、装置、运行器及可读存储介质

技术领域

本申请涉及计算机图形绘制技术领域，尤其涉及一种基于WebGL的图形绘制方法、装置、运行器及可读存储介质。

背景技术

在网络游戏、动画展现等应用场景中，需要进行大量的多维图形(比如2D图形或3D图形)绘制工作，图形绘制的快慢在较大程度上决定到各种应用、程序对用户进行相应操作的响应速度，进而影响到该应用或程序的用户使用量。为提高图形绘制效率，在不依赖于浏览器为载体的情况下，一般可以使用专门开发的运行器(runtime)。通常，运行器基于原生native(例如iOS、android原生框架)开发而成，支持原生APP，其包含JS解析引擎和C++引擎框架。当需要在运行器内运行JS代码编写的JS项目时，由运行器内的JS解析引擎对JS代码项目进行解析，然后将解析后的JS语言通过JS解析引擎中的引擎接口调用至C++引擎框架，再通过OpenGLES进行渲染，最后完成预定的图形绘制。

在大多数情况下，运行器的运行需要Web端引擎的配合，但是，开发Web端引擎的引擎商较多，各自具有各自不同的Web端引擎。为兼容各家的Web端引擎，业界需要将配合某特定Web端引擎的运行器由“专用”变为“通用”。为达到该目的，现有技术中的一种做法是在开发运行器时，针对多维图形绘制(无论是2D还是3D或者其他图形)，均采用标准的WebGL接口。由于采用标准WebGL接口规范，其能够兼容不同引擎商的Web端引擎，具有较高的灵活性和较强扩展性。同时，由于开发Web端引擎的引擎商按照标准WebGL接口开发，对接口事先熟知，增强了其对Web端引擎的控制能力。

然而，尽管采用WebGL标准接口开发运行器能够达到灵活性高、扩展性强、控制力好的技术效果，但是，由于在绘制多维图形的应用场景中往往涉及大量计算，这些计算在Web端引擎的JS代码层面完成，而JS代码的优势并不在其运算能力，导致采用WebGL接口的运行器的整体绘制效率无法得到保障。

发明内容

本申请实施例提供一种基于WebGL的图形绘制方法和装置，用于解决现有技术中WebGL接口的运行器的整体绘制效率较低的问题。

一方面，本申请实施例提供的基于WebGL的图形绘制方法包括：

运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象；

运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。

另一方面，本申请实施例提供的图形绘制方法包括：接收对目标图形的绘制请求，所述绘制请求中包含图形绘制规则指令以及作为所述图形绘制指令参数的预定的操作类型和操作对象；

根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。

再一方面，本申请实施例提供的基于WebGL的图形绘制装置包括：

接收单元，用于接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象；

绘制单元，用于根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。

又一方面，本申请实施例提供的运行器，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的方法的步骤。

再一方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的方法的步骤。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请实施例提供的技术方案，运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象；运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。该技术方案分工明确，充分发挥运行器的优势，有效解决了图形绘制的整体效率问题。

附图说明

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

图1为现有技术中图形绘制方法的流程示意图；

图2为本申请的一个实施例图形绘制方法的示意图；

图3为本申请的一个实施例中一节点树结构示意图；

图4为本申请的一个实施例中另一节点树结构示意图；

图5为本申请的一个实施例图形绘制装置的结构示意图；

图6为本申请的一个实施例运行器的结构示意图。

具体实施方式

在对本申请的各种实施例进行充分介绍之前，为便于理解，先对一些基本背景进行介绍。随着计算机技术的发展，人们对计算机信息处理的响应速度要求越来越高，尤其在一些实时应用场景之中，更是如此。比如，常见的网络对战型的实时性网络游戏，这些游戏通常涉及大量目标对象的动作、场景、角色、能力值、武器装备等的迅速变换，为更好呈现视觉效果，需要进行“任务艰巨”的图形绘制，图形绘制成为这类软件吸引用户量的关键瓶颈。HTML5协议在网络展现上的广泛、深入的发展，对网络Web画面的显现提出了更高的要求，早期，人们通过canvas(画布)提供的标准绘图API实现丰富画面的展现。但是，这种方式的效果有限，后续逐步出现了WebGL(英文全称：Web Graphics Library)接口协议，该接口协议能够对显卡GPU进行直接控制，为HTML5 Canvas提供硬件加速渲染，大大提高了2D或3D的显示效率和显示效果。

WebGL接口与HTML5协议类似，在项目应用层上，使用JavaScript语言(以下简称JS语言)开发。在将Web端引擎的JS项目导入到运行器中运行时，将涉及到大量的JavaScript语言与以C++语言为基础的运行器之间的调用、协调工作。不仅如此，如前述背景技术所言及，采用WebGL接口的JS项目在Web端引擎仍将可能面临大量的计算工作。参见图1所示，JS项目代码可能要调用大量的绘图函数(比如，图中示意性展示的DrawImage)，这些大量的绘图函数将完成各种复杂的矩阵计算、顶点数据合并、数据修改等运算，然后才能调用WebGL接口中的函数，传递到运行器。这些运算工作与JS项目代码的“分内能力”相悖，影响到整个图形绘制的效率。

为了解决上述问题，本申请实施例提供一种基于WebGL的图形绘制方法，参见图2，该图示出的实施例方法包括：S201：运行器接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象；S202：运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。为了更好理解该技术方案，在前述背景介绍的基础上，对该方案中的一些重要信息进行说明：

上述技术方案中步骤S201、S202涉及的执行主体为“运行器”，运行器中通常包含三部分：一是JS解析引擎部分，比如，具有该功能的V8、JSC等。从Web端引擎获得的代码尽管包含WebGL接口的一些内容，但仍然是JS代码，需要通过该JS解析引擎解析、识别，转换成运行器其他部分可操作的目标代码；二是C++引擎框架部分，该部分是运行器的“主梁”，经过JS解析引擎解析后的代码，将由该部分来完成大量的实质运算处理工作，由于采用较为底层的C++语言开发，其运行效率较高；三是渲染绘制部分，比如OpenGLES，通过C++代码调用OpenGLES函数完成图形绘制以及绘制结果提交。虽然这里执行主体采用运行器，但是，由于本申请实施例在运行器中的执行过程与现有的运行器相比，发生了适当变化，因此，在理解该实施例中的执行主体时，不能简单地将该运行器视为与现有技术相同的运行器，准确地说，本实施例中的运行器是能够完成其随后将执行的功能的运行器(即至少能够完成步骤S201、S202)，比如，应当具备识别图形绘制规则指令的能力，依据图形绘制规则指令确定操作对象和操作类型的能力，基于获得的操作对象数据和识别出的操作类型进行操作的能力，以最终完成图形绘制的能力等等。同样地，是否一定称呼其为“运行器”，在具备上述能力的情况下，“运行器”之名对其并不构成理解和运用上的限制。

上述技术方案中提及图形绘制之“图形”的用语，在本实施例中，应当朝着符合行业习惯的更为广泛的角度去理解其含义。通常而言，“图形”可能限于一些几何图形，但实际上，在本实施例中不仅可以包含常规图形、图像等，比如，绘制一个图形，可以是在画布上绘制一个三角形、四边性等，而且还可以是对一个已完成的某个图形进行填色、遮盖等操作，比如，对一个已在某个时刻绘制完成的三角形进行填色，该对三角形填色的过程仍可以独立称为图形绘制。甚至还可以包括对一些非图形进行的处理。比如，在一张画布上布置无数离散的点，虽然其最终可能并不构成某个规范的图形，但该过程仍可称为图形绘制。也就是说，本申请实施例中的图形绘制可能包括一个具体的图形绘制过程，也可能是对已有图形或者非图形进行一定的操作。总而言之，图形绘制过程是对将要显示在画面中目标对象或与显示在画面中的对象关联的目标对象进行某个操作的过程。

上述技术方案中提及“图形绘制规则指令”的用语，这里没有称为“图形绘制指令”，主要原因在于本实施例中是由Web端引擎“制定规则”，而运行器端“实现规则(运行规则)”，进而达到Web端引擎JS代码层面少运算，甚至不运算，而将大量的运算工作交由具有更强运算能力的运行器来完成，从而最终提高图形绘制的整体性能。换句话说，在来自Web端引擎的绘制请求中，包含的图形绘制规则指令是不同于常规图形绘制指令的一条特殊“指令”，它至少负责告诉运行器应当“怎么干”，而不是越俎代庖自己“亲自上”。具体而言，在一条图形绘制规则指令中，指定了该指令确定的运算规则以及运算涉及的数据，前者在本实施例中称为操作类型，后者称为操作对象，当运行器获得这些信息后，将按照操作类型的要求，对操作对象进行操作。

尽管上述对“图形绘制规则指令”做了一定的解释，但由此就将“图形绘制规则指令”理解成不可能为一条具体的图形绘制指令，则亦为错误。也就是说，在某些情况下，图形绘制规则指令可以直接体现为一条具体的图形绘制指令，因而需要结合具体的应用场景来考虑。比如，对某个数据区内的数据执行清除操作，该图形绘制规则指令可以直接表现为一条清除指令。由此，在理解“图形绘制规则指令”的概念时，不在于该规则指令体现为一条规则指令，还是一条具体指令，而在于强调该指令是可以不在Web端引擎执行，而需要到运行器中执行。实际应用过程中，为了表达出这种区别，可以由Web端引擎给“图形绘制规则指令”定义出预定的标识，当Web端引擎“看到”该标识时，便知“此非分内之事”，做出“放行”之举，交由运行器处理。

还需要说明的是，在本实施例中，基于描述需要，在某些地方可能直接使用“图形绘制规则指令”，而在另一些地方，则使用“图形绘制规则指令及作为其参数的预定操作类型和操作对象”，即该概念有时是指代包含其参数在内的整体，有时是指代不包含其参数、仅具有规则部分的局部，实际应用过程中涉及到该概念理解时，不可不结合上下文进行全面的理解。

在上述技术方案中，提及运行器根据图形绘制规则指令以及预定操作类型和操作对象进行操作，以对目标图形进行绘制。这里需要说明的是，运行器完成对操作对象的操作并不一定就意味着目标图形绘制完成。实际上，运行器对操作对象进行操作在大多数情况下，仅能认为是完成其较为核心部分的内容，除此之外，还可能具有一些其他操作，比如，由OpenGLES函数完成与GPU的对接、渲染等。但是，本实施例的重点在于突出运行器相对于现有技术的核心区别，对其他操作进行简略甚至省略介绍，本领域技术人员在阅读本实施例的该步骤时，不可不细查也。

通过上述对技术方案的说明，应能排除对本实施例的理解偏差。本实施例相对于现有技术是一个突破性的发明，其技术效果呈现出如下显著特点：

一是充分利用显卡硬件，实现绘制显示加速。该实施例针对的对象是由JS代码调用WebGL接口形成的项目，由于WebGL是在OpenGLES基础上开发，可以直接操作GPU指令，从而通过显卡实现硬件加速，可以大大提高图形绘制的效率和显示效果。

二是实现Web端引擎与运行器端的“优势互补”，整体性能得以显著提升。一方面，由于接收的绘制请求包含的是图形绘制规则指令和预定操作类型、操作对象，而并非由Web端引擎计算后的现成结果，使得大量运算处理工作由Web端引擎转移到运行器，而运行器由C++引擎框架组成，其计算效率大大高于Web端引擎中JS代码层，由此充分利用了运行器的“运算优势”。另一方面，Web端引擎不再背负过多计算任务，在上层指明运算规则即可，从而增加了Web端引擎的灵活性和扩展性，充分发挥了Web端引擎面向不同引擎商的“包容优势”。基于运行器、Web端引擎“分工明确”，相互“取长补短”，大大提升了基于WebGL的图形绘制性能。

三是贯彻“WebGL+”理念，成功模拟canvas。在运行器运行的项目不再是通过JS语言调用的canvas接口，而是变更为JS语言调用WebGL接口以及webgl扩展函数接口，WebGL的底层性与运行器内的C++引擎框架契合，加快了运行效率。

值得说明的是，现有技术在实现通用运行器的过程中，还存在一种可作为进一步说明本实施例技术效果的技术方案。该方案在绘制3D图形时采用WebGL接口，但在绘制2D图形时采用canvas标准接口，具体方式是上层Web引擎通过调用canvas标准接口调用到运行器中的函数，运行器底层通过OpenGLES模拟canvas接口实现绘制效果，但是，该方案由于使用标准canvas接口，受到canvas接口数量和类别的限制，一些特殊的效果无法支持，且第三方Web引擎由于对其缺乏精准控制，不信任通用运行器中使用OpenGLES模拟的标准canvas接口的做法。在本实施例之下，由于基于WebGL的图形绘制规则指令没有直接进行运算，而是可以在发起图形绘制请求中包含由Web端引擎配置的预定操作类型，这就方便了第三方对图形绘制过程的控制，从而增强信任，有利于拓宽其扩展性。

还值得强调的是，在前述内容中，均是以运行器为主体，基于WebGL的图形绘制过程，但是，上述实施例体现出的思想(Web端引擎制定规则，运行器端运行规则)可以应用在非WebGL场景下，比如，采用传统canvas的情形，因此，本申请还提供另一种实施例，该实例包含的步骤为：接收对目标图形的绘制请求，所述绘制请求中包含图形绘制规则指令以及作为所述图形绘制指令参数的预定的操作类型和操作对象；根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。

在前述实施例中，尽管可以将操作对象直接体现在图形绘制请求之中，但是，这样将使图形绘制请求“臃肿”，尤其在操作对象体现为“量大而结构复杂”的数据时，更为“不堪其重负”，而且，当需要修改图形绘制规则指令时，又需要重新指定操作对象，给系统增加无谓的开销。为此，可以采取一种图形绘制规则指令与其操作对象分离的机制，即在图形绘制请求中包含操作对象的索引，而将索引对应的数据在运行器中临时或长久开辟的数据存储区中进行存储，这样在改变(增加或调整)图形绘制规则指令时，只要操作对象的索引不发生变化，该指令便可不变化，而仅需要修改数据存储区的数据即可。具体做法是：在图形绘制请求中指定操作对象的索引，运行器根据该操作对象索引从数据区中获取其对应的具体操作数据，然后由运行器根据预定的操作类型对该操作数据进行操作，进而完成图形绘制。举如下实例说明之：

假设图形绘制请求中包含如下内容：

SetValueByShareData(offset，operateType)

该内容中“SetValueByShareData”为图形绘制规则指令，“offset”、“operateType”为图形绘制规则指令的参数，前者指明待操作对象在数据区中的位置，后者指明针对该操作对象要进行何种类型的操作。这种情况下，如果offset＝10，operateType为擦除操作，则运行器在运行该规则指令时，先根据offset从数据区中获取偏离值为10位置上对应的数据作为操作对象，然后对该数据执行擦除操作。通过这种数据与指令的分离机制，可以提高操作的便捷性，为进行其他的进一步改进提供了技术保障。

在前述实现图形绘制规则指令与图形绘制规则指令的操作对象的分离(指令与数据分离)机制情景下，维护数据区内的数据便变得至关重要。根据实际情况和不同的划分标准，数据区可以划分为不同的类型。比如，可以划分为全局数据区和局部数据区，前者用于存储带有全局性的数据或者存储中间结果，后者用于存储带有局部性质的数据。当然，在实际应用过程中，这两个数据区可以在物理上为相邻的存储位置，也可以为隔着“千山万水”的不同物理存储位置。无论是全局数据区，还是局部数据区，其当中的数据均可在Web端引擎进行配置，比如在初始化时进行定义，然后在接受到图形绘制请求时或者之前，将这些配置好的数据同步到运行器能够访问的数据区中。比如，可以按照如下的方式配置数据区内的全局数据：

varvalueID＝GL.addValueDefine(modifyType，type，size，defaultData)

定义alpha型数据：type＝float，size＝1，defaultData＝[1]

定义matrix型数据：type＝float，size＝6，defaultData＝[1，0，0，1，0，0]

既然在某些情况下存在全局数据区和局部数据区之别，那么便可能存在只针对全局数据区或局部数据区内数据进行的操作，也可能存在一部分数据来自全局数据区，另一部分数据来自局部数据区，将两者进行某种操作的情况。也就是说，可以仅仅针对同类型的数据区内的数据进行操作，也可以在不同性质的数据区内进行数据操作，比如，图形绘制中涉及到的矩阵计算、顶点计算等情形，在需要对多个数据进行操作时，图形绘制请求中包含的操作对象(操作对象索引)则可能为多个。下面以对全局数据区内的一个数据和局部数据区内的一个数据进行矩阵运算为例进行说明：

图形绘制请求中包含如下内容：

setValueByShareData(id，offset，operateType)

该指令内容的id代表全局数据区的全局索引，假设其值为2，offset代表局部数据区内的局部索引，假设其值为4，如果当前预定的操作类型为矩阵运算，则运行器会首先根据全局数据区的全局索引id指明的位置，从全局数据区id＝2的位置获取第一操作数据，根据局部数据区的局部索引offset指明的位置，从局部数据区offset＝4的位置获取第二操作数据，然后按照operateType指明的操作类型，对第一操作数据和第二操作数据进行矩阵运算。需要强调的是，这些计算在运行器内完成，而运行器包含C++引擎框架，计算效率比现有技术中在Web端引擎高很多。在实际应用过程中，图形绘制中涉及大量的矩阵运算，通过在运行器内计算而得以大大节约处理资源。

实际上，除了矩阵运算外，图形绘制过程中涉及的操作类型还包括常规的加、减、乘、除以及顶点变形等运算类型。比如，对于图形绘制中的大量的顶点数据，可以采取上述运算中的一种来完成运算。举例如下：

modifyMesh(valueID，vdoPosID，operatorType)

该指令内容表示使用全局数据区中valueID指明的某个数据修改顶点缓冲数据区中vdoPosID指明的显卡顶点缓冲区内的某个数据，按照operatorType指定操作类型进行计算。

假设使用全局数据区中valueID＝2对应的数据，去修改顶点缓冲数据区中的vdoPosID＝0(顶点的x、y坐标)对应的数据，操作方式是矩阵变形顶点数据。该运算在运行器的C++中的代码中运算，大为提高效率。

在前述各个实施例的说明中，没有特别限定图形绘制请求中包含的图形绘制规则指令是一条图形绘制指令，还是多条图形绘制指令。如果在图形绘制请求中包含多条绘制指令，则构成图形绘制规则指令集。这些指令集在运行器内可以逐条予以执行，也可以多条同步执行。由于最终需要将执行结果提交给OpenGLES进行渲染，当对多条指令集采取不同执行方式时，则面临如何提交执行结果的问题。尽管完全可以采取逐条图形绘制规则指令执行完后即可提交的方式，但是，由于执行绘制次数较多，将可能导致提交次数也相当大，这将浪费过多的通知资源(每次提交时，均需要向上层报告)，因而，为便于节约资源，可以采取合并提交的形式进行，从而能够减少通知资源的消耗。合并需要按照一定规则将确实能够合并且有必要合并提交的，才进行合并提交操作，对于其他的情形，则仍按照逐条提交的方式进行。在实务过程中，该规则可以设定为判断对操作对象进行操作的着色器、着色器参数、纹理参数、渲染状态中的至少一个是否相同，如果相同，则对相同的多个操作结果进行合并提交显卡渲染。在对效率要求较高、数据量特别大的情况下，可以根据情况设定上述四个要素及其类似要素同时满足或更多的要素得以满足时，才进行合并提交操作。

与前述讨论操作对象类似的道理，在图形绘制请求中可以包含图形绘制规则指令本身，也可以包含图形绘制规则指令的索引，这样运行器便可以根据所述绘制请求中包含的所述图形绘制规则指令索引，确定与该图形绘制规则指令索引对应的图形绘制规则指令集，具体而言：

运行器根据图形绘制请求中包含的图形绘制规则指令索引，从存储设备中查找与图形绘制规则指令索引对应的指令集，所述存储设备中存储有不同的图形绘制规则指令索引以及与不同的图形绘制规则指令索引对应的指令集。

在实际应用过程中，可以预先将用于绘制所述目标图形的多条规则指令整合成一个指令集，并将该指令集与图形绘制规则指令索引对应存储在存储设备中，这样，在接收到所述图形绘制请求后，可以根据图形绘制规则指令索引在所述存储设备中查找与图形绘制规则指令索引对应的指令集。

在本申请实施例中，为了便于对不同的目标图形进行绘制，可以按照上述记载的方法确定对不同的目标图形进行绘制的多个规则指令集，并将该多个规则指令集与图形绘制规则指令索引对应存储至所述存储设备中，这样，在绘制不同的目标图形时，可以从所述存储设备中查找得到与不同的图形绘制规则指令索引对应的指令集。

需要说明的是，所述存储设备可以是系统内存，也可以是运行器中用于存储数据的空间，这里不做具体限定。其中，针对运行器而言，所述存储设备中存储的指令集和图形绘制规则指令索引可以在所述运行器中的JS引擎以及C++引擎框架之间数据共享。这样，在绘制所述目标图形时，由于图形绘制规则指令索引对应的所述指令集在所述JS引擎和C++引擎框架中数据共享，因此，JS引擎可以只进行一次函数调用，即只调用一次接口，并告知C++引擎框架执行所述指令集便可完成图形绘制。

在本申请提供的一个实施例中，如前所述，图形绘制规则指令集中可以直接包含操作对象，也可以包含操作对象的索引。在直接包含操作对象的情况下，该操作对象数据可以用于与所述指令集中包含的多条指令相结合，共同绘制得到所述目标图形，例如，所述操作对象数据可以是目标图形的位置、大小等。在根据所述指令集中包含的多条指令，对所述目标图形进行绘制时，可以根据所述指令集中包含的多条指令以及操作对象数据，对所述目标图形进行绘制。

具体地，运行器在根据所述指令集中包含的多条指令以及操作对象数据绘制所述目标图形时，JS引擎可以只调用一次接口，告知C++引擎框架可以根据所述指令集绘制所述目标图形，此时，C++引擎框架可以直接从共享的所述存储设备中调用所述指令集，并根据所述指令集中包含的多条指令以及操作对象数据完成所述目标图形的绘制。由于JS引擎只需要一次调用就可以完成一次图形绘制，因此，可以有效提高运行器的运行效率。

在本实施例中，当JS引擎需要对指令集中的操作对象数据进行修改时，由于所述存储设备中存储的指令集在JS引擎以及C++引擎框架之间数据共享，因此，JS引擎可以直接修改所述指令集中的操作对象数据，无需进行其他操作，在绘制图形时，C++引擎框架可以直接使用修改后的指令集进行图形绘制，可以在指令集修改的情况下实现高效率绘图。

在本申请的另一个实施例中，考虑到在对所述指令集中包含的指令增加或删除时，需要为所述指令集重新分配存储空间。最重要的是在应用中，目标图形对应的指令集类型变化的频率非常低，但是该目标图形对应的数据区变化频率非常高(例如：游戏中的角色移动时，角色的坐标一直在变化，即该角色对应的数据区一直在变化，但是该角色对应的指令集却没有变化)，因此，为了提高效率，以及减少所述指令集占用的存储空间，可以如前述内容所描述，将所述指令集中包含的所述操作对象数据(比如：位置、大小)与所述指令集中包含的指令分离，即所述指令集中可以不包含所述操作对象数据，而是将所述指令集中的操作对象数据以数据区的形式与所述指令集对应存储。同时，为了便于将所述数据区中的操作对象数据与所述指令集相结合进而对目标图形进行绘制，所述指令集中可以包含操作对象索引，所述数据区中可以包含与所述操作对象索引对应的操作对象数据，这样，可以根据所述指令集中包含的所述操作对象索引从所述数据区中查找对应的操作对象数据，并根据查找的操作对象数据以及所述指令集绘制目标图形。

例如，指令集A中包含操作对象索引M，指令集A对应的数据区1中包含操作对象索引1到N对应的N个操作对象数据，其中N大于M，这样，可以根据操作对象索引M从数据区1中查找第M个操作对象数据，第M个操作对象数据可以与指令集A相结合绘制得到目标图形。

需要说明的是，由于所述规则指令集中可以包含多条指令，每一条指令可以包含操作对象数据，因此，所述指令集中包含的操作对象索引的个数可以是多个，与所述指令集对应的所述数据区中可以包含与每一个所述操作对象索引对应的操作对象数据。为了便于描述，本申请实施例可以以所述指令集中包含一个操作对象索引为例进行说明。

还需要说明的是，所述数据区可以存储至前述所言的存储设备中，这样，所述数据区中包含的操作对象数据也可以在JS引擎以及C++引擎框架之间数据共享。

在本实施例中，针对一个所述指令集而言，所述指令集可以对应一个数据区，所述数据区与所述指令集结合可以用于绘制得到一个目标图形；此外，所述指令集也可以对应多个数据区，每一个所述数据区与所述指令集相结合后，可以用于绘制得到不同的目标图形，即多个不同的目标图形可以共同使用一个指令集进行目标图形的绘制，这样，由于多个目标图形可以根据同一个指令集绘制得到，因此，可以有效减少存储的指令集的个数，从而有效减少指令集对存储空间的占用。

例如，指令集A可以对应数据区1和数据区2，根据指令集A和数据区1中的操作对象数据，可以绘制得到目标图形A1，根据指令集A和数据区2中的操作对象数据，可以绘制得到目标图形A2。由于目标图形A1和A2均可以根据指令集A绘制得到，因此，可以减少指令集的个数，从而减少指令集占用的存储空间。

基于本实施例中指令集与数据区分开存储的设计，在根据所述指令集中包含的多条指令，对所述目标图形进行绘制时，可以包括：

从所述存储设备中查找与所述指令集对应的其中一个所述数据区；

根据所述指令集中包含的操作对象索引，从查找到的所述数据区中确定与所述操作对象索引对应的操作对象数据；

根据所述操作对象数据以及所述指令集中包含的多条指令，对所述目标图形进行绘制。

具体地，运行器中的JS引擎可以根据实际绘制需求确定与所述指令集对应的一个数据区，并通过一次接口调用告知C++引擎使用所述指令集以及所述数据区进行图形绘制，此时，C++引擎框架可以根据所述指令集中包含的操作对象索引，从所述存储设备中的所述数据区中查找与所述操作对象索引对应的操作对象数据，并将该操作对象数据与所述指令集中包含的多条指令相结合，最终可以绘制得到所述目标图形。

例如，JS引擎在确定用于绘制目标图形的指令集A后，根据实际绘制需求从所述存储设备中确定与指令集A对应的数据区1后，可以将指令集A以及数据区1通过调用一次接口告知C++引擎框架，此时，C++引擎框架可以根据指令集A中包含的操作对象索引M，从数据区1中查找到与操作对象索引M对应的操作对象数据x，C++引擎框架在确定指令集A以及对应的操作对象数据x后，可以将指令集A与操作对象数据x相结合进而绘制得到所述目标图形。

在本实施例中，考虑到所述目标图形在显示时可能存在多种不同的显示状态，因此，在将多条指令整合成指令集，并以此方法得到多个指令集后，还可根据所述目标图形不同的显示状态，将多个所述指令集进行分类，不同类型的所述指令集可以视为一个指令集模板，不同的指令集模板可以对应目标图形不同的显示状态。

在得到多个不同类型的指令集模板后，根据所述指令集中包含的多条指令，对所述目标图形进行绘制，可以包括：

当所述目标图形的显示状态发生变化时，确定与所述目标图形变化后的显示状态对应的指令集；

根据所述指令集中包含的多条指令，对所述目标图形进行绘制。

具体地，基于多个不同类型的指令集模板，在绘制所述目标图形的过程中，若所述目标图形在前后两帧的显示状态发生变化，则可以根据变化后的显示状态确定与变化后的显示状态对应的指令集(即上述记载的所述指令集模板)，进而根据该指令集对所述目标图形进行绘制，以得到不同显示状态的所述目标图形。其中，在根据不同的指令集模板绘制不同显示状态的所述目标图形时，使用的数据区可以保持不变。

例如，在绘制第一帧的目标图形时，所述目标图形是正常的显示状态，此时，可以根据该正常的显示状态对应的指令集A和数据区1绘制得到所述目标图形；在绘制第二帧的所述目标图形时，所述目标图形增加了缩放状态，那么，可以确定与缩放状态对应的指令集B，并根据指令集B以及数据区1绘制得到增加了缩放状态的所述目标图形。

这样，在所述目标图形的显示状态发生变化时，由于可以根据所述目标图形不同的显示状态随意切换不同的指令集，因此，可以提到图形绘制的效率，针对运行器而言，可以提高运行器的运行效率。

本申请实施例提供的技术方案，可以实现对一帧应用中的每一个目标图形进行绘制，其中，在对每一个目标图形进行绘制时，通过将多条指令整合为一个指令集，可以使得运行器中的JS引擎直接调用指令集进行图形绘制，相较于现有技术而言，由于JS引擎由调用多次指令进行图形绘制改为调用一次指令集进行图形绘制，因此，可以减少JS到C++代码的调用次数，提高运行器的运行效率。

在本申请的另一实施例中，在对应用中包含的多个所述目标图形进行绘制时，可以根据上述记载的方法确定与每一个所述目标图形对应的指令集，并根据确定的所述指令集完成对多个所述目标图形的绘制。然而，在实际应用中，如果一帧应用(例如：游戏中的界面)中包含的目标图形的个数比较多，例如5000或10000个，那么，在绘制多个所述目标图形时，针对多帧应用而言，每帧应用都需要循环遍历多个所述目标图形，导致图形绘制的效率比较低，运行器的运行效率低下。

为了解决上述问题，在绘制多帧连续的应用时，针对每一帧应用而言，可以建立所述应用中的多个所述目标图形的第一树形结构，其中，所述第一树形结构中可以包含多个节点，每一个所述节点可以分别对应其中一个所述目标图形。

若下一帧应用的第一树形结构中，只要父子级关系未发生变化则可以直接将上一帧应用中父子级关系未发生变化的节点对应的所述目标图形的绘制数据复制到下一帧应用的所述目标图形的绘制数据中，以便对下一帧所述应用中的所述目标图形进行绘制。因为采用上述记载的指令集和数据区分离方案以及指令集模板方案，因此，即使指令集标示类型和数据区发生变化(比如：位置、旋转、缩放)，也可以直接将上一帧数据直接拷贝到下一帧数据中。这样，由于可以直接将上一帧应用中的一部分绘制数据直接复制到下一帧应用中，减少了循环遍历的次数，因此，可以减少绘制应用所需的时间，提高运行器的运行效率。

如图3所示，图3中第一树形结构包括节点A至K，节点A至K为一帧应用中包含的11个目标图形对应的节点，在绘制完成上一帧应用后，已知下一帧应用中节点B、D、E、F、G、G和I(图3中用灰色进行标记)的父子级关系没有发生变化，且节点B、D、E、F、G、G和I对应的目标图形的渲染类型也没有发生变化，则在绘制下一帧应用时，可以直接将上一帧中节点B、D、E、F、G、G和I的绘制数据直接复制到下一帧应用的绘制数据中，无需循环遍历节点B、D、E、F、G、G和I。

需要说明的是，上述记载的建立第一树形结构是针对运行器中的JS引擎而言，可以避免JS引擎循环便利多次应用中包含的目标图形，由于JS引擎对JS语言的解析执行效率比较低，通过在JS引擎中建立第一树形结构，可以有效提高运行器的运行效率。

在本申请提供的又一实施例中，基于上述JS引擎中建立的第一树形结构，还可以在运行器的C++引擎架构中建立相应的第二树形结构，以提高C++引擎架构对C++语言的执行效率。具体地：

在绘制连续多帧应用时(每一帧应用均包含多个目标图形)，C++引擎架构可以针对包含多个目标图形的每一帧应用分别建立第二树形结构，所述第二树形结构中可以包含多个节点，每一个所述节点可以分别对应一帧应用中包含的其中一个所述目标图形。

需要说明的是，所述第二树形结构中的“第二”与所述第一树形结构中的“第一”只是为了便于区别在C++引擎框架以及在JS引擎中建立的树形结构，没有其他特殊含义，其中，所述第二树形结构可以与所述第一树形结构对等，即所述第二树形结构中包含的多个节点的连接方式可以与所述第一树形结构中包含的多个节点的连接方式相同。

在C++引擎架构中建立所述第二树形结构后，可以确定所述第二树形结构中包含的每一个节点对应的指令集。具体地，可以确定每一个节点对应的目标图形，根据所述目标图形的图形标识，通过上述记载的内容，确定得到每一个所述目标图形对应的指令集，进而确定得到每一个节点对应的指令集。

在确定与每一个节点对应的指令集后，可以根据每一个所述节点对应的指令集，通过接口调用对应的指令集对每一个所述节点进行绘制，以对所述应用中包含的多个所述目标图形进行绘制。

需要说明的是，如前所述，所述指令集中可以包含操作对象数据，也可以不包含操作对象数据，这样，针对包含操作对象数据的指令集而言，可以通过上述记载的方法对所述第二树形结构中包含的每一个节点进行绘制，进而实现对应用的绘制。针对不包含操作对象数据的指令集而言，在确定每一个节点对应的指令集后，还需要进一步确定所述指令集对应的数据区，并通过接口调用对应的指令集以及数据区对每一个所述节点进行绘制，以对所述应用中包含的多个所述目标图形进行绘制。

这样，C++引擎框架在绘制连续多帧应用时，可以循环遍历每帧应用对应的所述第二树形结构，并将每个节点按照指令集或指令集以及数据区进行绘制，可以提高图形绘制效率，进而提高运行器的运行效率。

如图4所示，图4中第二树形结构包括节点A至E，节点A至E为一帧应用中包含的5个目标图形对应的节点，其中，已知节点a对应指令集A以及数据区1，节点b对应指令集B以及数据区2，节点c对应指令集C以及数据区3，节点d对应指令集C以及数据区4，节点e对应指令集B以及数据区5。这样，在绘制该帧应用时，可以按照每个节点对应的指令集以及数据区对每个节点进行绘制，进而对一帧应用进行绘制。由于每帧应用都可以建立一个树形结构，因此，每一帧应用都可以循环遍历树形结构，进而实现多个应用的绘制，有效提高运行器的运行效率。

图5为本申请的一个实施例图形绘制装置的结构示意图。所述图形绘制装置包括：接收单元51和绘制单元52，其中：

接收单元51，用于接收对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象；

绘制单元52，用于根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制。

上述装置能够取得与前述方法实施例同样的技术效果，为避免重复，这里不再赘言。

可选地，在操作对象为操作对象索引的情况下，则绘制单元52包括确定子单元521和绘制子单元522，其中：

数据获取子单元521，用于根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据；

绘制子单元522，用于根据所述图形绘制规则指令按照所述预定操作类型对所述操作数据进行操作。

在前述的基础之上，数据区可以具体包括全局数据区和局部数据区，所述操作对象索引包括全局数据区内第一操作数据的全局索引和局部数据区内第二操作数据的局部索引，则：

数据获取子单元521，具体用于根据所述全局索引从全局数据区获取第一操作数据；根据所述局部索引从局部数据区内获取第二操作数据；

绘制子单元522，具体用于根据所述图形绘制规则指令按照所述预定操作类型对第一操作数据和第二操作数据进行操作。

可选地，所述绘制单元52在对应用中包含的多个所述目标图形进行绘制时，建立所述应用中的多个所述目标图形的第一树形结构，所述第一树形结构中包含多个节点，每一个所述节点分别对应其中一个所述目标图形；

若上一帧应用的所述第一树形结构中存在多个节点的父子级关系未发生变化，则将所述上一帧所述应用中父子级关系未发生变化的节点对应的所述目标图形的绘制数据复制到下一帧应用的所述目标图形的绘制数据中，以对所述下一帧应用中的所述目标图形进行绘制。

可选地，所述绘制单元52针对每一帧所述应用建立第二树形结构，所述第二树形结构中包含多个节点，每一个所述节点分别对应所述应用中包含的其中一个所述目标图形；

确定所述第二树形结构中包含的每一个节点对应的指令集；

根据每一个所述节点对应的指令集，对每一个所述节点进行绘制，以对所述应用中包含的多个所述目标图形进行绘制。

图6为本申请的一个实施例运行器的结构示意图，所述运行器50中包含存储器61、处理器62及存储在所述存储器61上并可在所述处理器62上运行的计算机程序，所述计算机程序被所述处理器62执行时实现上述记载的图形绘制方法的步骤。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述记载的图形绘制方法的步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (11)

1.一种基于WebGL的图形绘制方法，其特征在于，包括：

运行器接收来自Web端引擎的对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象，所述图形绘制规则指令指定了由Web端引擎制定的运算规则以及运算涉及的数据，所述运算规则为预定操作类型，所述运算涉及的数据为操作对象，所述图形绘制规则指令不在Web端引擎执行；所述运行器具备识别图形绘制规则指令的能力、依据图形绘制规则指令确定操作对象和操作类型的能力，以及基于确定出的操作对象和操作类型进行操作的能力；所述运行器的运行需要Web端引擎的配合；

运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制；

所述操作对象为操作对象索引，则运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：

运行器根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据；

运行器根据所述图形绘制规则指令按照所述预定操作类型对所述操作数据进行操作。

2.如权利要求1所述的方法，其特征在于，所述数据区包括全局数据区和局部数据区，所述操作对象索引包括全局数据区内第一操作数据的全局索引和局部数据区内第二操作数据的局部索引，则运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：

运行器根据所述全局索引从全局数据区获取第一操作数据；根据所述局部索引从局部数据区内获取第二操作数据；

运行器根据所述图形绘制规则指令按照所述预定操作类型对第一操作数据和第二操作数据进行操作。

3.根据权利要求2所述的方法，其特征在于，所述全局数据区由Web端引擎设置，在图形绘制之前或之时由Web端引擎同步到运行器的数据区。

4.根据权利要求1所述的方法，其特征在于，所述基于WebGL的图形绘制规则指令为包含至少一条图形绘制规则指令的图形绘制规则指令集，所述图形绘制规则指令集中各条图形绘制规则指令均具有对应的预定操作类型和操作对象，则运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制，包括：

运行器根据图形绘制规则指令集内的每条所述图形绘制规则指令以及该条图形绘制规则指令对应的预定操作类型对相应的操作对象进行操作；

运行器根据预定规则对多个操作结果进行合并提交操作，以对所述目标图形进行绘制；所述预定规则包括判断对操作对象进行操作的着色器、着色器参数、纹理参数、渲染状态中的至少一个是否相同，如果相同，则对相同的多个操作结果进行合并提交。

5.根据权利要求1所述的方法，其特征在于，所述基于WebGL的图形绘制规则指令为图形绘制规则指令索引，则运行器根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，包括：

运行器根据所述绘制请求中包含的图形绘制规则指令索引，确定与所述图形绘制规则指令索引对应的图形绘制规则指令集，所述指令集中包含对所述目标图形进行绘制的多条图形绘制规则指令；

根据所述指令集中包含的多条图形绘制规则指令以及各图形绘制规则指令对应的预定操作类型对各自相应的操作对象进行操作。

6.如权利要求1所述的方法，其特征在于，所述方法还包括：

在对应用中包含的多个所述目标图形进行绘制时，建立所述应用中的多个所述目标图形的第一树形结构，所述第一树形结构中包含多个节点，每一个所述节点分别对应其中一个所述目标图形；

若上一帧应用的所述第一树形结构中存在多个节点的父子级关系未发生变化，则将所述上一帧所述应用中父子级关系未发生变化的节点对应的所述目标图形的绘制数据复制到下一帧应用的所述目标图形的绘制数据中，以对所述下一帧应用中的所述目标图形进行绘制。

7.如权利要求6所述的方法，其特征在于，所述方法还包括：

针对每一帧所述应用建立第二树形结构，所述第二树形结构中包含多个节点，每一个所述节点分别对应所述应用中包含的其中一个所述目标图形；

确定所述第二树形结构中包含的每一个节点对应的图形绘制规则指令集；

根据每一个所述节点对应的图形绘制规则指令集，对每一个所述节点进行绘制，以对所述应用中包含的多个所述目标图形进行绘制。

8.一种基于WebGL的图形绘制装置，其特征在于，包括：

接收单元，用于接收来自Web端引擎的对目标图形的绘制请求，所述绘制请求中包含基于WebGL的图形绘制规则指令以及作为所述图形绘制规则指令参数的预定操作类型和操作对象，所述图形绘制规则指令指定了由Web端引擎制定的运算规则以及运算涉及的数据，所述运算规则为预定操作类型，所述运算涉及的数据为操作对象，所述图形绘制规则指令不在Web端引擎执行；所述装置具备识别图形绘制规则指令的能力、依据图形绘制规则指令确定操作对象和操作类型的能力，以及基于确定出的操作对象和操作类型进行操作的能力；所述装置的运行需要Web端引擎的配合；

绘制单元，用于根据所述图形绘制规则指令以及所述预定操作类型对所述操作对象进行操作，以对所述目标图形进行绘制；

所述操作对象为操作对象索引，则所述绘制单元包括数据获取子单元和绘制子单元，其中：

所述数据获取子单元，用于根据所述操作对象索引从数据区中获取所述操作对象索引对应的操作数据；

所述绘制子单元，用于根据所述图形绘制规则指令按照所述预定操作类型对所述操作数据进行操作。

9.如权利要求8所述的装置，其特征在于，所述数据区包括全局数据区和局部数据区，所述操作对象索引包括全局数据区内第一操作数据的全局索引和局部数据区内第二操作数据的局部索引，则：

所述数据获取子单元，具体用于根据所述全局索引从全局数据区获取第一操作数据；根据所述局部索引从局部数据区内获取第二操作数据；

所述绘制子单元，具体用于根据所述图形绘制规则指令按照所述预定操作类型对第一操作数据和第二操作数据进行操作。

10.一种运行器，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至7中任一项所述的方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法的步骤。