一种任务实现方法、装置、设备和介质

技术领域

本公开涉及车辆控制领域，尤其涉及一种任务实现方法、装置、设备和介质。

背景技术

汽车开放系统架构(Automotive Open System Architecture，AUTOSAR)为控制器定义了软件架构，这种软件架构把设备的硬件与软件分离，把功能模型软件、软件组件放在一起，彼此独立并由不同的制造商研发，其有利于车辆电子系统软件的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。

现有技术中，AUTOSAR的任务实现通常是基于多进程或者多线程模型，即各个任务是单独的进程或者线程，但是所有任务的访问资源是共用的，因此，当某个任务出现系统故障时，可能会影响其他任务的正常运行，导致系统崩溃或者死机等，健壮性较差。

发明内容

为了解决上述技术问题，本公开提供了一种任务实现方法、装置、设备和介质。

第一方面，本公开提供了一种任务实现方法，包括：

将汽车开放系统架构AUTOSAR中包含的每个任务分别定义为对应的任务组件；

基于所述每个任务对应的访问资源，将所述访问资源添加至对应的任务组件中。

可选的，所述将AUTOSAR中包含的每个任务分别定义为对应的任务组件，包括：

根据CAmkES软件平台，将所述每个任务分别定义为对应的任务组件。

可选的，所述基于CAmkES软件平台，将所述每个任务定义为对应的任务组件，包括：

基于CAmkES软件平台，通过目标关键字和入口函数，对所述每个任务对应的功能进行编码，得到对应的编码文件；

对所述编码文件进行封装，得到对应的任务组件。

可选的，所述方法还包括：

根据所述任务组件的个数，基于定时服务器发送的消息，对所述任务组件进行激活。

可选的，所述根据所述任务组件的个数，基于定时服务器发送的消息，对所述任务组件进行激活，包括：

若所述任务组件的个数未超过预设阈值，确定所述任务组件的类型为扩展任务组件；

在所述扩展任务组件处于等待状态的情况下，基于所述定时服务器发送的第一激活消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

可选的，所述根据所述任务组件的个数，基于定时服务器发送的消息，对所述任务组件进行激活，包括：

若所述任务组件的个数超过预设阈值，确定每个任务组件分别对应的类型；

基于所述定时服务器发送的第二激活消息，激活所述类型中的基本任务组件；

在所述类型中的扩展任务组件处于等待状态的情况下，控制所述基本任务组件向所述扩展任务组件发送触发消息；

基于所述触发消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

可选的，所述控制所述基本任务组件向所述扩展任务组件发送触发消息，包括：

基于所述第二激活消息的发送周期和所述扩展任务组件对应的执行周期，确定所述基本任务组件向所述扩展任务组件发送触发消息的目标时刻；

控制所述基本任务组件在所述目标时刻向所述扩展任务组件发送所述触发消息。

第二方面，本公开提供了一种任务实现装置，包括：

定义模块，用于将汽车开放系统架构AUTOSAR中包含的每个任务分别定义为对应的任务组件；

添加模块，用于基于所述每个任务对应的访问资源，将所述访问资源添加至对应的任务组件中。

可选的，定义模块，包括：

定义单元，具体用于：根据CAmkES软件平台，将所述每个任务分别定义为对应的任务组件。

可选的，定义单元，具体用于：

基于CAmkES软件平台，通过目标关键字和入口函数，对所述每个任务对应的功能进行编码，得到对应的编码文件；

对所述编码文件进行封装，得到对应的任务组件。

可选的，上述装置还包括：

激活模块，具体用于：根据所述任务组件的个数，基于定时服务器发送的消息，对所述任务组件进行激活。

可选的，上述激活模块，具体用于：

若所述任务组件的个数未超过预设阈值，确定所述任务组件的类型为扩展任务组件；

在所述扩展任务组件处于等待状态的情况下，基于所述定时服务器发送的第一激活消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

可选的，上述激活模块，包括：

确定单元，用于若所述任务组件的个数超过预设阈值，确定每个任务组件分别对应的类型；

第一激活单元，用于基于所述定时服务器发送的第二激活消息，激活所述类型中的基本任务组件；

发送单元，用于在所述类型中的扩展任务组件处于等待状态的情况下，控制所述基本任务组件向所述扩展任务组件发送触发消息；

第二激活单元，用于基于所述触发消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

可选的，上述发送单元，具体用于：

基于所述第二激活消息的发送周期和所述扩展任务组件对应的执行周期，确定所述基本任务组件向所述扩展任务组件发送触发消息的目标时刻；

控制所述基本任务组件在所述目标时刻向所述扩展任务组件发送所述触发消息。

第三方面，本公开还提供了一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本公开实施例中的任一种所述的任务实现方法。

第四方面，本公开还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本公开实施例中的任一种所述的任务实现方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点：首先将AUTOSAR中包含的每个任务分别定义为对应的任务组件，然后基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中，通过任务组件将访问资源隔离，能够节省开发成本，避免某个任务出现系统故障时，影响其他任务的正常运行，健壮性较好，能够防止系统崩溃。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本公开实施例提供的一种任务实现方法的流程示意图；

图2是本公开实施例提供的另一种任务实现方法的流程示意图；

图3A是本公开实施例提供的又一种任务实现方法的流程示意图；

图3B是本公开实施例提供的一种对任务组件进行激活的过程的示意图；

图3C是本公开实施例提供的另一种对任务组件进行激活的过程的示意图；

图4是本公开实施例提供的一种任务实现装置的结构示意图；

图5是本公开实施例提供的一种电子设备的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

图1是本公开实施例提供的一种任务实现方法的流程示意图。本实施例可适用于对AUTOSAR中的任务进行实现的情况。本实施例方法可由任务实现装置来执行，该装置可采用硬件/或软件的方式来实现，并可配置于电子设备中。如图1所示，该方法具体包括如下：

S110，将AUTOSAR中包含的每个任务分别定义为对应的任务组件。

其中，任务(Task)可以理解为AUTOSAR中操作系统调度的对象。任务组件可以理解为对任务功能的封装。任意一个任务组件中均定义了与其他任务组件的交互点，即：既能提供被其他任务组件调用的接口，也提供从其他任务组件调用的接口。任务组件的抽象层次更高，各任务组件之间使用连接器相互连接。

AUTOSAR中包含了多个任务，传统AUTOSAR操作系统(Operating System，OS)通常被设计成一个保护和分离服务的集合系统，服务之间通过进程间的通信机制进行通信，但是，随着服务的数量和它们的互连的复杂性的增加，设计这样的系统变得越来越困难，为了解决该问题，本实施例通过相应的软件开发平台，将AUTOSAR中包含的每个任务分别定义为对应的任务组件。

S120，基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中。

在将AUTOSAR中包含的每个任务分别定义为对应的任务组件之后，为了避免所有任务组件共用访问资源，因此，需要对任务组件进行访问资源的隔离。此时，需要确定AUTOSAR中每个任务分别对应的访问资源，并且将与每个任务对应的访问资源添加至与任务相对应的任务组件中，任务组件只能访问自身对应的访问资源，无法访问其他任务组件对应的访问资源，从而达到资源隔离的目的。

在一些实施例中，如果一个任务组件中包含多个子任务组件，相应的，多个子任务组件能够访问该任务组件对应的访问资源。

本实施例中，多个子任务组件能够访问所属的任务组件对应的访问资源，提高了访问的便利性和快捷性。

在本实施例中，首先将AUTOSAR中包含的每个任务分别定义为对应的任务组件，然后基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中，通过任务组件将访问资源隔离，能够节省开发成本，避免某个任务出现系统故障时，影响其他任务的正常运行，健壮性较好，能够防止系统崩溃。

图2是本公开实施例提供的另一种任务实现方法的流程示意图。本实施例是在上述实施例的基础上进行优化。可选的，本实施例对将AUTOSAR中包含的每个任务分别定义为对应的任务组件的过程进行详细的解释说明。如图2所示，该方法具体包括如下：

S210，根据CAmkES软件平台，将每个任务分别定义为对应的任务组件。

其中，CAmkES为一种面向seL4的基于组件的软件平台，允许开发人员设计基于seL4的系统的交互组件的集合。seL4是一个安全操作系统内核，其是L4微内核家族的成员，为系统中运行的应用之间的隔离提供了保障，可以遏制系统某一部分的危害，并防止损害系统中其它可能更关键的部分。

通过CAmkES软件平台，能够将每个任务分别定义为对应的任务组件。

S220，基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中。

在本实施例中，首先根据CAmkES软件平台，将每个任务分别定义为对应的任务组件，然后基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中，通过CAmkES软件平台定义任务组件，能够将访问资源隔离，避免某个任务出现系统故障时，影响其他任务的正常运行，健壮性较好，能够防止系统崩溃。

在本实施例中，可选的，所述基于CAmkES软件平台，将所述每个任务定义为对应的任务组件，可以具体包括：

基于CAmkES软件平台，通过目标关键字和入口函数，对所述每个任务对应的功能进行编码，得到对应的编码文件；

对所述编码文件进行封装，得到对应的任务组件。

其中，目标关键字为控制(control)关键字。入口函数可以为intrun(void)函数。

根据CAmkES软件平台，通过control关键字和入口函数，对每个任务对应的功能进行编码，能够得到对应的编码文件。具体可以在入口函数中定义每个任务对应的功能，例如，在入口函数中定义多个可运行实体(Runnable Entity)。可运行实体为Task中包含的多个实现特定功能/算法的结构，其主要用于实现软件组件(Software component，SWC)内的特定功能。在得到编码文件之后，通过对编码文件进行封装，能够得到对应的任务组件。

本实施例中，通过上述方法得到任务组件，能够实现AUTOSAR中包含的任务，节省开发成本，以及有利于资源隔离，从而提高系统的健壮性。

图3A是本公开实施例提供的又一种任务实现方法的流程示意图。本实施例是在上述实施例的基础上进行优化。可选的，本实施例对任务组件的激活过程进行详细的解释说明。如图3A所示，该方法具体包括如下：

S310，将AUTOSAR中包含的每个任务分别定义为对应的任务组件。

S320，基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中。

S330，根据任务组件的个数，基于定时服务器发送的消息，对任务组件进行激活。

其中，定时服务器(TimeServer)为CAmkES软件平台提供的定时组件，其抽象了对计时器设备的访问并且支持多路复用。

现有技术中，AUTOSAR设计中，OS启动后，任务会进入Suspended(挂起)状态或者Wait(即等待事件)状态，如果要执行这个任务，需要在代码里调用OS的应用程序编程接口(Application Programming Interface，API)来激活，使任务进入Ready(准备)状态，之后OS根据任务的优先级对各任务进行调度，这种激活方式容易产生资源不足、内存碎片过多且耗费时间较长等问题。激活也可称为唤醒。

为了解决上述问题，在将访问资源添加至对应的任务组件中，实现了任务组件之间的资源隔离之后，基于此，还需要重新设计任务激活方法。具体的，根据任务组件的个数，基于定时服务器发送的消息，能够对不同的任务组件进行激活，从而实现AUTOSAR中任务的定时与触发激活。

在本实施例中，首先将AUTOSAR中包含的每个任务分别定义为对应的任务组件，然后基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中，最后根据任务组件的个数，基于定时服务器发送的消息，对任务组件进行激活，一方面通过任务组件将访问资源隔离，能够节省开发成本，避免某个任务出现系统故障时，影响其他任务的正常运行，健壮性较好，能够防止系统崩溃；另一方面通过定时服务器对任务组件进行激活，能够避免产生资源不足、内存碎片过多的问题，且能够节省时间，提高工作效率。

在本实施例中，可选的，所述根据所述任务组件的个数，基于定时服务器发送的消息，对所述任务组件进行激活，可以具体包括：

若所述任务组件的个数未超过预设阈值，确定所述任务组件的类型为扩展任务组件；

在所述扩展任务组件处于等待状态的情况下，基于所述定时服务器发送的第一激活消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

其中，预设阈值可以为预先设定的数值，例如1个，也可以视具体情况而定，本实施例对此不做具体限制。扩展任务(Extended Task)组件可以理解为在运行完毕后能够进入Wait状态，等待再次激活的任务组件。第一激活消息可以理解为定时服务器按照扩展任务组件的执行周期所发送的激活消息，该第一激活消息用于激活扩展任务组件。扩展任务组件的执行周期可以是预先确定好的，可以在扩展任务组件初始化阶段设置执行周期，即Timing Event(定时事件)周期，例如1秒执行1次，还可以视具体情况而定，本实施例对此不做具体限制。扩展任务组件的执行周期能够被定时服务器调用。

如果任务组件的个数未超过预设阈值，确定该任务组件的类型为扩展任务组件，控制该扩展任务组件进入等待状态，在该扩展任务组件处于等待状态的情况下，定时服务器能够根据扩展任务组件的执行周期不断发送第一激活消息，从而基于定时服务器发送的第一激活消息，能够激活该扩展任务组件，以使该扩展任务组件执行对应的功能。

本实施例中，通过上述方法激活扩展任务组件，能够节省时间，提高工作效率，避免不断通过OS的API来激活扩展任务组件，造成时间的浪费。

示例性的，图3B是本公开实施例提供的一种对任务组件进行激活的过程的示意图。如图3B所示，具体的激活过程如下所示：

第1步：定时服务器获取扩展任务组件的执行周期，该执行周期可以为扩展任务组件初始化阶段设置的Timing Event周期；

第2步：扩展任务组件进入Wait状态；

第3步：定时服务器向扩展任务组件发送第一激活消息；

第4步：扩展任务组件执行对应的功能后，重复第2步至第3步。

需要说明的是：图3B中示出了三次循环过程，用于对任务组件进行激活的过程进行说明，不对具体的执行周期和执行次数进行限制。

在本实施例中，可选的，所述基于所述定时服务器发送的第一激活消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能之后，还可以具体包括：

在所述扩展任务组件的功能执行完成之后，控制所述任务组件进入等待状态。

本实施例中，在扩展任务组件的功能执行完成之后，控制任务组件进入等待状态，能够节省激活时间，提高效率。

在本实施例中，可选的，所述根据所述任务组件的个数，基于定时服务器发送的消息，对所述任务组件进行激活，可以具体包括：

若所述任务组件的个数超过预设阈值，确定每个任务组件分别对应的类型；

基于所述定时服务器发送的第二激活消息，激活所述类型中的基本任务组件；

在所述类型中的扩展任务组件处于等待状态的情况下，控制所述基本任务组件向所述扩展任务组件发送触发消息；

基于所述触发消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

其中，任务组件的类型包括基本任务组件和扩展任务组件。基本任务(BasicTask)组件不能等待一个时间段，在运行完毕后就被终止，重新进入到挂起状态，等待用户的下一次激活。

根据CAmkES软件平台，将每个任务分别定义为对应的任务组件的过程中，为了加快通信过程，避免组件之间的进程间通信(Inter-Process Communication，IPC)，可以将SWC的所有模块，基础软件层(Basic Software，BSW)的所有模块各自组成一个组(Group)，一个组内可以包含多个任务组件，Group内部使用远程过程调用(Remote Procedure Call，RPC)协议通信，相当于直接函数调用，能够提高通信效率。但是这种情况下，定时服务器不支持Group内部配置多个任务组件使用，即：一个Group内部只支持一个定时服务器。

具体的，针对上述场景，或者其他需要用一个定时服务器对多个任务组件进行激活的场景，方案如下：如果任务组件的个数超过预设阈值，确定每个任务组件分别对应的类型，基于定时服务器发送的第二激活消息，激活类型中的基本任务组件，其中，第二激活消息的发送周期可以设置为Group内部任务组件的最小时间周期。然后在类型中的扩展任务组件处于等待状态的情况下，控制基本任务组件向类型中的扩展任务组件发送触发消息，基于该触发消息，激活扩展任务组件，以使扩展任务组件执行对应的功能。

需要说明的是：在上述情况中，各任务组件分别对应的类型中可以包括一个基本任务组件和多个扩展任务组件，对扩展任务组件的个数不做具体限制。

本实施例中，通过上述方法，能够实现Group内部多个任务组件的激活，有利于提高工作效率，节省时间。

在本实施例中，可选的，所述控制所述基本任务组件向所述扩展任务组件发送触发消息，可以具体包括：

基于所述第二激活消息的发送周期和所述扩展任务组件对应的执行周期，确定所述基本任务组件向所述扩展任务组件发送触发消息的目标时刻；

控制所述基本任务组件在所述目标时刻向所述扩展任务组件发送所述触发消息。

具体的，由于第二激活消息的发送周期通常设置为Group内部任务组件的最小时间周期，因此，基于第二激活消息的发送周期和扩展任务组件对应的执行周期，能够确定基本任务组件在接收到几次定时服务器发送的第二激活消息之后，应该向扩展任务组件发送触发消息，即：基本任务组件向扩展任务组件发送触发消息的目标时刻，从而控制基本任务组件在目标时刻向扩展任务组件发送触发消息，达到激活扩展任务组件的目的。

在本实施例中，通过上述方法控制基本任务组件在目标时刻向扩展任务组件发送触发消息，简单高效，有利于激活多个扩展任务组件。

示例性的，图3C是本公开实施例提供的另一种对任务组件进行激活的过程的示意图。如图3C所示，假设第二激活消息的发送周期为1秒发送1次，扩展任务组件1的执行周期为2秒执行1次，扩展任务组件2的执行周期为3秒执行1次，具体的激活过程如下所示：

第1步：基本任务组件初始化阶段设置第二激活消息的发送周期；

第2步：扩展任务组件1和扩展任务组件2进入Wait状态；

第3步：定时服务器根据第二激活消息的发送周期不断向基本任务组件发送第二激活消息，以激活基本任务组件，基本任务组件根据扩展任务组件1的执行周期(即：在接收到2次第二激活消息之后)向扩展任务组件1发送第一触发消息，激活扩展任务组件1，以使扩展任务组件1执行对应的功能，以及基本任务组件根据扩展任务组件2的执行周期(即：在接收到3次第二激活消息之后)向扩展任务组件2发送第二触发消息，激活扩展任务组件2，以使扩展任务组件2执行对应的功能；

第4步：扩展任务组件1和扩展任务组件2执行对应的功能后，重复第2步至第3步。

需要说明的是：图3C中示出了扩展任务组件1和扩展任务组件2的一次激活过程，用于对多个任务组件进行激活的过程进行说明，不对任务组件的具体执行周期和执行次数进行限制。

图4是本公开实施例提供的一种任务实现装置的结构示意图；该装置配置于电子设备中，可实现本申请任意实施例所述的任务实现方法。该装置具体包括如下：

定义模块410，用于将汽车开放系统架构AUTOSAR中包含的每个任务分别定义为对应的任务组件；

添加模块420，用于基于所述每个任务对应的访问资源，将所述访问资源添加至对应的任务组件中。

在本实施例中，可选的，定义模块410，包括：

定义单元，具体用于：根据CAmkES软件平台，将所述每个任务分别定义为对应的任务组件。

在本实施例中，可选的，定义单元，具体用于：

基于CAmkES软件平台，通过目标关键字和入口函数，对所述每个任务对应的功能进行编码，得到对应的编码文件；

对所述编码文件进行封装，得到对应的任务组件。

在本实施例中，可选的，上述装置还包括：

激活模块，具体用于：根据所述任务组件的个数，基于定时服务器发送的消息，对所述任务组件进行激活。

在本实施例中，可选的，上述激活模块，具体用于：

若所述任务组件的个数未超过预设阈值，确定所述任务组件的类型为扩展任务组件；

在所述扩展任务组件处于等待状态的情况下，基于所述定时服务器发送的第一激活消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

在本实施例中，可选的，上述激活模块，包括：

确定单元，用于若所述任务组件的个数超过预设阈值，确定每个任务组件分别对应的类型；

第一激活单元，用于基于所述定时服务器发送的第二激活消息，激活所述类型中的基本任务组件；

发送单元，用于在所述类型中的扩展任务组件处于等待状态的情况下，控制所述基本任务组件向所述扩展任务组件发送触发消息；

第二激活单元，用于基于所述触发消息，激活所述扩展任务组件，以使所述扩展任务组件执行对应的功能。

在本实施例中，可选的，上述发送单元，具体用于：

基于所述第二激活消息的发送周期和所述扩展任务组件对应的执行周期，确定所述基本任务组件向所述扩展任务组件发送触发消息的目标时刻；

控制所述基本任务组件在所述目标时刻向所述扩展任务组件发送所述触发消息。

通过本公开实施例提供的任务实现装置，首先将AUTOSAR中包含的每个任务分别定义为对应的任务组件，然后基于每个任务对应的访问资源，将访问资源添加至对应的任务组件中，通过任务组件将访问资源隔离，能够节省开发成本，避免某个任务出现系统故障时，影响其他任务的正常运行，健壮性较好，能够防止系统崩溃。

本公开实施例所提供的任务实现装置可执行本公开任意实施例所提供的任务实现方法，具备执行方法相应的功能模块和有益效果。

图5是本公开实施例提供的一种电子设备的结构示意图。如图5所示，该电子设备包括处理器510和存储装置520；电子设备中处理器510的数量可以是一个或多个，图5中以一个处理器510为例；电子设备中的处理器510和存储装置520可以通过总线或其他方式连接，图5中以通过总线连接为例。

存储装置520作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本公开实施例中的任务实现方法对应的程序指令/模块。处理器510通过运行存储在存储装置520中的软件程序、指令以及模块，从而执行电子设备的各种功能应用以及数据处理，即实现本公开实施例所提供的任务实现方法。

存储装置520可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储装置520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储装置520可进一步包括相对于处理器510远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本实施例提供的一种电子设备可用于执行上述任意实施例提供的任务实现方法，具备相应的功能和有益效果。

本公开实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于实现本公开实施例所提供的任务实现方法。

当然，本公开实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本公开任意实施例所提供的任务实现方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本公开可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述的方法。

值得注意的是，上述任务实现装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本公开的保护范围。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。