一种数据流处理方法、设备及存储介质与流程

本申请涉及数据处理技术领域，尤其涉及一种数据流处理方法、设备及存储介质。

背景技术：

在网络通信过程中，网络数据的传输需要消耗传输资源，很多情况下，传输资源都是收费的，因此，为了节省传输成本，可对网络数据进行压缩后再传输。

目前，在四层网络协议下，由于无法感知应用层传输协议，因此通常采用无条件压缩的方式，也即是压缩速度与发送端的数据发送速度一致。这虽然可保证数据流传输的实时性，但是数据流几乎是无缓冲的，导致压缩率比较低。因此，这种压缩方式仅对实时性要求高的数据流比较友好，而对大数据量传输型数据流的压缩效果则不佳，导致压缩效果并不稳定。

技术实现要素：

本申请的多个方面提供一种数据流处理方法、设备及存储介质，用以提高数据流压缩效果的稳定性。

本申请实施例提供一种数据流处理方法，包括：

响应于发送端的数据流转发请求，从所述发送端读取数据至数据缓冲区；

对所述数据缓冲区中的待处理数据进行缓冲状态检测；

若确定所述待处理数据的缓冲状态达到预设的数据量条件和/或缓冲时间条件，则对所述待处理数据进行压缩；

将压缩后的待处理数据转发至接收端。

本申请实施例还提供一种网关设备，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

响应于发送端的数据流转发请求，通过所述通信组件从所述发送端读取数据至数据缓冲区；

对所述数据缓冲区中的待处理数据进行缓冲状态检测；

若确定所述待处理数据的缓冲状态达到预设的数据量条件和/或缓冲时间条件，则对所述待处理数据进行压缩；

通过所述通信组件将压缩后的待处理数据转发至接收端。

本申请实施例还提供一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的数据流处理方法。

在本申请实施例中，可对数据缓冲区中的待处理数据进行缓冲状态的检测，若待处理数据的缓冲状态已经达到了预设的数据量条件和/或缓冲时间条件，则启动对待处理数据的压缩。据此，本申请实施例中，可通过对数据缓冲区中待处理数据的缓冲状态进行检测，间接识别出待处理数据的压缩需求，从而自适应地为不同的数据流适配符合其压缩需求的压缩启动时机，避免过早或过晚压缩导致的实时性不足和/或压缩率过低等问题，进而可在不同压缩需求下获得所需的压缩效果。

附图说明

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

图1a为本申请一示例性实施例提供的一种数据流处理方法的流程示意图；

图1b为本申请一示例性实施例提供的一种数据流处理方法的逻辑示意图；

图2为本申请一示例性实施例提供的一种对待处理数据进行压缩的实现方式的逻辑示意图；

图3为本申请一示例性实施例提供的另一种对待处理数据进行压缩的实现方式的逻辑示意图；

图4为本申请一示例性实施例提供的又一种对待处理数据进行压缩的实现方式的逻辑示意图；

图5为本申请一示例性实施例提供的一种多工作模式方案的逻辑示意图；

图6为本申请又一示例性实施例提供的一种网关设备的结构示意图。

具体实施方式

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

目前，在四层协议下，无条件压缩方式仅对实时性要求高的数据流比较友好，而对大数据量传输型数据流的压缩效果则不佳，导致压缩效果并不稳定。为此，本申请的一些实施例中：可对数据缓冲区中的待处理数据进行缓冲状态的检测，若待处理数据的缓冲状态已经达到了预设的数据量条件和/或缓冲时间条件，则启动对待处理数据的压缩。据此，本申请实施例中，可通过对数据缓冲区中待处理数据的缓冲状态进行检测，间接识别出待处理数据的压缩需求，从而自适应地为不同的数据流适配符合其压缩需求的压缩启动时机，避免过早或过晚压缩导致的实时性不足和/或压缩率过低等问题，进而可在不同压缩需求下获得所需的压缩效果。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1a为本申请一示例性实施例提供的一种数据流处理方法的流程示意图，图1b为本申请一示例性实施例提供的一种数据流处理方法的逻辑示意图。该方法可由数据流处理装置执行，该数据流处理装置可实现为软件和/或硬件的结合，该数据流处理装置可集成在网关设备中。参考图1a和1b，该方法包括：

步骤100、响应于发送端的数据流转发请求，从发送端读取数据至数据缓冲区；

步骤101、对数据缓冲区中的待处理数据进行缓冲状态检测；

步骤102、若确定待处理数据的缓冲状态达到预设的数据量条件和/或缓冲时间条件，则对待处理数据进行压缩；

步骤103、将压缩后的待处理数据转发至接收端。

本实施例提供的数据流处理方法，可适用于四层协议下的数据传输场景，当然，还可适用于其它无法感知应用层传输协议的网络体系中。其中，四层协议可以是支持总体分为四层的网络协议，四层协议可分为应用层、运输层、网络层和链路层。采用四层协议的网络体系可包括但不限于tcp/ip等。在四层协议下，网关设备是无法感知到应用层传输协议的，这导致网关设备需要对数据流进行盲压缩，例如，前文中提及的无条件压缩等。但盲压缩经常导致过早压缩或者过晚压缩，而过早压缩的压缩率将不足，过晚压缩有可能使实时性变差，所以目前对数据流的压缩效果并不稳定。

为此，本实施例提出了一种数据流处理方案，以解决数据流压缩效果的稳定性问题，可自适应地为不同的压缩需求提供不同的压缩方案。

在本实施例中，步骤100中，可响应于发送端的数据流转发请求，从发送端读取数据至数据缓冲区。其中，发送端可以是指具有数据转发需求的网络端，例如，数据库、源服务器等。与发送端相对应的是接收端，接收端是指需要从发送端获取数据流的网络端。本实施例中，可为发送端和接收端分别配置网关设备，并在网关设备中进行数据流的压缩或解压缩。值得说明的是，本实施例中，主要针对发送端侧的网关设备，阐述对数据流的压缩方案。

本实施例中，数据缓冲区用于缓冲数据流。这里，可为不同的接收端，个性化定制数据缓冲区，也即是，为不同的接收端分别配置数据缓冲区，且不同接收端对应的数据缓冲区的规格、数据量条件、缓冲时间条件等可不完全相同。实际应用中，接收端可提供定制需求，并在定制需求中配置所需的数据缓冲区的规格、数据量条件、缓冲时间条件等信息，本实施例中，可基于接收端的定制需求，为接收端配置所需的数据缓冲区以及数据量条件和/或缓冲时间条件。

发送端发送的数据流可写入至数据缓冲区。发送端发送的数据流中写入至数据缓冲区中的数据，本文中称为待处理数据。参考图1b，实际应用中，可启动协程r1，从发送端读取数据并写入数据缓冲区。

在步骤101中，可对数据缓冲区中的待处理数据进行缓冲状态的检测。参考图1b，实际应用中，可启动协程r2，对待处理数据进行缓冲状态的检测。其中，对待处理数据的缓冲状态的检测可包括但不限于以下几个方面：

检测待处理数据处于无新增状态的持续时间；

检测待处理数据的数据量；和/或

检测待处理数据的缓冲时间。

应当理解的是，本实施例中并不限定上述这几个方面的检测顺序。

基于待处理数据的缓冲状态，在步骤102中，可判断待处理数据的缓冲状态是否达到了预设的数据量条件和/或缓冲时间条件，以确定是否启动对待处理数据的压缩操作。其中，数据量条件可包括但不限于累积数据量超过预置数据量阈值；缓冲时间条件可包括但不限于缓冲时间超过第一时间阈值和/或处于无新增状态的持续时间超过第二时间阈值。

也即是，可对待处理数据的缓冲状态进行以下几个方面的条件判断：

a、待处理数据的缓冲时间是否超过第一时间阈值；

b、待处理数据处于无新增状态的持续时间是否超过第二时间阈值；和/或

c、待处理数据的累积数据量是否超过预置数据量阈值。

本实施例中，上述几个方面的条件判断中，任意详细判断结果为是的情况下，可触发启动对待处理数据的压缩操作。另外，本实施例中，可周期性地对待处理数据的缓冲状态进行条件判断，例如，可通过前述的协程r2每隔10ms执行一次条件判断。

其中，若待处理数据处于无新增状态的持续时间已经超过第二时间阈值，则表征数据流发送完成。例如，数据缓冲区中已经超过10ms无新增数据，则表征数据发送完成。基于此，无需感知应用层传输协议，即可及时发现数据流已经发送完成，避免盲等，从而及时完成压缩及转发操作。

若待处理数据的累积数据量已经超过预置数据量阈值，则表征数据流的数据量较大。基于此，可间接识别出该数据流可能是大数据量传输型数据流，其压缩需求可能是期望更高的压缩率。例如，待处理数据的累积数量已经超过64kb，可启动压缩操作，对64kb的数据量进行压缩可获得较高的压缩率。正如上文提及的，不同接收端可定制不同的数据量阈值，对于大数据量传输型数据流较多的接收端，可将数据流阈值设定的更高一些，并且，还可通过设定第一时间阈值来兼顾数据流的传输实时性，当然，这种情况下，第一时间阈值可设定的更大一些，以降低传输实时性要求。

若待处理数据的缓冲时间已经超过第一时间阈值，则表征数据流的缓冲时间较短。基于此，可间接识别出该数据流可能是延时敏感型的数据流，其压缩需求可能是期望更高的传输实时性。例如，待处理数据的缓冲时间已经超过50ms，可启动压缩操作，最多50ms进行一次压缩可获得较高的传输实时性。正如上文提及的，不同接收端可定制不同的第一时间阈值，对于延时敏感型的数据流较多的接收端，可将第一时间阈值设定的更小一些，并且，还可通过设定前述的数据量预置来兼顾数据流的压缩率。当然，这种情况下，数据量阈值可设定的更小一些，以降低压缩率要求；也可设置的足够大，以通过第一时间阈值来保证传输实时性。

因此，通过上述a和c方面的条件判断，可降低由于压缩操作导致的延时，从而保证延时敏感型数据流获得更高的传输实时性，而通过上述b方面的条件判断，则可等待更多数据写入数据缓冲区，从而保证大数据量传输型数据流获得更高的压缩率。这样，不同类型的数据流可获得所需的压缩效果，也即是，对于不同压缩需求，可适应地适配符合压缩需求的压缩启动时机，从而获得所需的压缩效果。

在步骤103中，可将压缩后的待处理数据转发至接收端。

据此，本实施例中，可在无法感知应用层传输协议的网络体系下，读取发送端的数据流并写入至数据缓冲区；对数据缓冲区中的待处理数据进行缓冲状态的检测，若待处理数据的缓冲状态已经达到了预设的数据量条件和/或缓冲时间条件，则启动对待处理数据的压缩。据此，本实施例中，可通过对数据缓冲区中待处理数据的缓冲状态进行检测，间接识别出待处理数据的压缩需求，从而自适应地为不同的数据流适配符合其压缩需求的压缩启动时机，避免过早或过晚压缩导致的实时性不足和/或压缩率过低等问题，进而可在不同压缩需求下获得所需的压缩效果。

在上述或下述实施例中，可采用多种实现方式对待处理数据进行压缩。

图2为本申请一示例性实施例提供的一种对待处理数据进行压缩的实现方式的逻辑示意图。在该实现方式中，数据缓冲区可包括头端和尾端，在对待处理数据进行压缩的过程中，可从数据缓冲区中读取待处理数据；对待处理数据进行压缩；从数据缓冲区的头端开始，将压缩后的待处理数据写入数据缓冲区。

在该实现方式中，从发送端读取的数据可从数据缓冲区的头端开始，顺序写入数据缓冲区，前述的协程r1可记录从发送端读取的数据在数据缓冲区中的写入位置。若协程r2检测到数据缓冲区中的待处理数据达到了压缩触发时机，则可对待处理数据进行压缩，例如，若待处理数据在数据缓冲区中的缓冲区间为0-64kb，则可对待处理数据进行压缩，腾出缓冲区间0-64kb，并记录当前的写入位置已到达64kb，后续从发送端读取的数据则从64kb开始接续写入数据缓冲区。协程r1可持续向数据缓冲区写入数据，直至发送端的数据流发送完成或者数据缓冲区写满，而不受协程r2的影响。而压缩后的待处理数据，则从数据缓冲区的头端开始写入，例如，压缩后的待处理数据在数据缓冲区中占用的缓冲区间为0-30kb(小于64kb)，压缩后的待处理数据被转发后，可腾出缓冲区间0-30kb。随着协程r1向数据缓冲区写入数据，协程r2继续判断新写入的数据是否达到了压缩触发时机，例如，写入位置到达85kb是达到压缩触发时机，则对65kb-85kb的缓冲区间中的数据进行压缩，并将压缩后的数据从数据缓冲区的头端开始写入，例如，压缩后的数据在数据缓冲区中占用的缓冲区间为0-15kb(小于20kb)，压缩后的5理数据被转发后，可腾出缓冲区间0-15kb。

在该实现方式中，若从发送端读取的数据已写至数据缓冲区的尾端，则对数据缓冲区中的待处理数据进行压缩；在将压缩后的待处理数据转发完成后，继续从数据缓冲区的头部开始写入从发送端读取的数据。也即是，若数据缓冲区以被写满，即使数据缓冲区中的待处理数据的缓冲状态未达到前述的数据量条件和缓冲时间条件，则也将触发启动压缩操作。这样，数据缓冲区被写满，也将作为一种压缩触发时机，并在将压缩后的待处理数据转发后，也即是清空数据缓冲区之后，再继续从发送端读取数据，以保证数据缓冲区写满后，后续从发送端读取的数据可从数据缓冲区的头端开始写入。

图3为本申请一示例性实施例提供的另一种对待处理数据进行压缩的实现方式的逻辑示意图。在该实现方式中，数据缓冲区采用环形缓冲区(ringbuffer)，在对待处理数据进行压缩的过程中，可从数据缓冲区中读取待处理数据；对待处理数据进行压缩；将压缩后的待处理数据接续写入数据缓冲区中最近一次已转发数据所占用的位置之后。

在该实现方式中，环形缓冲区中，从发送端读取的数据和压缩后的待处理数据都可采用接续写入的方式，而互不影响，因此，可更加充分地利用数据缓冲区。

图4为本申请一示例性实施例提供的又一种对待处理数据进行压缩的实现方式的逻辑示意图。在该实现方式中，数据缓冲区包括相互独立的第一子区和第二子区，其中，第一子区和第二子区可采用前述实现方式中的包含头端和尾端的缓冲区，当然，也可采用前述实现方式中的环形缓冲区，在此不作限定。基于此，在从发送端读取数据至数据缓冲区过程中，可将从发送端读取数据写入第一子区；在对待处理数据进行压缩的过程中，可从第一子区中读取待处理数据，对待处理数据进行压缩，将压缩后的待处理数据写入第二子区。

在该实现方式中，第一子区和第二子区相互独立，互不影响。

当然，上述三种实现方式也仅是示例性的，本实施例中，还可基于数据缓冲区采用其它的缓冲方式，来支持对待处理数据进行压缩，本实施例并不限于此。

在上述或下述实施例中，可提供两种工作模式：压缩模式和非压缩模式。图5为本申请一示例性实施例提供的一种多工作模式方案的逻辑示意图。参考图5，本实施例中，在压缩模式下，将在数据缓冲区中的待处理数据达到前述的压缩触发时机时，对待处理数据进行压缩。而在非压缩模式下，在数据缓冲区中的待处理数据达到前述的压缩触发时机时，将直接对待处理数据透传至接收端，而不再压缩。其中，压缩触发时机包括但不限于待处理数据的缓冲状态达到预置的数据量条件和/或缓冲时间条件，或者数据缓冲区已写满等。

另外，参考图5，在压缩模式下，还可在对待处理数据进行压缩前，检查待处理数据的数据量是否低于压缩标准，若是，则不执行压缩，而继续执行下一次对数据缓冲区的待处理数据的缓冲状态进行检查的操作。例如，压缩标准可以是10kb等。

参考图5，压缩模式和非压缩模式之间可按需进行切换。

在压缩模式下，针对连续的n次压缩过程，记录压缩率超过预设标准的次数，n≥2，且为整数；若次数满足预设次数条件，则切换至非压缩模式；

在非压缩模式下，对压缩过程进行压缩率测试；若出现压缩率测试值低于预设标准的情况，则切换至压缩模式。其中，压缩率是指数据经过压缩后的大小占原始大小的百分比。

例如，在压缩模式下，可记录每一次压缩过程的压缩率，其中，若连续32次压缩过程的压缩率均超过90％，或者连续40次压缩过程中压缩率超过90％的次数大于30次，则从压缩模式切换至非压缩模型。当然，这里的预设次数条件等均是示例性的，本实施例并不限于此。

再例如，在非压缩模式下，可对数据缓冲区中的数据进行采样，并对采样数据执行压缩过程，以测试压缩率。若出现压缩率低于90％的采样数据，则从非压缩模式切换至压缩模式。

据此，本实施例中，可通过压缩率，间接感知数据流是否已经被压缩过，从而及时切换工作模式。这样，对于已经被压缩过的数据流，可直接透传至接收端，而对于未被压缩过的数据流，则可进行压缩后在转发至接收端。进而可有效降低资源损耗。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤101至步骤103的执行主体可以为设备a；又比如，步骤100的执行主体可以为设备a，步骤101-103的执行主体可以为设备b；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的应用端、消息、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图6为本申请又一示例性实施例提供的一种网关设备的结构示意图。如图6所示，该计算设备包括：存储器60、处理器61以及通信组件62。

处理器61，与存储器60和通信组件62耦合，用于执行存储器60中的计算机程序，以用于：

响应于发送端的数据流转发请求，通过通信组件62从发送端读取数据至数据缓冲区；

对数据缓冲区中的待处理数据进行缓冲状态检测；

若确定待处理数据的缓冲状态达到预设的数据量条件和/或缓冲时间条件，则对待处理数据进行压缩；

通过通信组件62将压缩后的待处理数据转发至接收端。

在一可选实施例中，处理器61在对数据缓冲区中的待处理数据进行缓冲状态检测时，用于：

检测待处理数据处于无新增状态的持续时间；

检测待处理数据的累积数据量；和/或

检测待处理数据的缓冲时间。

在一可选实施例中，数据量条件包括累积数据量超过预置数据量阈值；缓冲时间条件包括缓冲时间超过第一时间阈值和/或处于无新增状态的持续时间超过第二时间阈值。

在一可选实施例中，处理器61具体用于：

若数据缓冲区中的待处理数据达到数据量条件和缓冲时间条件中的任意一项条件，则启动对待处理数据的压缩操作。

在一可选实施例中，处理器61还用于：

接收接收端发送的定制需求，定制需求中包含数据缓冲区的属性信息、数据量条件和/或缓冲时间条件；

根据定制需求，为接收端配置数据缓冲区以及数据量条件和/或缓冲时间条件。

在一可选实施例中，数据缓冲区包括头端和尾端，处理器61在对待处理数据进行压缩时，用于：

从数据缓冲区中读取待处理数据；

对待处理数据进行压缩；

从数据缓冲区的头端开始，将压缩后的待处理数据写入数据缓冲区。

在一可选实施例中，处理器61还用于：

若从发送端读取的数据已写至数据缓冲区的尾端，则对数据缓冲区中的待处理数据进行压缩；

在将压缩后的待处理数据转发完成后，继续从数据缓冲区的头端开始写入从发送端读取的数据。

在一可选实施例中，数据缓冲区采用环形缓冲区，处理器61在对待处理数据进行压缩时，用于：

从数据缓冲区中读取待处理数据；

对待处理数据进行压缩；

将压缩后的待处理数据接续写入数据缓冲区中最近一次已转发数据所占用的位置之后。

在一可选实施例中，数据缓冲区包括相互独立的第一子区和第二子区，处理器61在从发送端读取数据至数据缓冲区时，用于：

将从发送端读取数据写入第一子区；

处理器61在对待处理数据进行压缩时，用于：从第一子区中读取待处理数据，对待处理数据进行压缩，将压缩后的待处理数据写入第二子区。

在一可选实施例中，处理器61还用于：

确定当前是否处于压缩模式下；

若当前处于压缩模式下，则在数据缓冲区中的待处理数据达到预设的数据量条件和/或缓冲时间条件的情况下，执行对待处理数据进行压缩以及将压缩有的待处理数据转发至接收端的操作。

在一可选实施例中，处理器61还用于：

若当前处于非压缩模式下，则在数据缓冲区中的待处理数据达到预设的数据量条件和/或缓冲时间条件的情况下，将待处理数据透传至接收端。

在一可选实施例中，处理器61还用于：

在压缩模式下，针对连续的n次压缩过程，记录压缩率超过预设标准的次数，n≥2，且为整数；若次数满足预设次数条件，则切换至非压缩模式；

在非压缩模式下，对压缩过程进行压缩率测试；若出现压缩率测试值低于预设标准的情况，则切换至压缩模式。

进一步，如图6所示，该网关设备还包括：电源组件63等其它组件。图6中仅示意性给出部分组件，并不意味着计算设备只包括图6所示组件。

值得说明的是，上述关于网关设备各实施例中的技术细节，可参考前述的方法实施例中的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由网关算设备执行的各步骤。

上述图6中的存储器，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。

上述图6中的通信组件，被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如wifi，2g、3g、4g/lte、5g等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。

上述图6中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

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

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

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

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

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

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

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

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

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