一种web前端项目编译速度优化方法、设备及介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种web前端项目编译速度优化方法、设备及介质。

背景技术

Webpack是代码编译工具，有入口、出口、loader和插件。Webpack是一个用于现代JavaScript应用程序的静态模块打包工具。当Webpack处理应用程序时，它会在内部构建一个依赖图(dependency graph)，此依赖图对应映射到项目所需的每个模块，并生成一个或多个bundle。

在前端项目开发过程中，通常使用Webpack来构建前端项目，并使用编辑器编译、运行，随着项目的不断迭代，项目文件和体积会非常庞大，项目编译的时间也会随之增加。前端人员开发的时候每次修改文件都会等比较长的时间才能看到效果，过长的编译时间以致影开发人员的工作效率。

发明内容

本申请实施例提供了一种web前端项目编译速度优化方法、设备及介质，用于解决如下技术问题：前端人员开发的时候每次修改文件都会等比较长的时间才能看到效果，过长的编译时间以致影开发人员的工作效率。

本申请实施例采用下述技术方案：

本申请实施例提供一种web前端项目编译速度优化方法。包括，通过预置打包速度获取插件，确定出当前构建的待优化web前端项所对应的打包速度。将待优化web前端项所对应的打包速度与第一预置速度阈值进行比对，以确定出待优化模块；基于待优化模块的数量，构建多个nodejs进程，并通过配置文件查找范围，以缩小打包范围；将打包速度大于第二预置速度阈值的打包结果进行缓存，以完成web前端项目编译速度优化。

本申请实施例通过确定出当前构建的待优化web前端项所对应的打包速度，并基于该打包速度确定出需要优化的模块，能够对打包速度进行初步分析，将打包速度符合要求的模块进行筛选，从而减少需要优化的模块的数量，降低工作量。其次，本申请实施例通过构建多个进程，能够提升构建速度，提高打包速度。此外，本申请实施例通过对打包结果进行缓存，无需重新多次进行转换，从而进一步提高打包速度。

在本申请的一种实现方式中，通过预置打包速度获取插件，确定出当前构建的待优化web前端项所对应的打包速度，具体包括：响应于插件安装命令，对预置打包速度获取插件进行安装；在预置webpack.config.js文件中进行配置，以使预置打包速度获取插件对当前构建的待优化web前端项所对应的打包速度进行获取；其中，获取到的打包速度至少包括Webpack的总打包耗时、各plugin的打包耗时以及loader的打包耗时。

在本申请的一种实现方式中，将待优化web前端项所对应的打包速度与第一预置速度阈值进行比对，以确定出待优化模块，具体包括：将Webpack的总打包耗时与预置总打包耗时阈值进行比对；以及将各plugin的打包耗时分与相应的各plugin的预置打包耗时阈值进行比对；以及将loader的打包耗时与相应的预置loader打包耗时阈值进行比对；将打包耗时大于打包耗时阈值的模块，作为待优化模块。

在本申请的一种实现方式中，基于待优化模块的数量，构建多个nodejs进程，具体包括：确定出待优化模块的数量，并基于待优化模块的数量确定出开启的进程的数量；响应于多进程构建命令，通过thread-loader进行多个nodejs进程构建，并在预置webpack.config.js文件中进行配置。

在本申请的一种实现方式中，通过配置文件查找范围，以缩小打包范围，具体包括：基于当前构建的待优化web前端项所对应数据信息，确定出相应的文件范围；在预置webpack.config.js文件中对文件范围进行设置，以缩小打包范围。

在本申请的一种实现方式中，将通过多线程构建多个nodejs进程，具体包括：将当前任务分解多个子任务，并将多个子任务分别分配至多个子进程并发执行；在多个子进程将相应的子任务执行完成后，将相应的子任务处理结果发送至主进程。

在本申请的一种实现方式中，将当前任务分解多个子任务之前，方法还包括：响应于子进程执行命令，在预置文件webpack.config.js，对HappyPack插件进行配置；其中，HappyPack插件用于构建多进程任务。

在本申请的一种实现方式中，将打包速度大于第二预置速度阈值的打包结果进行缓存，具体包括：确定出打包速度大于第二预置速度阈值的待处理文件加载器；响应于缓存安装命令，在待处理文件加载器之前添加cache-loader，基于预置缓存路径，对打包结果进行缓存。

本申请实施例提供一种web前端项目编译速度优化设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够：通过预置打包速度获取插件，确定出当前构建的待优化web前端项所对应的打包速度；将待优化web前端项所对应的打包速度与第一预置速度阈值进行比对，以确定出待优化模块；基于待优化模块的数量，构建多个nodejs进程，并通过配置文件查找范围，以缩小打包范围；将打包速度大于第二预置速度阈值的打包结果进行缓存，以完成web前端项目编译速度优化。

本申请实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：通过预置打包速度获取插件，确定出当前构建的待优化web前端项所对应的打包速度；将待优化web前端项所对应的打包速度与第一预置速度阈值进行比对，以确定出待优化模块；基于待优化模块的数量，构建多个nodejs进程，并通过配置文件查找范围，以缩小打包范围；将打包速度大于第二预置速度阈值的打包结果进行缓存，以完成web前端项目编译速度优化。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例通过确定出当前构建的待优化web前端项所对应的打包速度，并基于该打包速度确定出需要优化的模块，能够对打包速度进行初步分析，将打包速度符合要求的模块进行筛选，从而减少需要优化的模块的数量，降低工作量。其次，本申请实施例通过构建多个进程，能够提升构建速度，提高打包速度。此外，本申请实施例通过对打包结果进行缓存，无需重新多次进行转换，从而进一步提高打包速度。

附图说明

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

图1为本申请实施例提供的一种web前端项目编译速度优化方法流程图；

图2为本申请实施例提供的一种web前端项目编译速度优化整体流程图；

图3为本申请实施例提供的一种web前端项目编译速度优化设备的结构示意图。

具体实施方式

本申请实施例提供一种web前端项目编译速度优化方法、设备及介质。

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

下面通过附图对本申请实施例提出的技术方案进行详细的说明。

图1为本申请实施例提供的一种web前端项目编译速度优化方法流程图，如图1所示，web前端项目编译速度优化方法包括如下步骤：

S101、通过预置打包速度获取插件，确定出当前构建的待优化web前端项所对应的打包速度。

在本申请的一个实施例中，响应于插件安装命令，对预置打包速度获取插件进行安装。在预置webpack.config.js文件中进行配置，以使预置打包速度获取插件对当前构建的待优化web前端项所对应的打包速度进行获取。其中，获取到的打包速度至少包括Webpack的总打包耗时、各plugin的打包耗时以及loader的打包耗时。

具体地，首先使用Webpack构建web前端项目。先进行打包速度分析，在进行打包速度优化之前，需要对当前项目每个部分的打包时间了解清楚。

进一步地，本申请实施例借助speed-measure-webpack-plugin插件，通过该speed-measure-webpack-plugin插件分析Webpack的总打包耗时以及每个plugin和loader的打包耗时，从而对打包时间较长的部分进行针对性优化。

进一步地，通过以下命令安装插件：

npminstall speed-measure-webpack-plugin–D，并在webpack.config.js文件中进行配置，再次build就能看到各个部分的打包耗时。

S102、将所述待优化web前端项所对应的打包速度与第一预置速度阈值进行比对，以确定出待优化模块。

在本申请的一个实施例中，在本申请的一个实施例中，将Webpack的总打包耗时与预置总打包耗时阈值进行比对。以及将各plugin的打包耗时分与相应的各plugin的预置打包耗时阈值进行比对。以及将loader的打包耗时与相应的预置loader打包耗时阈值进行比对。将打包耗时大于打包耗时阈值的模块，作为待优化模块。

具体地，不同的打包分别对应不同的打包耗时，因此，对不同的打包耗时分别进行分析，将将Webpack的总打包耗时与预置总打包耗时阈值进行比对。将各plugin的打包耗时分与相应的各plugin的预置打包耗时阈值进行比对。将loader的打包耗时与相应的预置loader打包耗时阈值进行比对，从而确定出不同的打包结果分别是否超过打包耗时阈值，若超过相应的打包耗时阈值，则说明当前打包耗时结果不符合要求，需要对其进行优化，从而将其作为待优化模块。

S103、基于所述待优化模块的数量，通过多线程构建多个nodejs进程，并通过配置文件查找范围，以缩小打包范围。

在本申请的一个实施例中，确定出待优化模块的数量，并基于待优化模块的数量确定出开启的进程的数量。响应于多进程构建命令，通过thread-loader进行多个nodejs进程构建，并在预置webpack.config.js文件中进行配置。

具体地，对于耗时较长的模块，同时开启多个nodejs进程进行构建，可以有效地提升打包的速度。本申请实施例采用thread-loader进行多进程构建。通过以下命令安装插件：npminstall thread-loader–D在webpack.config.js文件中进行配置。

在本申请的一个实施例中，基于当前构建的待优化web前端项所对应数据信息，确定出相应的文件范围。在预置webpack.config.js文件中对文件范围进行设置，以缩小打包范围。

具体地，由于构建过程是默认全局查找，这非常的耗时。通过配置rules中的文件查找范围，可以减少打包的范围，从而提升打包的速度。具体地，可以在webpack.config.js文件中对查找范围对应的文件进行配置。

在本申请的一个实施例中，将当前任务分解多个子任务，并将多个子任务分别分配至多个子进程并发执行。在多个子进程将相应的子任务执行完成后，将相应的子任务处理结果发送至主进程。

在本申请的一个实施例中，响应于子进程执行命令，在预置文件webpack.config.js，对HappyPack插件进行配置。其中，HappyPack插件用于构建多进程任务。

具体地，由于有大量文件需要解析和处理，构建是文件读写和计算密集型的操作，特别是当文件数量变多后，Webpack构建慢的问题会显得严重。文件读写和计算操作是无法避免的，使用能让Webpack同一时刻处理多个任务，发挥多核CPU电脑的威力，以提升构建速度。

本申请实施例在接收到子进程执行命令后，通过HappyPack插件将任务分解给多个子进程去并发的执行，子进程处理完后再把结果发送给主进程。

通过以下命令安装插件：npminstall happypack–D在webpack.config.js文件中进行相应配置。

S104、将打包速度大于第二预置速度阈值的打包结果进行缓存，以完成web前端项目编译速度优化。

在本申请的一个实施例中，确定出打包速度大于所述第二预置速度阈值的待处理文件加载器。响应于缓存安装命令，在待处理文件加载器之前添加cache-loader，基于预置缓存路径，对打包结果进行缓存。

具体地，确定出打包速度大于所述第二预置速度阈值的待处理文件加载器，即，确定出的待处理文件加载器性能开销较大，在这些性能开销较大的loader之前添加cache-loader，将结果缓存中磁盘中。默认保存在node_modueles/.cache/cache-loader目录下。

通过以下命令安装插件：npminstall cache-loader–D，并在webpack.config.js文件中进行相应配置。

本申请实施例通过确定出当前构建的待优化web前端项所对应的打包速度，并基于该打包速度确定出需要优化的模块，能够对打包速度进行初步分析，将打包速度符合要求的模块进行筛选，从而减少需要优化的模块的数量，降低工作量。其次，本申请实施例通过构建多个进程，能够提升构建速度，提高打包速度。此外，本申请实施例通过对打包结果进行缓存，无需重新多次进行转换，从而进一步提高打包速度。

图2为本申请实施例提供的一种web前端项目编译速度优化整体流程图。如图2所示，对web前端项目编译速度优化时，包括如下过程：

1.首先进行打包速度分析，具体地，借助speed-measure-webpack-plugin插件，它分析Webpack的总打包耗时以及每个plugin和loader的打包耗时，从而对打包时间较长的部分进行针对性优化。

2.多进程构建，对于耗时较长的模块，同时开启多个nodejs进程进行构建，可以有效地提升打包的速度。本申请实施例采用thread-loader进行多进程构建。

3.缩小构建范围，构建过程是默认全局查找，这非常的耗时。通过配置rules中的文件查找范围，可以减少打包的范围，从而提升打包的速度。

4.使用HappyPack构建，由于有大量文件需要解析和处理，构建是文件读写和计算密集型的操作，特别是当文件数量变多后，Webpack构建慢的问题会显得严重。文件读写和计算操作是无法避免的，使用能让Webpack同一时刻处理多个任务，发挥多核CPU电脑的威力，以提升构建速度。它把任务分解给多个子进程去并发的执行，子进程处理完后再把结果发送给主进程。

5.缓存，在一些性能开销较大的loader之前添加cache-loader，将结果缓存中磁盘中。

通过以上配置，可以将项目的编译时间从17.37秒缩短到了1.36秒，提高了开发效率。

图3为本申请实施例提供的一种web前端项目编译速度优化设备的结构示意图。如图3所示，web前端项目编译速度优化设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：通过预置打包速度获取插件，确定出当前构建的待优化web前端项所对应的打包速度；将所述待优化web前端项所对应的打包速度与第一预置速度阈值进行比对，以确定出待优化模块；基于所述待优化模块的数量，通过多线程构建多个nodejs进程，并通过配置文件查找范围，以缩小打包范围；将打包速度大于第二预置速度阈值的打包结果进行缓存，以完成web前端项目编译速度优化。

本申请实施例还提供一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：通过预置打包速度获取插件，确定出当前构建的待优化web前端项所对应的打包速度；将所述待优化web前端项所对应的打包速度与第一预置速度阈值进行比对，以确定出待优化模块；基于所述待优化模块的数量，通过多线程构建多个nodejs进程，并通过配置文件查找范围，以缩小打包范围；将打包速度大于第二预置速度阈值的打包结果进行缓存，以完成web前端项目编译速度优化。

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

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

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

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

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

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

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

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请的实施例可以有各种更改和变化。而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。