任务生成方法、装置、设备及存储介质与流程

文档序号:16997876发布日期:2019-03-02 01:30阅读:177来源:国知局
任务生成方法、装置、设备及存储介质与流程

本公开实施例涉及计算机技术,尤其涉及一种任务生成方法、装置、设备及存储介质。



背景技术:

在大多数基于服务器/客户端的系统结构中,若客户端向服务器发起服务调用请求,则服务器会通过调度器将该请求加入线程池,由线程池来处理执行服务调用请求对应的一个或多个任务,其中,每种任务的生成可以通过生成对应的任务类来实现。

现有技术中,根据任务的方法函数来生成任务对应的任务类,生成方法较单一,需要进行优化。



技术实现要素:

本公开实施例提供一种任务生成方法、装置、设备及存储介质,以优化现有的任务生成方式。

第一方面,本公开实施例提供了一种任务生成方法,包括:

获取预先创建的上下文类;该上下文类包含多个子任务类的上下文属性参数;

获取所述多个子任务类中的方法函数;

根据获取的所述上下文类和所述方法函数生成目标任务类,所述目标任务类包含所述上下文类中的各上下文属性参数以及所述方法函数。

进一步的,创建所述上下文类,包括:

根据待创建的上下文类的标识定义上下文类;

为定义的所述上下文类设置继承属性,所述继承属性指示继承多个子任务对象的上下文属性参数。

进一步的,根据获取的所述上下文类和所述方法函数生成目标任务类,所述目标任务类包含所述上下文类中的各上下文属性参数以及所述方法函数,包括:

将获取的所述上下文类和所述方法函数作为输入参数,调用预设的任务创建函数,得到包含所述上下文类中的各上下文属性参数以及所述方法函数的目标任务类。

进一步的,在生成目标任务类之后,所述方法还包括:

在所述目标任务类中添加执行顺序描述信息,所述执行顺序描述信息描述在执行所述目标任务类对应的目标任务时,所述目标任务类中包含的各方法函数的执行顺序,并且所述执行顺序基于所述多个子任务类分别对应的子任务的指定执行路径确定。

进一步的,在生成目标任务类之后,所述方法还包括:

将所述目标任务类添加到任务文件中;

获取服务接口定义语言idl文件、脚本文件、有向无环图dag描述文件和所述任务文件:所述dag描述文件中包含待生成的服务处理对象进行服务处理时需要执行的所述任务文件中包含的多个任务类对应的多个任务的执行依赖关系信息;

将所述服务idl文件、所述dag描述文件和所述任务文件,输入给所述脚本文件,通过运行所述脚本文件得到服务处理对象;

保存生成的所述服务处理对象。

进一步的,在保存生成的所述服务处理对象之后,所述方法还包括:

接收服务调用请求;

将所述服务调用请求输入给所述服务处理对象,以使所述服务处理对象根据所述服务调用请求执行获取所述多个任务的执行依赖关系信息、根据所述执行依赖关系信息生成所述多个任务的执行图、根据生成的所述执行图执行所述多个任务的操作。

第二方面,本公开实施例还提供了一种任务生成装置,该装置包括:

上下文类获取模块,用于获取预先创建的上下文类;该上下文类包含多个子任务类的上下文属性参数;

方法函数获取模块,用于获取所述多个子任务类中的方法函数;

目标任务生成模块,用于根据获取的所述上下文类和所述方法函数生成目标任务类,所述目标任务类包含所述上下文类中的各上下文属性参数以及所述方法函数。

进一步的,上下文类获取模块具体用于:

根据待创建的上下文类的标识定义上下文类;

为定义的所述上下文类设置继承属性,所述继承属性指示继承多个子任务对象的上下文属性参数。

进一步的,目标任务生成模块具体用于:

将获取的所述上下文类和所述方法函数作为输入参数,调用预设的任务创建函数,得到包含所述上下文类中的各上下文属性参数以及所述方法函数的目标任务类。

进一步的,所述装置还包括:

信息添加模块,用于在生成目标任务类之后,在所述目标任务类中添加执行顺序描述信息,所述执行顺序描述信息描述在执行所述目标任务类对应的目标任务时,所述目标任务类中包含的各方法函数的执行顺序,并且所述执行顺序基于所述多个子任务类分别对应的子任务的指定执行路径确定。

进一步的,所述装置还包括:

任务添加模块,用于在生成目标任务类之后,将所述目标任务类添加到任务文件中;

文件获取模块,用于获取服务接口定义语言idl文件、脚本文件、有向无环图dag描述文件和所述任务文件:所述dag描述文件中包含待生成的服务处理对象进行服务处理时需要执行的所述任务文件中包含的多个任务类对应的多个任务的执行依赖关系信息;

文件输入模块,用于将所述服务idl文件、所述dag描述文件和所述任务文件,输入给所述脚本文件,通过运行所述脚本文件得到服务处理对象;

对象保存模块,用于保存生成的所述服务处理对象。

进一步的,所述装置还包括:

请求接收模块,用于在保存生成的所述服务处理对象之后,接收服务调用请求;

请求输入模块,用于将所述服务调用请求输入给所述服务处理对象,以使所述服务处理对象根据所述服务调用请求执行获取所述多个任务的执行依赖关系信息、根据所述执行依赖关系信息生成所述多个任务的执行图、根据生成的所述执行图执行所述多个任务的操作。

第三方面,本公开实施例还提供了一种计算机设备,该设备包括:

一个或多个处理器;

存储器,用于存储一个或多个程序;

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

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

本公开实施例通过获取预先创建的包含有多个子任务类上下文属性参数的上下文类,并获取该多个子任务类中的方法函数,根据该上下文类和获取的方法函数生成目标任务类,该目标任务类是包含多个子任务类的上下文属性参数和多个子任务类的方法函数的任务类,在执行该目标任务类对应的任务时,多个子任务类的方法函数均被执行,从而实现了多个子任务组合起来后所能实现的新功能。并且,仅需调用执行该目标任务类即可实现多个子任务组合起来后所能实现的组合功能,而不需要分别调用组合功能对应的多个子任务类,从而避免了调用次数多、组合功能的实现效率低等问题,实现了降低任务调用次数,提高任务组合功能的实现效率的效果。

附图说明

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

图2a是本公开实施例二提供的一种任务生成方法的流程示意图;

图2b是本公开实施例二适用的一种服务处理对象的生成结构示意图;

图2c是本公开实施例二适用的一种执行图的执行顺序示意图;

图3是本公开实施例三提供的一种任务生成装置的结构示意图;

图4是本公开实施例四提供的一种计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本公开,而非对本公开的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本公开相关的部分而非全部结构。

下述各实施例中,每个实施例中同时提供了可选特征和示例,实施例中记载的各个特征可进行组合,形成多个可选方案,不应将每个编号的实施例仅视为一个技术方案。

实施例一

图1为本公开实施例一提供的一种任务生成方法的流程示意图。该方法可适用于对实现组合功能所需执行的任务进行生成的情况,该方法可以由任务生成装置来执行,该装置可由硬件和/或软件组成,并一般可集成在服务器以及所有包含服务处理功能的计算机设备中。具体包括如下:

s110、获取预先创建的上下文类;该上下文类包含多个子任务类的上下文属性参数。

在服务器为实现目标组合功能而进行的目标任务类创建的过程中,首先需要获取预先创建的上下文类。其中,不同的上下文类可对应于不同的功能类型,上下文类中包含有其所属功能类型对应需要执行的多个子任务类的上下文属性参数,通过该多个子任务类的上下文属性参数,可对应传递子任务执行时所需的参数值和/或传递任务执行结果值,以适配不同的组合新功能。

其中,子任务类为初始状态下的子任务,也即对子任务类进行实例化后可得到具体的子任务,其对应设置的上下文属性参数也被赋予了具体的取值。以thrift服务框架为例,本实施例中提到的子任务类为executor,包含同步和异步两种运行方式,对外暴露统一的folly::future<int>run(std::shared_ptr<context>ctx)接口。内部分别调用intpre(ctx)->intsync(ctx)->intpost(ctx)或intpre(ctx)->folly::future<int>async(ctx)->intpost(ctx)两条路径。每个pre/sync/async/post都是虚函数,可以被派生类覆盖。executor通过设置的上下文属性参数ctx来传递数据,同时内部不维护状态,以保证线程安全。

示例性的,若目标组合功能对应需要执行的多个子任务类为任务1、任务2和任务3,则预先创建的与该目标组合功能的功能类型相匹配的上下文类中,包含有任务1的上下文属性参数ctx1、任务2的上下文属性参数ctx2以及任务3的上下文属性参数ctx3。

可选的,创建上下文类,包括:根据待创建的上下文类的标识定义上下文类;为定义的上下文类设置继承属性,继承属性指示继承多个子任务对象的上下文属性参数。

其中,上下文类的标识可以是上下文类的名称、身份信息等字符串。示例性的,针对目标组合功能,可定义一个上下文类,具体可使用目标组合功能的名称来定义上下文类。同时,设置该定义的上下文类继承该目标组合功能对应需要执行的所有子任务类的上下文属性参数,使得在该上下文类具有实现目标组合功能所需的所有上下文属性参数,当各子任务类实例化为子任务对象时,该上下文类能够包含有所有子任务对象对应的上下文属性参数值。

s120、获取多个子任务类中的方法函数。

本实施例中,每个子任务类可包括至少一个方法函数,用于进行相应的任务处理,实现相应的任务功能,由于每个子任务类之间是相对独立的,因此,为了能够实现多个子任务类的组合功能,也即实现最终的目标组合功能,则需获取目标组合功能对应需要执行的多个子任务的任务类中,包含的所有方法函数,以进行相应的组合后得到能够实现目标组合功能的目标任务类。

s130、根据获取的上下文类和方法函数生成目标任务类,目标任务类包含上下文类中的各上下文属性参数以及方法函数。

示例性的,可将各个子任务类中包含的方法函数,与包含有各子任务类的上下文属性参数的上下文类,组合生成能够实现目标组合功能的目标任务类,也即通过一次调用目标任务类即可实现目标组合功能,相较于现有技术中需要多次调用多个子任务类才能最终实现目标组合功能,简化了调用过程,降低了任务调用次数,提高了多个任务的组合功能的实现效率。

例如,现有技术中要实现某种功能,需要分别调用执行任务1-任务3三种任务类,本实施例生成了包含三个任务类的所有上下文属性参数和方法函数的新的任务类,则只需进行一次调用,也即调用新生成的任务类即可,使得多个任务的组合功能的实现过程更加简单,提高了实现效率。

可选的,根据获取的上下文类和方法函数生成目标任务类,目标任务类包含上下文类中的各上下文属性参数以及方法函数,包括:将获取的上下文类和方法函数作为输入参数,调用预设的任务创建函数,得到包含上下文类中的各上下文属性参数以及方法函数的目标任务类。

其中,预设的任务创建函数可以是利用上下文属性参数以及方法函数进行任务创建的函数。示例性的,可调用该任务创建函数,并将各个子任务类中包含的方法函数,以及包含有各子任务类的上下文属性参数的上下文类,作为该函数的输入参数,运行该任务创建函数后即可得到包含各子任务类的上下文属性参数以及方法函数的目标任务类。

可选的,在生成目标任务类之后,方法还包括:在目标任务类中添加执行顺序描述信息,执行顺序描述信息描述在执行目标任务类对应的目标任务时,目标任务类中包含的各方法函数的执行顺序,并且执行顺序基于多个子任务类分别对应的子任务的指定执行路径确定。

其中,各方法函数的执行顺序可以是并行执行,也可以是串行执行,在此不作限定。例如,若要实现目标组合功能,则需要执行4个子任务:任务1-任务4,指定执行路径可以是从任务1到任务4串行执行,还可以是先执行任务1,在并行执行任务2和任务3,执行2和任务3执行结束后执行任务4,具体指定什么样的执行路径与组合后的任务需要实现什么样的功能相关,可根据要实现的目标组合功能来设置相应的指定执行路径。其中,若指定执行路径是从任务1到任务4串行执行,则在目标任务类中添加的执行顺序描述信息可以是先执行任务1,再执行任务2,再执行任务3,最后执行任务4。

在上述各实施例的基础上,举一个实际例子:

首先,预先创建一个名称为requestcontext的上下文类,该上下文类中包含任务1(executor1)的上下文属性参数ctx1、任务2(executor2)的上下文属性参数ctx2、任务3(executor3)的上下文属性参数ctx3、任务4(executor4)的上下文属性参数ctx4和任务5(executor5)的上下文属性参数ctx5;

然后,在需要生成能够实现任务1至任务5的组合功能的目标任务类时,获取预先定义的上下文类requestcontext、任务1至任务5中的方法函数;

最后,将上下文类requestcontext、任务1至任务5中的方法函数作为输入参数,调用任务创建函数,得到生成的目标任务类。

本实施例的技术方案,通过获取预先创建的包含有多个子任务类上下文属性参数的上下文类,并获取该多个子任务类中的方法函数,根据该上下文类和获取的方法函数生成目标任务类,由于该目标任务类是包含多个子任务类的上下文属性参数和多个子任务类的方法函数的任务类,因此,解决了现有技术中或是因为没有实现多个任务组合功能的需求,或是因为各个任务均是按照预先定义的接口单独生成的,在此接口规范下想要同时实现多个任务组合后的新功能必须依次调用各个子任务类的问题,实现了在执行该目标任务类对应的任务时,能够通过将上下文类中包括的多个子任务类上下文属性参数代入到多个子任务类的方法函数里,使得多个子任务类的方法函数均被执行,从而最终实现了多个子任务组合起来后所能实现的新功能。并且,由于本实施例的技术方案仅需调用执行该目标任务类即可实现多个子任务组合起来后所能实现的组合功能,而不需要分别调用组合功能对应的多个子任务类,从而避免了调用次数多、组合功能的实现效率低等问题,实现了降低任务调用次数,提高任务组合功能的实现效率的效果。

实施例二

图2a为本公开实施例二提供的一种任务生成方法的流程示意图。本实施例以上述实施例中各个可选方案为基础进行具体化,提供了可选的任务生成方法,具体是,对在生成目标任务类之后的步骤进行了进一步扩展。具体包括如下:

s210、获取预先创建的上下文类;该上下文类包含多个子任务类的上下文属性参数。

s220、获取多个子任务类中的方法函数。

s230、根据获取的上下文类和方法函数生成目标任务类,目标任务类包含上下文类中的各上下文属性参数以及方法函数。

s240、将目标任务类添加到任务文件中。

本实施例中,一个任务文件对应一个服务功能,每个任务文件中包括至少一个任务类,任务文件可以是为实现特定服务功能的多个任务类的集合,其中包含有各任务对应的任务类的描述信息,描述信息中包含有各任务类所对应的上下文属性参数以及方法函数等。

s250、获取服务idl文件、脚本文件、有向无环图dag描述文件和任务文件:dag描述文件中包含待生成的服务处理对象进行服务处理时需要执行的任务文件中包含的多个任务类对应的多个任务的执行依赖关系信息。

本实施例中,服务idl(interfacedefinitionlanguage,接口定义语言)文件是一个接口文件,该文件中包含该服务功能所属服务类型对应的服务需求信息(比如服务的输入是什么、输出是什么)、输入输出的规范和字段定义信息等。dag(directedacyclicgraph,有向无环图)描述文件用于记录特定服务类型对应所需执行的多个任务之间的执行依赖关系信息。脚本文件是指生成器,是依据一定的代码格式编写的可执行文件,用来进行任务的批量处理(具体指生成代码)。

其中,执行依赖关系信息包含服务中多个任务执行时各任务所依赖的执行条件,例如,任务文件中包括任务1-任务5,其dag描述文件中包含的执行依赖关系信息例如可以为:任务2和任务3的执行依赖于任务1的执行结果,任务4的执行依赖于任务3的执行结果,任务5的执行依赖于任务2和任务4的执行结果,以此来确定任务的执行顺序,其中,执行顺序可以是并行执行,也可以是串行执行,在此不作限定。

示例性的,若任务文件中包含之前生成的目标任务类,则后续在执行目标任务类对应的目标任务时,可根据其中的执行顺序描述信息一次性执行其中包括的多个子任务,从而无需对每个子任务都进行调用,提高了任务执行效率。

s260、将服务idl文件、dag描述文件和任务文件,输入给脚本文件,通过运行脚本文件得到服务处理对象。

以thrift服务框架为例,thriftservicehandler中,每一个服务idl文件,也即thriftidl,都会编译生成一个api::thriftservicehandler以接入内部服务化平台。

可选的,通过运行脚本文件得到服务处理对象,包括:运行脚本文件后,得到服务源代码文件、服务处理类、资源管理器和请求上下文类;通过对服务源代码文件、服务处理类、资源管理器和请求上下文类进行编译,得到服务处理程序;在启动服务处理程序时,通过调用服务适配函数适配服务源代码文件,通过调用服务封装函数加载适配的服务源代码文件,得到生成的服务处理对象。

以thrift服务框架为例,运行脚本文件后,得到的服务源代码文件可以是thriftinterface,通过对该服务源代码文件进行编译,可将人类可读的计算机语言指令翻译成为计算机可以执行的二进制指令。运行脚本文件后,得到的服务处理类,属于未被实例化的服务处理对象,而得到的资源管理器(resourcemanager),可用于管理该服务类型对应所需执行的多个任务executor,其中注册有该服务所需的全部任务executor对应的信息,例如每个任务所属任务类所对应的上下文属性参数以及方法函数,同时,还生成有请求上下文类(requestcontext),其中包含有该上下文属性参数。

示例性的,在编译得到服务处理程序后,在启动该服务处理程序时,可通过调用服务适配函数(serviceadaptor)确定该服务类型对应的服务源代码文件(thriftinterface),再通过调用thrift服务中的封装函数(libtimetomb)对该服务源代码文件进行封装,最终得到服务处理对象。其中,封装函数(libtimetomb)可通过gflags设置端口,线程数,日志名,配置文件等,并向该封装函数(libtimetomb)提供相应的服务源代码文件(thriftinterface)即可执行相应的主函数流程。具体的,thrift服务框架中服务处理对象(thriftservicehandler)的生成过程如图2b所示。

s270、保存生成的服务处理对象。

其中,服务处理对象可以是对服务调用请求进行处理时,服务器所提供的服务处理入口,例如thrift服务框架中的thriftservicehandler。示例性的,在得到服务处理对象时,可通过executorstore来存储、检索、提供命令行和restful接口,同时提供应用示例和帮助文档,以提高executor的代码复用率。

可选的,在保存生成的服务处理对象之后,方法还包括:接收服务调用请求;将服务调用请求输入给服务处理对象,以使服务处理对象根据服务调用请求执行获取多个任务的执行依赖关系信息、根据执行依赖关系信息生成多个任务的执行图、根据生成的执行图执行多个任务的操作。

其中,服务调用请求可以是针对服务器中预设的服务功能之一,由客户端向服务器发起的请求。例如,服务调用请求可以是客户端向服务器发起的文章推荐服务的调用请求,以使服务器为该客户端提供文章推荐结果。

在thrift服务框架中,客户端可通过执行rpcfunction(remoteprocedurecallfunction,远程过程调用函数),以将服务调用请求发送给服务器,再由服务器输入至预先生成的服务处理对象。其中,不同的服务类型可对应于不同的服务处理对象。

其中,执行依赖关系信息包含服务中多个任务执行时各任务所依赖的执行条件,基于该执行条件,可生成该多个任务对应的执行图,以描述多个任务的执行顺序,该执行顺序包括并行执行和/或串行执行,在此不作限定。例如,图2c所示,接收到的服务调用请求所对应的服务需要执行的任务包括第一任务21、第二任务22、第三任务23、第四任务24以及第五任务25,若获取的预先设置的执行依赖关系信息为:第二任务22和第三任务23的执行依赖于第一任务21的执行结果,第四任务24的执行依赖于第三任务23的执行结果,第五任务25的执行依赖于第二任务22和第四任务24的执行结果,则可自动生成如图2c所示的执行图,其中,首先执行的是第一任务21,由于第二任务22和第三任务23之间没有依赖关系,因此第二任务22与第三任务23并行执行,在第三任务13执行结束后执行第四任务24,最后,在第二任务22和第四任务24均执行结束后执行第五任务25。

本实施例中,由于生成的执行图中描述了任务之间的执行顺序,因此服务处理对象可根据该执行图确定各任务的执行顺序,进而根据该执行顺序执行各个任务。以thrift服务框架为例,libengine是executor运行的容器,内部将多个executor串行或并行组合新的executor,执行其run方法即可完成整个执行图中各任务的执行。在服务调用请求所对应多个任务均执行完毕,则可得到服务调用结果。

本实施例的技术方案,通过将根据多个子任务类组合生成的目标任务类添加至任务文件中,再结合获取的其他文件,生成和保存服务处理对象,以在客户端进行服务调用时,提供服务处理入口,使得在进行服务处理时,若执行的多个任务类中包括目标任务类对应的目标任务,则可根据其中的执行顺序描述信息一次性执行其中包括的多个子任务,进而无需对每个子任务都进行调用,提高了任务执行效率。

实施例三

图3为本公开实施例三提供的一种任务生成装置的结构示意图。参考图3,任务生成装置包括:上下文类获取模块310、方法函数获取模块320以及目标任务生成模块330,下面对各模块进行具体说明。

上下文类获取模块310,用于获取预先创建的上下文类;该上下文类包含多个子任务类的上下文属性参数;

方法函数获取模块320,用于获取所述多个子任务类中的方法函数;

目标任务生成模块330,用于根据获取的所述上下文类和所述方法函数生成目标任务类,所述目标任务类包含所述上下文类中的各上下文属性参数以及所述方法函数。

本实施例提供的任务生成装置,通过获取预先创建的包含有多个子任务类上下文属性参数的上下文类,并获取该多个子任务类中的方法函数,根据该上下文类和获取的方法函数生成目标任务类,该目标任务类是包含多个子任务类的上下文属性参数和多个子任务类的方法函数的任务类,在执行该目标任务类对应的任务时,多个子任务类的方法函数均被执行,从而实现了多个子任务组合起来后所能实现的新功能。并且,仅需调用执行该目标任务类即可实现多个子任务组合起来后所能实现的组合功能,而不需要分别调用组合功能对应的多个子任务类,从而避免了调用次数多、组合功能的实现效率低等问题,实现了降低任务调用次数,提高任务组合功能的实现效率的效果。

可选的,上下文类获取模块310具体可以用于:

根据待创建的上下文类的标识定义上下文类;

为定义的所述上下文类设置继承属性,所述继承属性指示继承多个子任务对象的上下文属性参数。

可选的,目标任务生成模块330具体用于:

将获取的所述上下文类和所述方法函数作为输入参数,调用预设的任务创建函数,得到包含所述上下文类中的各上下文属性参数以及所述方法函数的目标任务类。

可选的,所述装置还包括:

信息添加模块,用于在生成目标任务类之后,在所述目标任务类中添加执行顺序描述信息,所述执行顺序描述信息描述在执行所述目标任务类对应的目标任务时,所述目标任务类中包含的各方法函数的执行顺序,并且所述执行顺序基于所述多个子任务类分别对应的子任务的指定执行路径确定。

可选的,所述装置还包括:

任务添加模块,用于在生成目标任务类之后,将所述目标任务类添加到任务文件中;

文件获取模块,用于获取服务idl文件、脚本文件、有向无环图dag描述文件和所述任务文件:所述dag描述文件中包含待生成的服务处理对象进行服务处理时需要执行的所述任务文件中包含的多个任务类对应的多个任务的执行依赖关系信息;

文件输入模块,用于将所述服务idl文件、所述dag描述文件和所述任务文件,输入给所述脚本文件,通过运行所述脚本文件得到服务处理对象;

对象保存模块,用于保存生成的所述服务处理对象。

可选的,所述装置还包括:

请求接收模块,用于在保存生成的所述服务处理对象之后,接收服务调用请求;

请求输入模块,用于将所述服务调用请求输入给所述服务处理对象,以使所述服务处理对象根据所述服务调用请求执行获取所述多个任务的执行依赖关系信息、根据所述执行依赖关系信息生成所述多个任务的执行图、根据生成的所述执行图执行所述多个任务的操作。

上述产品可执行本公开任意实施例所提供的方法,具备执行方法相应的功能模块和有益效果。

实施例四

图4为本公开实施例四提供的一种计算机设备的结构示意图,如图4所示,本实施例提供的一种计算机设备,包括:处理器41和存储器42。该计算机设备中的处理器可以是一个或多个,图4中以一个处理器41为例,所述计算机设备中的处理器41和存储器42可以通过总线或其他方式连接,图4中以通过总线连接为例。

本实施例中计算机设备的处理器41中集成了上述实施例提供的任务生成装置。此外,该计算机设备中的存储器42作为一种计算机可读存储介质,可用于存储一个或多个程序,所述程序可以是软件程序、计算机可执行程序以及模块,如本公开实施例中任务生成方法对应的程序指令/模块(例如,附图3所示的任务生成装置中的模块,包括:上下文类获取模块310、方法函数获取模块320以及目标任务生成模块330)。处理器41通过运行存储在存储器42中的软件程序、指令以及模块,从而执行设备的各种功能应用以及数据处理,即实现上述方法实施例中任务生成方法。

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

并且,当上述计算机设备所包括一个或者多个程序被所述一个或者多个处理器41执行时,程序进行如下操作:

获取预先创建的上下文类;该上下文类包含多个子任务类的上下文属性参数;获取多个子任务类中的方法函数;根据获取的上下文类和方法函数生成目标任务类,目标任务类包含上下文类中的各上下文属性参数以及方法函数。

实施例五

本公开实施例五还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被任务生成装置执行时实现如本公开实施例一提供的任务生成方法,该方法包括:获取预先创建的上下文类;该上下文类包含多个子任务类的上下文属性参数;获取多个子任务类中的方法函数;根据获取的上下文类和方法函数生成目标任务类,目标任务类包含上下文类中的各上下文属性参数以及方法函数。

当然,本公开实施例所提供的一种计算机可读存储介质,其上存储的计算机程序被执行时不限于实现如上所述的方法操作,还可以实现本公开任意实施例所提供的任务生成方法中的相关操作。

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

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

注意,上述仅为本公开的较佳实施例及所运用技术原理。本领域技术人员会理解,本公开不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本公开的保护范围。因此,虽然通过以上实施例对本公开进行了较为详细的说明,但是本公开不仅仅限于以上实施例,在不脱离本公开构思的情况下,还可以包括更多其他等效实施例,而本公开的范围由所附的权利要求范围决定。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1