前端工程自动启动方法及装置与流程

文档序号:26003626发布日期:2021-07-23 21:21阅读:135来源:国知局
前端工程自动启动方法及装置与流程

本申请涉及前端开发领域,也可用于金融领域,具体涉及一种前端工程自动启动方法及装置。



背景技术:

前端工程开发过程中,在业务功能开发之前需要先完成一些工程内的基础功能,例如权限管理、整体页面布局、菜单管理逻辑等涉及全局的模块。

发明人发现,在现有的前端框架中,这些基础功能模块通常以工程代码的形式与前端工程内的其他业务代码耦合在一块,增删某个基础功能会涉及到多处修改,容易造成遗漏,而且在新应用需要添加同类基础功能的时候,一般采用手工复制的方法,效率低而且容易出错,同时不利于这些基础模块的积累和复用,导致这些问题的原因是基础功能并未模块化,需要大量手工处理。



技术实现要素:

针对现有技术中的问题,本申请提供一种前端工程自动启动方法及装置,能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率。

为了解决上述问题中的至少一个,本申请提供以下技术方案:

第一方面,本申请提供一种前端工程自动启动方法,包括:

在监测到工程的模块打包器启动时启动本地模拟对象服务器并挂载至指定端口;

获取所述工程的页面布局代码生成代码插件以及获取所述工程的逻辑处理代码生成包依赖管理工具插件,将所述代码插件和所述包依赖管理工具插件存储至指定文件路径下并进行注册;

从所述工程的各业务功能模块中获取全局配置信息存储至指定文件路径下,并执行渐进式ui组件工程的启动流程,完成所述工程的启动操作。

进一步地,所述获取所述工程的逻辑处理代码生成包依赖管理工具插件,将所述包依赖管理工具插件存储至指定文件路径下并进行注册包括:

获取指定文件路径下存储的包含有逻辑处理代码的包依赖管理工具插件,并对所述包依赖管理工具插件中的方法和变量进行声明后,读取预设参数配置文件获取对应的插件参数;

对所述包依赖管理工具插件进行前置初始化后,判断是否符合全局注册条件,若是,则对所述包依赖管理工具插件进行后置的全局注册操作。

进一步地,所述获取所述工程的页面布局代码生成代码插件,将所述代码插件存储至指定文件路径下并进行注册,包括:

获取指定文件路径下存储的包含有页面布局代码的代码插件,并获取所述代码插件中的页面全局组件和页面全局指令;

根据所述页面全局组件和页面全局指令的上下文关系依次执行全局注册操作。

进一步地,所述从所述工程的各业务功能模块中获取全局配置信息存储至指定文件路径下,包括:

在监测到工程的模块打包器启动时从所述工程的各业务功能模块的配置信息中抽取得到对应的全局配置信息并存储至指定文件路径下,其中,所述全局配置信息包括所述各业务功能模块的路由信息、多语言信息以及模拟数据配置信息中的至少一种。

第二方面,本申请提供一种前端工程自动启动装置,包括:

mock启动模块,用于在监测到工程的模块打包器启动时启动本地模拟对象服务器并挂载至指定端口;

注册插件模块,用于获取所述工程的页面布局代码生成代码插件以及获取所述工程的逻辑处理代码生成包依赖管理工具插件,将所述代码插件和所述包依赖管理工具插件存储至指定文件路径下并进行注册;

全局配置模块,用于从所述工程的各业务功能模块中获取全局配置信息存储至指定文件路径下,并执行渐进式ui组件工程的启动流程,完成所述工程的启动操作。

进一步地,所述注册插件模块包括:

npm插件确定单元,用于获取指定文件路径下存储的包含有逻辑处理代码的包依赖管理工具插件,并对所述包依赖管理工具插件中的方法和变量进行声明后,读取预设参数配置文件获取对应的插件参数;

npm插件注册单元,用于对所述包依赖管理工具插件进行前置初始化后,判断是否符合全局注册条件,若是,则对所述包依赖管理工具插件进行后置的全局注册操作。

进一步地,所述注册插件模块包括:

代码插件确定单元,用于获取指定文件路径下存储的包含有页面布局代码的代码插件,并获取所述代码插件中的页面全局组件和页面全局指令;

代码插件注册单元,用于根据所述页面全局组件和页面全局指令的上下文关系依次执行全局注册操作。

进一步地,所述全局配置模块包括:

模块化配置单元,用于在监测到工程的模块打包器启动时从所述工程的各业务功能模块的配置信息中抽取得到对应的全局配置信息并存储至指定文件路径下,其中,所述全局配置信息包括所述各业务功能模块的路由信息、多语言信息以及模拟数据配置信息中的至少一种。

第三方面,本申请提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现所述的前端工程自动启动方法的步骤。

第四方面,本申请提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现所述的前端工程自动启动方法的步骤。

由上述技术方案可知,本申请提供一种前端工程自动启动方法及装置,通过代码插件和包依赖管理工具插件将工程涉及到的基础功能插件化,同时通过从所述工程的各业务功能模块中获取全局配置信息,将工程的公共文件去中心化,由此能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率。

附图说明

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

图1为本申请实施例中的前端工程自动启动方法的流程示意图之一;

图2为本申请实施例中的前端工程自动启动方法的流程示意图之二;

图3为本申请实施例中的前端工程自动启动方法的流程示意图之三;

图4为本申请实施例中的前端工程自动启动装置的结构图之一;

图5为本申请实施例中的前端工程自动启动装置的结构图之二;

图6为本申请实施例中的前端工程自动启动装置的结构图之三;

图7为本申请实施例中的前端工程自动启动装置的结构图之四;

图8为本申请一具体实施例中的抽取全局配置信息的示意图;

图9为本申请实施例中的电子设备的结构示意图。

具体实施方式

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

考虑到在现有的前端框架中,这些基础功能模块通常以工程代码的形式与前端工程内的其他业务代码耦合在一块,增删某个基础功能会涉及到多处修改,容易造成遗漏,而且在新应用需要添加同类基础功能的时候,一般采用手工复制的方法,效率低而且容易出错,同时不利于这些基础模块的积累和复用,导致这些问题的原因是基础功能并未模块化,需要大量手工处理的问题,本申请提供一种前端工程自动启动方法及装置,通过代码插件和包依赖管理工具插件将工程涉及到的基础功能插件化,同时通过从所述工程的各业务功能模块中获取全局配置信息,将工程的公共文件去中心化,由此能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率。

为了能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率,本申请提供一种前端工程自动启动方法的实施例,参见图1,所述前端工程自动启动方法具体包含有如下内容:

步骤s101:在监测到工程的模块打包器启动时启动本地模拟对象服务器并挂载至指定端口。

可选的,本申请可以在模块打包器webpack启动时,利用模块打包器webpack提供的钩子函数启动本地模拟对象服务器(即mock服务器)并将其挂载至指定端口。

步骤s102:获取所述工程的页面布局代码生成代码插件以及获取所述工程的逻辑处理代码生成包依赖管理工具插件,将所述代码插件和所述包依赖管理工具插件存储至指定文件路径下并进行注册。

可选的,本申请可以把工程中与ui无关、仅包含逻辑处理的基础模块定义为npm插件,并将这类基础模块抽取为npm插件,以依赖的形式引入;同时,本申请还可以把与ui有关的全局组件与全局指令定义为代码插件,以工程代码的形式引入。

步骤s103:从所述工程的各业务功能模块中获取全局配置信息存储至指定文件路径下,并执行渐进式ui组件工程的启动流程,完成所述工程的启动操作。

可以理解的是,在传统前端工程结构中,通常路由信息(router)、多语言配置(i18n)和模拟数据配置(mock)都是统一存放在全局配置中,这三项信息均与业务功能相关联,因此增删业务功能都需要修改这三项全局配置,导致业务功能代码与全局配置耦合度较高,移植不便。模块化配置解决了业务功能代码与全局配置耦合度高的问题。

参见图8,本申请的模块化配置部分包含两部分,全局配置生成模块和若干业务功能模块,其中,全局配置生成部分利用了vue-cli框架中默认打包工具webpack提供的自定义上下文函数require.context,在打包时自动将业务功能模块中的配置信息抽取出来生成全局配置。业务功能模块中保存了各自业务功能所对应的路由、多语言和模拟数据的配置,供全局配置生成模块抽取调用。如图2所示,添加模块化配置后,前端工程中所有与业务功能相关联的代码都收敛至一个文件夹内,业务功能代码不仅与全局配置解耦,而且业务功能代码之间也进行了解耦,方便业务功能代码的移植和增减。

在本申请其他实施例中,本申请还可以提供本地调试相关配置,具体可以包括dev-server设置和本地mock服务器的设置,通过改造,开发人员可以通过切换dev-server配置方便的使用本地mock服务进行自测以及与后端进行联调。

在本申请其他实施例中,本申请还可以提供代码质量相关模块,具体可以包含代码风格规则及代码风格校验修正模块两部分,在开发过程中,ide可以读取代码风格规则并提示用户代码是否满足规则,并在package.json中添加新指令以调用校验修正模块自动对代码进行风格修正。

从上述描述可知,本申请实施例提供的前端工程自动启动方法,能够通过代码插件和包依赖管理工具插件将工程涉及到的基础功能插件化,同时通过从所述工程的各业务功能模块中获取全局配置信息,将工程的公共文件去中心化,由此能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率。

为了能够将工程中涉及逻辑处理的代码插件化,在本申请的前端工程自动启动方法的一实施例中,参见图2,上述步骤s102还可以具体包含如下内容:

步骤s201:获取指定文件路径下存储的包含有逻辑处理代码的包依赖管理工具插件,并对所述包依赖管理工具插件中的方法和变量进行声明后,读取预设参数配置文件获取对应的插件参数。

步骤s202:对所述包依赖管理工具插件进行前置初始化后,判断是否符合全局注册条件,若是,则对所述包依赖管理工具插件进行后置的全局注册操作。

具体的,由于npm依赖的逻辑对前端工程来说是不可修改的,因此在注册这类插件时需要额外的参数信息以保证插件的灵活性。为了方便对npm插件参数进行维护管理,将所有插件的参数抽取出来统一放置在一个参数配置文件内,以object的形式存储,object中属性名为插件名,值为对应插件的配置项。参数配置文件结构如下所示:

可选的,对于以npm依赖形式引入的插件,由于其涉及全局的基础功能,因此要在前端工程入口流程中添加对这类插件的注册模块。在部分插件中,会需要添加部分vue全局配置,这里利用了vue框架提供的vue.use功能将需要添加至vue全局配置的插件进行注册。

具体的,首先声明插件内部相关的方法及变量,然后读取写在全局配置文件中的插件参数配置,将插件初始化流程分为前置和后置两部分,先执行前置初始化,再判断是否调用vue.use,接着执行插件的后置初始化,最终完成插件的全局注册。

为了能够将工程中涉及页面布局的代码插件化,在本申请的前端工程自动启动方法的一实施例中,参见图3,上述步骤s102还可以具体包含如下内容:

步骤s301:获取指定文件路径下存储的包含有页面布局代码的代码插件,并获取所述代码插件中的页面全局组件和页面全局指令。

步骤s302:根据所述页面全局组件和页面全局指令的上下文关系依次执行全局注册操作。

具体的,代码插件其实就是工程代码,根据插件分类放置在前端工程内的指定文件夹中,例如全局组件放置在src/components下,全局指令放置在src/directives下,代码插件的注册模块同样利用了webpack提供的自定义上下文功能,将指定文件夹内的所有文件抽取并依此调用vue.use功能进行注册。

为了能够将工程中的全局配置信息去中心化,在本申请的前端工程自动启动方法的一实施例中,上述步骤s103还可以具体包含如下内容:

在监测到工程的模块打包器启动时从所述工程的各业务功能模块的配置信息中抽取得到对应的全局配置信息并存储至指定文件路径下,其中,所述全局配置信息包括所述各业务功能模块的路由信息、多语言信息以及模拟数据配置信息中的至少一种。

可以理解的是,在传统前端工程结构中,通常路由信息(router)、多语言配置(i18n)和模拟数据配置(mock)都是统一存放在全局配置中,这三项信息均与业务功能相关联,因此增删业务功能都需要修改这三项全局配置,导致业务功能代码与全局配置耦合度较高,移植不便。模块化配置解决了业务功能代码与全局配置耦合度高的问题。

参见图8,本申请的模块化配置部分包含两部分,全局配置生成模块和若干业务功能模块,其中,全局配置生成部分利用了vue-cli框架中默认打包工具webpack提供的自定义上下文函数require.context,在打包时自动将业务功能模块中的配置信息抽取出来生成全局配置。业务功能模块中保存了各自业务功能所对应的路由、多语言和模拟数据的配置,供全局配置生成模块抽取调用。如图2所示,添加模块化配置后,前端工程中所有与业务功能相关联的代码都收敛至一个文件夹内,业务功能代码不仅与全局配置解耦,而且业务功能代码之间也进行了解耦,方便业务功能代码的移植和增减。

为了能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率,本申请提供一种用于实现所述前端工程自动启动方法的全部或部分内容的前端工程自动启动装置的实施例,参见图4,所述前端工程自动启动装置具体包含有如下内容:

mock启动模块10,用于在监测到工程的模块打包器启动时启动本地模拟对象服务器并挂载至指定端口。

注册插件模块20,用于获取所述工程的页面布局代码生成代码插件以及获取所述工程的逻辑处理代码生成包依赖管理工具插件,将所述代码插件和所述包依赖管理工具插件存储至指定文件路径下并进行注册。

全局配置模块30,用于从所述工程的各业务功能模块中获取全局配置信息存储至指定文件路径下,并执行渐进式ui组件工程的启动流程,完成所述工程的启动操作。

从上述描述可知,本申请实施例提供的前端工程自动启动装置,能够通过代码插件和包依赖管理工具插件将工程涉及到的基础功能插件化,同时通过从所述工程的各业务功能模块中获取全局配置信息,将工程的公共文件去中心化,由此能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率。

为了能够将工程中涉及逻辑处理的代码插件化,在本申请的前端工程自动启动装置的一实施例中,参见图5,所述注册插件模块20包括:

npm插件确定单元21,用于获取指定文件路径下存储的包含有逻辑处理代码的包依赖管理工具插件,并对所述包依赖管理工具插件中的方法和变量进行声明后,读取预设参数配置文件获取对应的插件参数。

npm插件注册单元22,用于对所述包依赖管理工具插件进行前置初始化后,判断是否符合全局注册条件,若是,则对所述包依赖管理工具插件进行后置的全局注册操作。

为了能够将工程中涉及页面布局的代码插件化,在本申请的前端工程自动启动装置的一实施例中,参见图6,所述注册插件模块20包括:

代码插件确定单元23,用于获取指定文件路径下存储的包含有页面布局代码的代码插件,并获取所述代码插件中的页面全局组件和页面全局指令。

代码插件注册单元24,用于根据所述页面全局组件和页面全局指令的上下文关系依次执行全局注册操作。

为了能够将工程中的全局配置信息去中心化,在本申请的前端工程自动启动装置的一实施例中,参见图7,所述全局配置模块30包括:

模块化配置单元,用于在监测到工程的模块打包器启动时从所述工程的各业务功能模块的配置信息中抽取得到对应的全局配置信息并存储至指定文件路径下,其中,所述全局配置信息包括所述各业务功能模块的路由信息、多语言信息以及模拟数据配置信息中的至少一种。

从硬件层面来说,为了能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率,本申请提供一种用于实现所述前端工程自动启动方法中的全部或部分内容的电子设备的实施例,所述电子设备具体包含有如下内容:

处理器(processor)、存储器(memory)、通信接口(communicationsinterface)和总线;其中,所述处理器、存储器、通信接口通过所述总线完成相互间的通信;所述通信接口用于实现前端工程自动启动装置与核心业务系统、用户终端以及相关数据库等相关设备之间的信息传输;该逻辑控制器可以是台式计算机、平板电脑及移动终端等,本实施例不限于此。在本实施例中,该逻辑控制器可以参照实施例中的前端工程自动启动方法的实施例,以及前端工程自动启动装置的实施例进行实施,其内容被合并于此,重复之处不再赘述。

可以理解的是,所述用户终端可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(pda)、车载设备、智能穿戴设备等。其中,所述智能穿戴设备可以包括智能眼镜、智能手表、智能手环等。

在实际应用中,前端工程自动启动方法的部分可以在如上述内容所述的电子设备侧执行,也可以所有的操作都在所述客户端设备中完成。具体可以根据所述客户端设备的处理能力,以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成,所述客户端设备还可以包括处理器。

上述的客户端设备可以具有通信模块(即通信单元),可以与远程的服务器进行通信连接,实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器,其他的实施场景中也可以包括中间平台的服务器,例如与任务调度中心服务器有通信链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备,也可以包括多个服务器组成的服务器集群,或者分布式装置的服务器结构。

图9为本申请实施例的电子设备9600的系统构成的示意框图。如图9所示,该电子设备9600可以包括中央处理器9100和存储器9140;存储器9140耦合到中央处理器9100。值得注意的是,该图9是示例性的;还可以使用其他类型的结构,来补充或代替该结构,以实现电信功能或其他功能。

一实施例中,前端工程自动启动方法功能可以被集成到中央处理器9100中。

其中,中央处理器9100可以被配置为进行如下控制:

步骤s101:在监测到工程的模块打包器启动时启动本地模拟对象服务器并挂载至指定端口。

步骤s102:获取所述工程的页面布局代码生成代码插件以及获取所述工程的逻辑处理代码生成包依赖管理工具插件,将所述代码插件和所述包依赖管理工具插件存储至指定文件路径下并进行注册。

步骤s103:从所述工程的各业务功能模块中获取全局配置信息存储至指定文件路径下,并执行渐进式ui组件工程的启动流程,完成所述工程的启动操作。

从上述描述可知,本申请实施例提供的电子设备,通过代码插件和包依赖管理工具插件将工程涉及到的基础功能插件化,同时通过从所述工程的各业务功能模块中获取全局配置信息,将工程的公共文件去中心化,由此能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率。

在另一个实施方式中,前端工程自动启动装置可以与中央处理器9100分开配置,例如可以将前端工程自动启动装置配置为与中央处理器9100连接的芯片,通过中央处理器的控制来实现前端工程自动启动方法功能。

如图9所示,该电子设备9600还可以包括:通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是,电子设备9600也并不是必须要包括图9中所示的所有部件;此外,电子设备9600还可以包括图9中没有示出的部件,可以参考现有技术。

如图9所示,中央处理器9100有时也称为控制器或操作控件,可以包括微处理器或其他处理器装置和/或逻辑装置,该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中,存储器9140,例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息,此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序,以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为lcd显示器,但并不限于此。

该存储器9140可以是固态存储器,例如,只读存储器(rom)、随机存取存储器(ram)、sim卡等。还可以是这样的存储器,其即使在断电时也保存信息,可被选择性地擦除且设有更多数据,该存储器的示例有时被称为eprom等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142,该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143,该数据存储部9143用于存储数据,例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100,以提供输入信号和接收输出信号,这可以和常规移动通信终端的情况相同。

基于不同的通信技术,在同一电子设备中,可以设置有多个通信模块9110,如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132,以经由扬声器9131提供音频输出,并接收来自麦克风9132的音频输入,从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外,音频处理器9130还耦合到中央处理器9100,从而使得可以通过麦克风9132能够在本机上录音,且使得可以通过扬声器9131来播放本机上存储的声音。

本申请的实施例还提供能够实现上述实施例中的执行主体为服务器或客户端的前端工程自动启动方法中全部步骤的一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的前端工程自动启动方法的全部步骤,例如,所述处理器执行所述计算机程序时实现下述步骤:

步骤s101:在监测到工程的模块打包器启动时启动本地模拟对象服务器并挂载至指定端口。

步骤s102:获取所述工程的页面布局代码生成代码插件以及获取所述工程的逻辑处理代码生成包依赖管理工具插件,将所述代码插件和所述包依赖管理工具插件存储至指定文件路径下并进行注册。

步骤s103:从所述工程的各业务功能模块中获取全局配置信息存储至指定文件路径下,并执行渐进式ui组件工程的启动流程,完成所述工程的启动操作。

从上述描述可知,本申请实施例提供的计算机可读存储介质,通过代码插件和包依赖管理工具插件将工程涉及到的基础功能插件化,同时通过从所述工程的各业务功能模块中获取全局配置信息,将工程的公共文件去中心化,由此能够有效降低前端开发过程中基础功能与工程内业务代码的耦合度,同时提高各个基础功能的内聚程度,进而提高前端开发的整体效率。

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

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

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

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

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

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