组件打包方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种组件打包方法、装置、电子设备及存储介质。

背景技术

当前的前端开发模式中，组件化开发大行其道，常见的如element-ui、Ant-design等优秀组件库也因为能够大大提高前端程序员的开发效率而广受欢迎。然而，这些组件库提供的组件数量有限，且往往都是一些常用组件，面对如今尤其是企业级软件市场高度定制化的组件需求以及快速迭代的敏捷开发模式显得有些力不从心。因此，基于业务需求定制开发一套组件库就显得十分迫切。

然而，由于业务组件的特殊性，单个项目中需要依赖的组件不会很多，如果将组件库全量加载，容易造成打包后的工程文件体积过大，文件加载时间变长，体验也会相应变得糟糕。因此，在开发业务组件库时，仍然需要定制化开发一整套打包脚本，使得组件库在支持全量加载的同时也支持按需加载。目前已知的组件打包方案存在以下问题：无法实现单组件的按需打包加载，项目打包体积较大，组件文件的运行性能较低，代码侵入性高，用户体验差。

发明内容

有鉴于此，本公开实施例提供了一种组件打包方法、装置、电子设备及存储介质，以解决现有技术存在的无法实现单组件的按需打包加载，项目打包体积较大，组件文件的运行性能较低，代码侵入性高的问题。

本公开实施例的第一方面，提供了一种组件打包方法，包括：从仓库管理工具中获取预定的组件打包工具，其中组件打包工具是利用前端应用开发系统所生成的工具；执行组件打包工具，以便读取用户预先配置的组件列表，并获取组件列表中的每个组件对应的组件名称以及组件路径；基于每个组件的组件名称以及组件路径，生成每个组件分别对应的组件打包脚本；执行组件打包脚本，并对执行结果进行判断，当判断组件打包脚本执行成功时，在目标文件夹中生成与组件相对应的组件文件；在每个组件对应的组件打包脚本分别执行且对执行结果进行判断之后，目标文件夹中将包含与每个执行成功的组件相对应的组件文件，将目标文件夹中的组件文件作为组件打包结果。

本公开实施例的第二方面，提供了一种组件打包装置，包括：获取模块，被配置为从仓库管理工具中获取预定的组件打包工具，其中组件打包工具是利用前端应用开发系统所生成的工具；执行模块，被配置为执行组件打包工具，以便读取用户预先配置的组件列表，并获取组件列表中的每个组件对应的组件名称以及组件路径；生成模块，被配置为基于每个组件的组件名称以及组件路径，生成每个组件分别对应的组件打包脚本；判断模块，被配置为执行组件打包脚本，并对执行结果进行判断，当判断组件打包脚本执行成功时，在目标文件夹中生成与组件相对应的组件文件；打包模块，被配置为在每个组件对应的组件打包脚本分别执行且对执行结果进行判断之后，目标文件夹中将包含与每个执行成功的组件相对应的组件文件，将目标文件夹中的组件文件作为组件打包结果。

本公开实施例的第三方面，提供了一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现上述方法的步骤。

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

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

通过从仓库管理工具中获取预定的组件打包工具，其中组件打包工具是利用前端应用开发系统所生成的工具；执行组件打包工具，以便读取用户预先配置的组件列表，并获取组件列表中的每个组件对应的组件名称以及组件路径；基于每个组件的组件名称以及组件路径，生成每个组件分别对应的组件打包脚本；执行组件打包脚本，并对执行结果进行判断，当判断组件打包脚本执行成功时，在目标文件夹中生成与组件相对应的组件文件；在每个组件对应的组件打包脚本分别执行且对执行结果进行判断之后，目标文件夹中将包含与每个执行成功的组件相对应的组件文件，将目标文件夹中的组件文件作为组件打包结果。本公开能够实现单组件的按需打包加载，减少项目打包体积，提升组件文件的运行性能，提升项目开发效率，代码侵入性低，优化用户体验。

附图说明

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

图1是本公开实施例提供的组件打包方法的整体处理流程示意图；

图2是本公开实施例提供的组件打包方法的流程示意图；

图3是本公开实施例提供的组件打包装置的结构示意图；

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

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本公开实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本公开。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本公开的描述。

如前文背景技术内容，当前的前端应用项目开发过程中中，为了解决组件库按需打包问题，主要采用Rollup和Webpack的方式，其中Rollup适合于库工程，Webpack适合于应用工程。但是，上述目前主流的组件打包方案仍存在以下问题：

1)配置项多且复杂，以Webpack为例，粗略统计有不少于50项配置，且不同配置之间可以进行排列组合。这对于主要进行日常业务逻辑开发的前端工程师来说学习成本较高，需要花费大量时间与精力进行脚本配置与调试。

2)版本更新快，通常版本更新完之后与之前版本之间存在一定量的不兼容配置项，其中大版本更新时表现得更为明显。

3)对于工程中原有配置项的利用率低，基本上相当于需要一份全新的配置文件，增加项目的维护成本。

鉴于上述现有技术中的问题，本公开实施例提供一种全新的组件打包方法，生成的组件打包工具通过仓库管理工具加载到前端应用项目中去，在前端应用项目开发过程中，执行该组件打包工具，读取用户在脚本中配置的组件列表，基于组件列表中每个组件对应的组件名称以及组件路径，生成每个组件的组件打包脚本，利用组件打包脚本执行该组件的打包操作，若打包操作执行成功，则在目标文件夹中生成与该组件相对应的组件文件，从而实现定制化组件按需打包操作。

下面结合附图以及具体实施例，对本公开实施例提供的组件打包方法的整体处理流程进行说明。图1是本公开实施例提供的组件打包方法的整体处理流程示意图。图1的组件打包方法可以由前端应用项目开发项目的服务器执行。

如图1所示，该组件打包方法的整体处理流程具体可以包括：

用户只需要输入自己配置的组件列表以及组件打包后所存放的目标文件夹的路径目录即可，其中组件列表为必填项，而目标文件夹为非必填项；之后通过调用组件打包工具中的脚本开发命令，遍历组件列表中的每个单组件，根据每个单组件的组件名称以及组件路径，生成每个单组件对应的组件打包脚本(即定制打包脚本的过程)，调用前端应用项目开发的子进程，依次执行每个单组件的组件打包脚本，并判断组件打包脚本是否执行成功，当组件打包脚本执行失败时，结束该组件的打包流程并输出执行异常堆栈信息；当组件打包脚本执行成功时，在目标文件夹中生成该组件的组件文件，并对组件文件执行重命名操作，最终所有执行成功的组件，在目标文件夹中都具有与之对应的组件文件，从而完成对组件列表内的所有单组件的打包工作。

基于本公开实施例提供的组件打包流程，本公开实施例可以根据用户配置的组件列表以及输出目录(非必填项)快速打包生成支持按需加载的组件文件，且用户不需要对原有项目中的打包配置进行调整，因此代码侵入性低。

需要说明的是，本公开以下实施例是以web应用程序项目开发场景为例，对web应用程序项目开发过程中的组件打包流程进行展开描述，但是，本公开实施例针对的应用场景不限于web应用程序项目开发场景，其他应用程序项目的开发场景同样适用。上述应用场景不构成对本公开技术方案的限定。

图2是本公开实施例提供的组件打包方法的流程示意图。图2的组件打包方法可以由服务器执行。如图2所示，该组件打包方法具体可以包括：

S201，从仓库管理工具中获取预定的组件打包工具，其中组件打包工具是利用前端应用开发系统所生成的工具；

S202，执行组件打包工具，以便读取用户预先配置的组件列表，并获取组件列表中的每个组件对应的组件名称以及组件路径；

S203，基于每个组件的组件名称以及组件路径，生成每个组件分别对应的组件打包脚本；

S204，执行组件打包脚本，并对执行结果进行判断，当判断组件打包脚本执行成功时，在目标文件夹中生成与组件相对应的组件文件；

S205，在每个组件对应的组件打包脚本分别执行且对执行结果进行判断之后，目标文件夹中将包含与每个执行成功的组件相对应的组件文件，将目标文件夹中的组件文件作为组件打包结果。

具体地，本公开实施例的仓库管理工具采用npm仓库，npm(Node PackageManager，节点的包管理器)是一个软件包管理器，主要用于进行JavaScript的包管理。通过npm，可以很方便地进行JavaScript包的下载、升级，也可以将开发的JavaScript包共享给其他使用者。

进一步地，本公开实施例的前端应用项目可以是web前端应用程序项目，web前端应用程序项目是基于Java工程开发的应用程序项目，通过应用程序项目开发人员生产web前端应用程序项目的代码，并将项目代码放到应用程序的容器中，由应用程序服务器启动web前端应用程序项目，实现对web前端应用程序服务的启动，这样用户就可以访问这些服务。

进一步地，本公开实施例的前端应用开发系统可以采用vue-cli-service系统，Vue是一套用于构建用户界面的渐进式框架，vue-cli-service是一个基于Vue.js进行快速开发的完整系统。vue-cli-service可以认为是生成页面应用的工具，通过执行脚本就可以生成一个vue前端应用程序。vue-cli-service依赖于nodejs进行开发，nodejs是JavaScript的运行环境的底层依赖。

根据本公开实施例提供的技术方案，通过从仓库管理工具中获取预定的组件打包工具，其中组件打包工具是利用前端应用开发系统所生成的工具；执行组件打包工具，以便读取用户预先配置的组件列表，并获取组件列表中的每个组件对应的组件名称以及组件路径；基于每个组件的组件名称以及组件路径，生成每个组件分别对应的组件打包脚本；执行组件打包脚本，并对执行结果进行判断，当判断组件打包脚本执行成功时，在目标文件夹中生成与组件相对应的组件文件；在每个组件对应的组件打包脚本分别执行且对执行结果进行判断之后，目标文件夹中将包含与每个执行成功的组件相对应的组件文件，将目标文件夹中的组件文件作为组件打包结果。本公开能够实现单组件的按需打包加载，减少项目打包体积，提升组件文件的运行性能，提升项目开发效率，代码侵入性低，优化用户体验。

在一些实施例中，在从仓库管理工具中获取预定的组件打包工具之前，方法还包括：在预定的前端应用开发系统中生成组件打包工具，并将组件打包工具对应的代码提交至仓库管理工具中，以使仓库管理工具保存组件打包工具的代码；其中，前端应用开发系统采用vue-cli-service系统，组件打包工具采用vue-build-enn工具，仓库管理工具采用npm仓库。

具体地，在vue-cli-service系统中生成vue-build-enn工具(即组件打包工具)，利用组件打包工具对组件进行按需打包，在生成vue-build-enn工具之后，将vue-build-enn工具的代码提交至仓库管理工具(npm仓库)中去，将vue-build-enn工具的代码保存在npm仓库中。也就是说，本公开实施例通过利用第三方仓库管理工具引入的方式，将组件打包工具引入到前端应用开发项目中。

在一些实施例中，从仓库管理工具中获取预定的组件打包工具，包括：在前端应用项目开发过程中，从仓库管理工具中下载组件打包工具对应的代码，并将组件打包工具对应的代码加载到前端应用项目中去，以便在前端应用项目中执行组件打包工具的代码。

具体地，在将vue-build-enn工具的代码提交到npm仓库之后，在前端应用项目的开发过程中，首先从npm仓库中下载该vue-build-enn工具对应的代码，并将vue-build-enn工具对应的代码加载到前端应用项目中去，以便在前端应用项目中执行vue-build-enn工具的代码。

在一些实施例中，读取用户预先配置的组件列表，并获取组件列表中的每个组件对应的组件名称以及组件路径，包括：利用组件打包工具中的脚本读取用户在脚本中配置的组件参数，以及用户在脚本中配置的组件打包后的目标文件夹对应的路径目录，其中，组件参数中包含组件列表，组件列表中包含多个单组件，每个单组件具有相应的组件名称以及组件路径。

具体地，在前端应用项目中执行上述vue-build-enn工具，触发单组件打包流程操作，首先利用组件打包工具中的脚本读取用户在脚本中配置的组件参数，这里的组件参数包含组件列表，组件列表中包含应用里面每个单组件的组件名称和组件路径，单组件对应的配置文件(即组件参数)是用户提前配置好的，为组件打包流程操作的必填项。

进一步地，除了读取用户配置的组件列表之外，还可以读取用户在脚本中配置的组件打包后的目标文件夹对应的路径目录，这里的打包后的目标文件夹即组件输出文件夹，默认采用componentsLib，通过在组件库中新建一个Lib的文件夹，将打包后的组件放到该文件夹的路径下，路径具有对应的目录名。

在一些实施例中，在生成每个组件分别对应的组件打包脚本之前，该方法还包括：基于目标文件夹对应的路径目录，判断目标文件夹中是否存在其它组件，当目标文件夹中存在其它组件时，从目标文件夹中将其它组件对应的组件文件进行清空，以便将目标文件夹中的其它组件删除。

具体地，在利用脚本读取组件列表，获取组件列表中的组件名称以及组件名称对应的组件路径之后，根据目标文件夹对应的路径目录，获取目标文件夹中已有的其它组件，即获取目标文件夹中的历史组件。在实际应用中，在对组件列表中的单组件进行打包之前，需要将目标文件夹中已有的其它组件进行删除，从而利用打包之后的新的组件覆盖原来旧的组件(即历史组件)。

在一些实施例中，基于每个组件的组件名称以及组件路径，生成每个组件分别对应的组件打包脚本，包括：调用组件打包工具中的脚本开发命令，利用脚本开发命令依次读取组件列表中的每个单组件对应的组件名称及组件路径，并生成每个单组件对应的组件打包脚本。

具体地，遍历组件列表，通过调用组件打包工具中的脚本开发命令，利用脚本开发命令依次读取组件列表中的每个单组件对应的组件名称及组件路径，从而生成单组件对应的定制打包脚本。在实际应用中，组件打包脚本的生成是基于vue-cli-service命令(即脚本开发命令)，通过vue-cli-service命令读取组件列表中的每个单组件对应的组件名称及其入口文件所在路径(即组件路径)生成打包脚本。由于每个组件对应的组件名称以及组件路径均不相同，因此每个组件均对应一个组件打包脚本。

在一些实施例中，执行组件打包脚本，并对执行结果进行判断，包括：调用前端应用项目开发的子进程，基于子进程执行组件打包脚本，当组件打包脚本执行失败时，结束该组件的打包流程并输出执行异常堆栈信息；当组件打包脚本执行成功时，在目标文件夹中生成与该组件相对应的组件文件，并按照预设的命名规则对组件文件执行重命名操作。

具体地，在生成每个单组件对应的组件打包脚本之后，通过调用前端应用项目开发的子进程来依次执行每个组件打包脚本，即通过调用nodejs的子进程来执行组件打包脚本，其中nodejs的子进程是JavaScript底层中的一个子进程。在调用nodejs的子进程执行各个组件对应的组件打包脚本之后，对每个组件对应的脚本执行结果进行判断，根据判断结果选择是否生成组件文件。

进一步地，若组件打包脚本执行失败，则结束该组件的打包流程，并输出执行异常堆栈信息，并且用户可以在控制台当中看到报错信息；比如当组件代码有问题时，组件打包脚本就可能执行失败，在控制台中对打包结果进行报错。

进一步地，若组件打包脚本执行成功，则会在目标文件夹(即输出文件夹)中生成对应的组件文件，组件文件是采用JavaScript脚本语言编写的文件夹，即在目标文件夹中生成JS文件，并将JS文件进行重命名流程操作，比如将按照命名规则将xxx.umd.min.js文件重命名为xxx.js文件。

进一步地，在将组件列表中的所有组件的打包流程都执行一遍之后，对于组件打包脚本执行失败的组件，则不在目标文件夹中生成与之对应的JS文件，而对于组件打包脚本执行成功的组件，则在目标文件夹中分别生成与之对应的JS文件，那么目标文件夹中将会出现与组件列表中执行成功的组件一一对应的JS文件。

根据本公开实施例提供的技术方案，本公开实施例从已有项目入手，在现有配置文件的基础上直接调用内置的打包命令vue-cli-service，完成组件打包流程，本公开技术方案具有以下优点：

1)对用户仅显示两项配置，且其中一项为非必填项。开发人员只需要关注自己的组件业务，无需学习大量的配置项，使得用户学习成本降低，使应用工程的接入成本低，团队无需安排额外人员去配置复杂的打包配置项，提升开发效率。

2)版本更新直接依赖于vue-cli-service，其内部会封装好不同版本直接的配置项差异，对外暴露统一配置，兼容性较高；并且由于各版本之间的差异小，对应用开发人员造成的影响较小。

3)支持直接通过打包脚本读取用户配置，不需要另外维护单独的配置文件，降低维护成本。且可以直接读取用户原有工程中的配置项，大大降低了接入成本和代码侵入性，最大限度的保持了项目的独立性。

前端开发人员在使用本公开实施例提供的技术方案进行组件打包时，不仅可以减少项目打包体积，提高打包后产物文件的运行性能，优化用户体验；还可以实现代码的快速接入，代码侵入性低，集成工作简单。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

图3是本公开实施例提供的组件打包装置的结构示意图。如图3所示，该组件打包装置包括：

获取模块301，被配置为从仓库管理工具中获取预定的组件打包工具，其中组件打包工具是利用前端应用开发系统所生成的工具；

执行模块302，被配置为执行组件打包工具，以便读取用户预先配置的组件列表，并获取组件列表中的每个组件对应的组件名称以及组件路径；

生成模块303，被配置为基于每个组件的组件名称以及组件路径，生成每个组件分别对应的组件打包脚本；

判断模块304，被配置为执行组件打包脚本，并对执行结果进行判断，当判断组件打包脚本执行成功时，在目标文件夹中生成与组件相对应的组件文件；

打包模块305，被配置为在每个组件对应的组件打包脚本分别执行且对执行结果进行判断之后，目标文件夹中将包含与每个执行成功的组件相对应的组件文件，将目标文件夹中的组件文件作为组件打包结果。

在一些实施例中，图3的获取模块301在从仓库管理工具中获取预定的组件打包工具之前，在预定的前端应用开发系统中生成组件打包工具，并将组件打包工具对应的代码提交至仓库管理工具中，以使仓库管理工具保存组件打包工具的代码；其中，前端应用开发系统采用vue-cli-service系统，组件打包工具采用vue-build-enn工具，仓库管理工具采用npm仓库。

在一些实施例中，图3的获取模块301在前端应用项目开发过程中，从仓库管理工具中下载组件打包工具对应的代码，并将组件打包工具对应的代码加载到前端应用项目中去，以便在前端应用项目中执行组件打包工具的代码。

在一些实施例中，图3的执行模块302利用组件打包工具中的脚本读取用户在脚本中配置的组件参数，以及用户在脚本中配置的组件打包后的目标文件夹对应的路径目录，其中，组件参数中包含组件列表，组件列表中包含多个单组件，每个单组件具有相应的组件名称以及组件路径。

在一些实施例中，图3的生成模块303在生成每个组件分别对应的组件打包脚本之前，基于目标文件夹对应的路径目录，判断目标文件夹中是否存在其它组件，当目标文件夹中存在其它组件时，从目标文件夹中将其它组件对应的组件文件进行清空，以便将目标文件夹中的其它组件删除。

在一些实施例中，图3的生成模块303调用组件打包工具中的脚本开发命令，利用脚本开发命令依次读取组件列表中的每个单组件对应的组件名称及组件路径，并生成每个单组件对应的组件打包脚本。

在一些实施例中，图3的判断模块304调用前端应用项目开发的子进程，基于子进程执行组件打包脚本，当组件打包脚本执行失败时，结束该组件的打包流程并输出执行异常堆栈信息；当组件打包脚本执行成功时，在目标文件夹中生成与该组件相对应的组件文件，并按照预设的命名规则对组件文件执行重命名操作。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。

图4是本公开实施例提供的电子设备4的结构示意图。如图4所示，该实施例的电子设备4包括：处理器401、存储器402以及存储在该存储器402中并且可以在处理器401上运行的计算机程序403。处理器401执行计算机程序403时实现上述各个方法实施例中的步骤。或者，处理器401执行计算机程序403时实现上述各装置实施例中各模块/单元的功能。

示例性地，计算机程序403可以被分割成一个或多个模块/单元，一个或多个模块/单元被存储在存储器402中，并由处理器401执行，以完成本公开。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序403在电子设备4中的执行过程。

电子设备4可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备4可以包括但不仅限于处理器401和存储器402。本领域技术人员可以理解，图4仅仅是电子设备4的示例，并不构成对电子设备4的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如，电子设备还可以包括输入输出设备、网络接入设备、总线等。

处理器401可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器402可以是电子设备4的内部存储单元，例如，电子设备4的硬盘或内存。存储器402也可以是电子设备4的外部存储设备，例如，电子设备4上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，存储器402还可以既包括电子设备4的内部存储单元也包括外部存储设备。存储器402用于存储计算机程序以及电子设备所需的其它程序和数据。存储器402还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

在本公开所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本公开实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

以上实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的精神和范围，均应包含在本公开的保护范围之内。