CN110636111A - 资源打包方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开关于一种资源打包方法、装置、电子设备及存储介质。其中方法包括：从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件；根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合；在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合；将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包，并生成所述页面与所述静态资源包的映射关系。本公开能够降低资源服务器同时响应的资源请求的数量，提升页面的加载速度。

Description

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

技术领域

本公开涉及互联网技术领域，尤其涉及一种资源打包方法、装置、电子设备及存储介质。

背景技术

HTTP(Hyper Text Transfer Protocol，超文本传输协议)是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML(Hyper TextMarkup Language，超文本标记语言)页面的方法。

在HTTP/1.0时代，每个TCP(Transmission Control Protocol，传输控制协议)连接只能承载一个请求资源。升级到HTTP/1.1后，支持以Keep-Alive(长连接)的方式让同一个TCP连接承载多个资源请求，但是顺序必须是依次的，并且受TCP头部阻塞特性的影响，可能导致严重阻塞，因此对连接数的限制依然没有有效改善。

随着互联网的迅速发展，HTTP/2已经普遍被支持，其多路复用功能能真正支持多个资源在同一条TCP连接上并行请求，互不干涉。但是，在相关技术中对于每一个TCP连接来说，资源服务器所能同时响应的资源请求并不是无限的，并且基于资源服务器的计算能力，往往也会导致能响应的资源请求大大减少，如果同时响应的资源请求较多，则会显著增加响应时延，适得其反。

发明内容

本公开提供一种资源打包方法、装置、电子设备及存储介质，以至少解决相关技术中资源服务器能同时响应的资源请求较少，不能充分发挥HTTP/2多路复用的能力，导致页面加载速度较低的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种资源打包方法，包括：

从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件；

根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合；

在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合；

将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包，并生成所述页面与所述静态资源包的映射关系。

可选地，所述根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合步骤包括：分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中；在存在剩余未聚合的待处理的静态资源文件时，将所述剩余未聚合的待处理的静态资源文件中，文件名称的首字母相同的待处理的静态资源文件聚合到同一个第一集合中。

可选地，所述分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中步骤包括：获取所述待处理的静态资源文件对应的目录路径；分别将具有相同的根目录路径的静态资源文件聚合到同一个第一集合中。

可选地，所述根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合步骤包括：创建所述预设个数的第二集合，所述第二集合在初始创建时为空集合；从所述多个第一集合中随机选取所述预设个数的第一集合，分别将选取的每个第一集合分配到一个第二集合中；针对剩余的每个第一集合，将当前第一集合分配到包含的第一集合的文件体积总和最小的第二集合中，直至全部第一集合分配完为止。

可选地，所述生成所述页面与所述静态资源包的映射关系步骤包括：针对每个页面，获取当前页面与所述待处理的静态资源文件的映射关系；查找包含所述当前页面对应的待处理的静态资源文件的静态资源包；建立所述当前页面与查找到的静态资源包的映射关系。

可选地，所述从应用的各页面对应的静态资源文件中获取待处理的静态资源文件步骤包括：从应用的各页面对应的静态资源文件中获取所述页面依赖的第三方静态资源文件，将所述第三方静态资源文件作为所述待处理的静态资源文件。

根据本公开实施例的第二方面，提供一种资源打包装置，包括：

获取模块，被配置为执行从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件；

第一聚合模块，被配置为执行根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合；

第二聚合模块，被配置为执行在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合；

打包模块，被配置为执行将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包；

映射模块，被配置为执行生成所述页面与所述静态资源包的映射关系。

可选地，所述第一聚合模块包括：第一聚合子模块，被配置为执行分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中；第二聚合子模块，被配置为执行在存在剩余未聚合的待处理的静态资源文件时，将所述剩余未聚合的待处理的静态资源文件中，文件名称的首字母相同的待处理的静态资源文件聚合到同一个第一集合中。

可选地，所述第一聚合子模块包括：路径获取单元，被配置为执行获取所述待处理的静态资源文件对应的目录路径；路径聚合单元，被配置为执行分别将具有相同的根目录路径的静态资源文件聚合到同一个第一集合中。

可选地，所述第二聚合模块包括：创建子模块，被配置为执行创建所述预设个数的第二集合，所述第二集合在初始创建时为空集合；第一分配子模块，被配置为执行从所述多个第一集合中随机选取所述预设个数的第一集合，分别将选取的每个第一集合分配到一个第二集合中；第二分配子模块，被配置为执行针对剩余的每个第一集合，将当前第一集合分配到包含的第一集合的文件体积总和最小的第二集合中，直至全部第一集合分配完为止。

可选地，所述映射模块包括：映射获取子模块，被配置为执行针对每个页面，获取当前页面与所述待处理的静态资源文件的映射关系；查找子模块，被配置为执行查找包含所述当前页面对应的待处理的静态资源文件的静态资源包；建立子模块，被配置为执行建立所述当前页面与查找到的静态资源包的映射关系。

可选地，所述获取模块，具体用于从应用的各页面对应的静态资源文件中获取所述页面依赖的第三方静态资源文件，将所述第三方静态资源文件作为所述待处理的静态资源文件。

根据本公开实施例的第三方面，提供一种电子设备，其特征在于，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如上所述的资源打包方法。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如上所述的资源打包方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，包括可读程序代码，当所述可读程序代码在计算设备上运行时，可使计算设备执行如上所述的资源打包方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本公开的实施例中，从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件；根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合；在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合；将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包，并生成所述页面与所述静态资源包的映射关系。由此可知，本公开的实施例中一方面通过将页面对应的静态资源文件进行聚合打包，打包后的每个静态资源包对应一个资源请求，从而降低每个页面对应的资源请求的数量，也即降低资源服务器同时响应的资源请求的数量，提升页面的加载速度；另一方面先根据待处理的静态资源文件在功能上的关联关系进行聚合，能够保证具有关联功能的静态资源文件被打包到一起，从而降低其他不相关的静态资源文件的影响；再一方面如果根据功能聚合后第一集合的数量仍然较多，再根据文件体积对静态资源文件进一步聚合，保证每个聚合后的第二集合的文件体积更加平均，避免体积不均导致体积较大的文件影响到整体的加载速度。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

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

图1是根据一示例性实施例示出的一种资源打包方法的流程图。

图2是根据一示例性实施例示出的一种资源打包方法的流程图。

图3是根据一示例性实施例示出的一种第一集合的示意图。

图4是根据一示例性实施例示出的一种第二集合的示意图。

图5是根据一示例性实施例示出的一种页面与静态资源包的映射关系的示意图。

图6是根据一示例性实施例示出的一种资源打包装置的框图。

图7是根据一示例性实施例示出的一种装置的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种资源打包方法的流程图。资源打包方法可以用于电子设备中，该电子设备可以为服务器。如图1所示，资源打包方法包括以下步骤。

在步骤S11中，从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件。

本实施例中的应用为Web应用。Web应用是一种可以通过Web访问的应用程序，这类应用程序一般借助浏览器来运行。Web应用可以包括多个页面，每个页面对应多个静态资源文件，静态资源文件可以包括JS(JavaScript，爪哇脚本，一种直译式脚本语言)文件、CSS(Cascading Style Sheets，层叠样式表)文件、Image(图像)文件等。

服务器中保存有应用的各页面对应的全部静态资源文件。考虑到服务器能同时响应的资源请求较少的问题，可以对静态资源文件进行打包，从而降低静态资源文件的数量，减少响应的资源请求的数量。服务器从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件，这些待处理的静态资源文件即为等待打包的静态资源文件。

在步骤S12中，根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合。

每个静态资源文件具有各自对应的功能，并且某些静态资源文件在功能上是具有关联关系的，这些在功能上具有关联关系的静态资源文件可能会被同一个页面依赖。因此，根据多个待处理的静态资源文件在功能上的关联关系，对多个待处理的静态资源文件进行聚合，可以将在功能上具有关联关系的待处理的静态资源文件聚合到一起。聚合之后可以得到多个第一集合，每个第一集合中包括一个或多个待处理的静态资源文件。

在步骤S13中，在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合。

考虑到服务器的计算能力的限制，能够同时响应的资源请求数量有限，也即能够同时返回给客户端的资源文件有限，因此如果第一集合的数量仍然较多，超过了服务器的处理能力，则还要对第一集合进行进一步地聚合，得到数量更少的第二集合。本实施例中设置预设个数，在第一集合的个数超过预设个数时，将第一集合进一步聚合为该预设个数的第二集合。在对第一集合进行聚合时，可以基于体积平均的原则聚合，对于具体的实现过程，将在下面的实施例说详细介绍。

对于预设个数的具体数值，本领域技术人员根据实际经验选用任意适用的数值均可，本实施例对此不作限制。比如，为了更加符合服务器的计算能力，可以根据服务器能够同时响应的资源请求的数量，可以设置预设个数小于或等于服务器能够同时响应的资源请求的数量。

在步骤S14中，将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包，并生成所述页面与所述静态资源包的映射关系。

对于聚合得到的每个第二集合，可以将当前第二集合中待处理的静态资源文件打包成一个静态资源包，从而得到与第二集合数量相同的静态资源包。得到静态资源包后，生成应用的页面与静态资源包的映射关系，后续在客户端请求页面时，服务器可以根据该映射关系返回页面对应的静态资源包。

本公开的实施例中，一方面通过将页面对应的静态资源文件进行聚合打包，打包后的每个静态资源包对应一个资源请求，从而降低每个页面对应的资源请求的数量，也即降低资源服务器同时响应的资源请求的数量，提升页面的加载速度；另一方面先根据待处理的静态资源文件在功能上的关联关系进行聚合，能够保证具有关联功能的静态资源文件被打包到一起，从而降低其他不相关的静态资源文件的影响；再一方面如果根据功能聚合后第一集合的数量仍然较多，再根据文件体积对静态资源文件进一步聚合，保证每个聚合后的第二集合的文件体积更加平均，避免体积不均导致体积较大的文件影响到整体的加载速度。

图2是根据一示例性实施例示出的一种资源打包方法的流程图。如图2所示，资源打包方法包括以下步骤。

在步骤S21中，从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件。

页面对应的静态资源文件可以分为页面依赖的原生静态资源文件(源代码)和页面依赖的第三方静态资源文件。对于各页面依赖的原生静态资源文件，可以针对每个页面，将当前页面依赖的原生静态资源文件打包成一个静态资源包。对于各页面依赖的第三方静态资源文件，如果盲目地将全部待处理的静态资源文件打包成一个静态资源包，虽然能够减少响应的资源请求的数量，有利于页面之间切换访问的效率(由于缓存的作用)，但是有的页面依赖的第三方静态资源文件较多，有的则较少，因此对于业务相对独立的页面来说，加载了较多不必要的代码，反而影响自身的首次加载速度和每次运行的代码解析速度，并且一旦一个页面所依赖的第三方静态资源文件增减，则同时会影响其它所有页面的客户端缓存，牵一发动全身，无利于客户端的长期浏览器体验。

因此，本实施例的资源打包方法可以针对各页面依赖的第三方静态资源文件，可以将各页面依赖的全部第三方静态资源文件进行聚合，打包成多个静态资源包。因此，服务器从应用的各页面对应的静态资源文件中获取各页面依赖的第三方静态资源文件，将获取的第三方静态资源文件作为待处理的静态资源文件。其中，待处理的静态资源文件可以为JS文件和CSS文件中的任意一种类型。

在步骤S22中，根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合。

在一种可选实施方式中，步骤S22可以包括步骤A1～A2：

步骤A1，分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中。

不同的静态资源文件可能会具有关联功能。比如，文件名称为React的静态资源文件(JS文件)的功能是构建用户界面，文件名称为React-Dom的静态资源文件(JS文件)的功能是把React组件中包含的虚拟Dom渲染成实际Dom，文件名称为Prop-Types的静态资源文件(JS文件)的功能是对React组件中包含的Props对象中的变量进行类型检测，因此文件名称为React、文件名称为React-Dom和文件名称为Prop-Types的JS文件即为具有关联功能的JS文件。在进行聚合时，将具有关联功能的待处理的静态资源文件聚合到同一个第一集合中，避免其受其他不相关文件的影响。

在一种可选实施方式中，步骤A1具体可以包括：获取所述待处理的静态资源文件对应的目录路径；分别将具有相同的根目录路径的静态资源文件聚合到同一个第一集合中。

服务器中保存有应用的各页面对应的静态资源文件的目录，每个静态资源文件对应一个目录路径。该目录可以为树形目录，比如在生成目录时可以按照待处理的静态资源文件在功能上的关联关系设置根目录路径、父目录路径、子目录路径等。比如，对于上述的文件名称为React、文件名称为React-Dom和文件名称为Prop-Types的JS文件三者来说，根据文件的功能可以得知，React的目录路径应该为React-Dom和Prop-Types的父目录路径，比如为R1；React-Dom的目录路径为React的子目录路径，比如为R1-1；Prop-Types的目录路径为React的子目录路径，比如为R1-2。如果R1没有父目录路径，则R1作为根目录路径，因此文件名称为React、文件名称为React-Dom和文件名称为Prop-Types的三个JS文件具有相同的根目录路径R1，因此可以将这三个JS文件聚合到同一个第一集合中。

步骤A2，在存在剩余未聚合的待处理的静态资源文件时，将所述剩余未聚合的待处理的静态资源文件中，文件名称的首字母相同的待处理的静态资源文件聚合到同一个第一集合中。

经过上述步骤A1聚合之后，如果不存在剩余未聚合的待处理的静态资源文件，则可以执行步骤S23。如果存在剩余未聚合的待处理的静态资源文件，则对剩余未聚合的待处理的静态资源文件继续进行聚合。

在一种可选实施方式中，为了使处理过程更加简便，可以按照文件名称的首字母进行聚合，将剩余未聚合的待处理的静态资源文件中，文件名称的首字母相同的待处理的静态资源文件聚合到同一个第一集合中。

经过步骤S22，可以将多个待处理的静态资源文件聚合为多个第一集合。下面以图3为例进行说明。

图3是根据一示例性实施例示出的一种第一集合的示意图。如图3所示，待处理的静态资源文件包括a.js、b.js、c.js、d.js、e.js、f.js、g.js和h.js，经过步骤S22的聚合后，将a.js和d.js聚合到同一个第一集合set1-1中，将f.js和g.js聚合到同一个第一集合set1-2中，将b.js、c.js、e.js和h.js聚合到同一个第一集合set1-3中。

在步骤S23中，判断所述第一集合的个数是否超过预设个数。若是，则执行步骤S24；若否，则执行步骤S26。

考虑到单个HTTP连接所能同时承载的资源请求数量的限制，比如Nginx(代理服务器)的默认配置是只能同时接受128个资源请求。但是由于服务器计算能力的限制，服务器能同时响应的资源请求数量会更少，比如普通的服务器可以同时响应7～8个资源请求。进一步地考虑到其它非静态资源文件也可能占用HTTP连接，则服务器能同时响应的静态资源请求的数量会进一步减少，比如对于静态资源文件来说，可以同时响应4～6个资源请求。

因此，在聚合得到多个第一集合后，还要进一步判断第一集合的个数是否超过预设个数，以便确定是否继续对第一集合进行聚合。该预设个数可以根据服务器的计算能力设置任意适用的数值。

在步骤S24中，在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合。

在第一集合的个数超过(也即大于)预设个数时，可以对第一集合进行进一步聚合，以便得到相比于第一集合数量更少的第二集合。

本实施例中，对第一集合进一步聚合的原则是尽量平均体积，毕竟遵循木桶原理(一只水桶能装多少水取决于它最短的那块木板)，体积最大响应最慢的文件的加载会影响到整体加载速度，平均体积是取得多文件并行加载速度的重要保证。因此，可以根据第一集合的文件体积将多个第一集合聚合为所述预设个数的第二集合。

在一种可选实时方式中，步骤S24可以包括步骤B1～B3：

步骤B1，创建所述预设个数的第二集合。

步骤S24的目的是将第一集合进一步聚合为预设个数的第二集合。首先创建预设个数的第二集合，第二集合在初始创建时为空集合，后续向第二集合中分配第一集合。

步骤B2，从所述多个第一集合中随机选取所述预设个数的第一集合，分别将选取的每个第一集合分配到一个第二集合中。

在第一次分配时，从多个第一集合中随机选取预设个数的第一集合，分别将选取的每个第一集合随机分配到一个第二集合中。比如，预设个数为5，则创建5个第二集合，从多个第一集合中随机选取5个第一集合，分别将5个第一集合随机分配到5个第二集合中，分配后每个第二集合中包含一个第一集合。

步骤B3，针对剩余的每个第一集合，将当前第一集合分配到包含的第一集合的文件体积总和最小的第二集合中，直至全部第一集合分配完为止。

遍历剩余未分配的第一集合，针对剩余的每个第一集合，在对当前第一集合进行分配时，获取每个第二集合中包含的第一集合的文件体积总和，选取其中包含的第一集合的文件体积总和最小的第二集合，将当前第一集合分配到选取的第二集合中。

其中，每个待处理的静态资源文件各自具有文件体积。服务器可以获取到每个待处理的静态资源文件的文件体积；针对每个第一集合计算当前第一集合包含的全部待处理的静态资源文件的文件体积的总和，作为当前第一集合的文件体积；针对每个第二集合，计算当前第二集合包含的全部第一集合的文件体积的总和。

图4是根据一示例性实施例示出的一种第二集合的示意图。以图4为例，创建的第二集合包括set2-1、set2-2、set2-3、……、set2-max，其中max为上述预设个数。第二集合中的灰度部分表示包含的第一集合的文件体积总和，图4中包含的第一集合的文件体积总和最小的第二集合为set2-1，因此在对当前第一集合进行分配时，将当前第一集合分配到第二集合set2-1中。

在对全部第一集合分配完后，即可结束分配，得到由多个第一集合聚合而成的预设个数的第二集合。根据上述基于体积的聚合方式虽然不能保证得出的第二集合的大小是严格平均的，但是精确度并不会特别影响最终的效果，而且算法复杂度小，方便操作。

在步骤S25中，将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包。之后执行步骤S27。

经过上述处理后得到预设个数的第二集合，服务器将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包，从而得到预设个数的静态资源包。

在步骤S26中，将每个第一集合中待处理的静态资源文件分别打包成一个静态资源包。之后执行步骤S27。

在第一集合的个数未超过(也即小于等于)预设个数时，可以不再对第一集合进行进一步聚合。服务器将每个第一集合中待处理的静态资源文件分别打包成一个静态资源包，从而得到与第一集合的个数相同的静态资源包。

步骤S27，生成所述页面与所述静态资源包的映射关系。

经过上述打包后得到多个静态资源包，每个页面要加载的第三方静态资源文件中，要包含依赖的全部的第三方静态资源文件，但每个页面依赖的全部第三方静态资源文件可能并未被打包到同一个静态资源包中，其可能分散被打包到多个静态资源包中，因此还要进一步生成页面与静态资源包的映射关系，将页面要加载的静态资源包对应挂载到相应的页面中。需要说明的是，页面要加载的静态资源文件还包括自身依赖的原生静态资源文件，该类静态资源文件也要建立与页面的映射关系，从而保证页面能够加载它所需要的全部静态资源文件。本实施例在此主要介绍生成页面与静态资源包的映射关系的过程。

在一种可选实施方式中，步骤S27包括：针对每个页面，获取当前页面与所述待处理的静态资源文件的映射关系；查找包含所述当前页面对应的待处理的静态资源文件的静态资源包；建立所述当前页面与查找到的静态资源包的映射关系。

服务器中保存有每个页面与其所依赖的第三方静态资源文件(也即待处理的静态资源文件)的映射关系。针对每个页面中的当前页面，从当前页面与待处理的静态资源文件的映射关系中查找当前页面对应的待处理的静态资源文件，从静态资源包中查找包含当前页面对应的待处理的静态资源文件的静态资源包，查找到的静态资源包即为当前页面要加载的静态资源包，因此建立当前页面与查找到的静态资源包的映射关系。

图5是根据一示例性实施例示出的一种页面与静态资源包的映射关系的示意图。以图5为例，对于页面index.html来说，与该页面index.html具有映射关系的静态资源包为chunk-1.js，该静态资源包chunk-1.js中包含静态资源文件a.js和静态资源文件d.js；对于页面about.html来说，与该页面about.html具有映射关系的静态资源包为chunk-2.js，该静态资源包chunk-2.js中包含静态资源文件f.js和静态资源文件g.js。其中，Chunk指多个Module(模块)聚合而成的JavaScript文件，直接嵌入到HTML中进行下载，Module指ECMAScript Module(European Computer Manufactures Association Script Module，欧洲计算机制造联合会脚本模块)，一般泛指一个JavaScript文件。

生成页面与静态资源包的映射关系后，如果服务器接收到客户端的页面资源请求，则从该映射关系中查找请求的页面对应的静态资源包，将查找到的静态资源包返回给客户端，客户端即可加载自己所需的静态资源文件。需要说明的是，页面对应的静态资源包中还可能包含该页面不需要的静态资源文件，比如图5中，页面index.html可能只需要a.js，但实际上加载的是chunk-1.js，也就是包含了不会用到的d.js。但是这是可以接受的，事实上，这已经比盲目地将所有第三方静态资源文件打包成一个静态资源文件优化了很多。

本公开的实施例中，极大降低了多页面项目中每个页面的静态资源体积，提高了加载和运行速度，有效加速了静态资源通过HTTP协议的下载速度，间接加速了所在页面的加载速度，兼顾HTTP多路复用特性和服务器响应能力的打包策略，增加并行资源请求数但不使加载性能恶化，并行资源请求的最优化均分算法，最大化降低木桶效应的影响。

图6是根据一示例性实施例示出的一种资源打包装置框图。参照图6，该装置包括获取模块601，第一聚合模块602、第二聚合模块603、打包模块604和映射模块605。

获取模块601，被配置为执行从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件。

第一聚合模块602，被配置为执行根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合。

第二聚合模块603，被配置为执行在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合。

打包模块604，被配置为执行将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包。

映射模块605，被配置为执行生成所述页面与所述静态资源包的映射关系。

在一种可选实施方式中，所述第一聚合模块602包括：第一聚合子模块，被配置为执行分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中；第二聚合子模块，被配置为执行在存在剩余未聚合的待处理的静态资源文件时，将所述剩余未聚合的待处理的静态资源文件中，文件名称的首字母相同的待处理的静态资源文件聚合到同一个第一集合中。

在一种可选实施方式中，所述第一聚合子模块包括：路径获取单元，被配置为执行获取所述待处理的静态资源文件对应的目录路径；路径聚合单元，被配置为执行分别将具有相同的根目录路径的静态资源文件聚合到同一个第一集合中。

在一种可选实施方式中，所述第二聚合模块603包括：创建子模块，被配置为执行创建所述预设个数的第二集合，所述第二集合在初始创建时为空集合；第一分配子模块，被配置为执行从所述多个第一集合中随机选取所述预设个数的第一集合，分别将选取的每个第一集合分配到一个第二集合中；第二分配子模块，被配置为执行针对剩余的每个第一集合，将当前第一集合分配到包含的第一集合的文件体积总和最小的第二集合中，直至全部第一集合分配完为止。

在一种可选实施方式中，所述映射模块605包括：映射获取子模块，被配置为执行针对每个页面，获取当前页面与所述待处理的静态资源文件的映射关系；查找子模块，被配置为执行查找包含所述当前页面对应的待处理的静态资源文件的静态资源包；建立子模块，被配置为执行建立所述当前页面与查找到的静态资源包的映射关系。

在一种可选实施方式中，所述获取模块601，具体用于从应用的各页面对应的静态资源文件中获取所述页面依赖的第三方静态资源文件，将所述第三方静态资源文件作为所述待处理的静态资源文件。

本公开的实施例中，一方面通过将页面对应的静态资源文件进行聚合打包，打包后的每个静态资源包对应一个资源请求，从而降低每个页面对应的资源请求的数量，也即降低资源服务器同时响应的资源请求的数量，提升页面的加载速度；另一方面先根据待处理的静态资源文件在功能上的关联关系进行聚合，能够保证具有关联功能的静态资源文件被打包到一起，从而降低其他不相关的静态资源文件的影响；再一方面如果根据功能聚合后第一集合的数量仍然较多，再根据文件体积对静态资源文件进一步聚合，保证每个聚合后的第二集合的文件体积更加平均，避免体积不均导致体积较大的文件影响到整体的加载速度。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图7是根据一示例性实施例示出的一种用于资源打包的装置700的框图。例如，装置700可以被提供为一服务器。

参照图7，装置700包括处理组件722，其进一步包括一个或多个处理器，以及由存储器732所代表的存储器资源，用于存储可由处理组件722的执行的指令，例如应用程序。存储器732中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件722被配置为执行指令，以执行上述方法。

装置700还可以包括一个电源组件726被配置为执行装置700的电源管理，一个有线或无线网络接口750被配置为将装置700连接到网络，和一个输入输出(I/O)接口758。装置700可以操作基于存储在存储器732的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM或类似。

在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器，上述指令可由资源打包装置的处理器执行以完成上述方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品，该计算机程序产品包括可读性程序代码，该可读性程序代码可由资源打包装置的处理器执行以完成上述方法。可选地，该程序代码可以存储在资源打包装置的存储介质中，该存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种资源打包方法，其特征在于，包括：

从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件；

根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合；

在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合；

将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包，并生成所述页面与所述静态资源包的映射关系。

2.根据权利要求1所述的资源打包方法，其特征在于，所述根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合步骤包括：

分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中；

在存在剩余未聚合的待处理的静态资源文件时，将所述剩余未聚合的待处理的静态资源文件中，文件名称的首字母相同的待处理的静态资源文件聚合到同一个第一集合中。

3.根据权利要求2所述的资源打包方法，其特征在于，所述分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中步骤包括：

获取所述待处理的静态资源文件对应的目录路径；

分别将具有相同的根目录路径的静态资源文件聚合到同一个第一集合中。

4.根据权利要求1所述的资源打包方法，其特征在于，所述根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合步骤包括：

创建所述预设个数的第二集合，所述第二集合在初始创建时为空集合；

从所述多个第一集合中随机选取所述预设个数的第一集合，分别将选取的每个第一集合分配到一个第二集合中；

针对剩余的每个第一集合，将当前第一集合分配到包含的第一集合的文件体积总和最小的第二集合中，直至全部第一集合分配完为止。

5.根据权利要求1所述的资源打包方法，其特征在于，所述生成所述页面与所述静态资源包的映射关系步骤包括：

针对每个页面，获取当前页面与所述待处理的静态资源文件的映射关系；

查找包含所述当前页面对应的待处理的静态资源文件的静态资源包；

建立所述当前页面与查找到的静态资源包的映射关系。

6.根据权利要求1所述的资源打包方法，其特征在于，所述从应用的各页面对应的静态资源文件中获取待处理的静态资源文件步骤包括：

从应用的各页面对应的静态资源文件中获取所述页面依赖的第三方静态资源文件，将所述第三方静态资源文件作为所述待处理的静态资源文件。

7.一种资源打包装置，其特征在于，包括：

获取模块，被配置为执行从应用的各页面对应的静态资源文件中获取多个待处理的静态资源文件；

第一聚合模块，被配置为执行根据所述多个待处理的静态资源文件在功能上的关联关系，将所述多个待处理的静态资源文件聚合为多个第一集合；

第二聚合模块，被配置为执行在所述第一集合的个数超过预设个数时，根据所述第一集合的文件体积将所述多个第一集合聚合为所述预设个数的第二集合；

打包模块，被配置为执行将每个第二集合中待处理的静态资源文件分别打包成一个静态资源包；

映射模块，被配置为执行生成所述页面与所述静态资源包的映射关系。

8.根据权利要求7所述的资源打包装置，其特征在于，所述第一聚合模块包括：

第一聚合子模块，被配置为执行分别将所述多个待处理的静态资源文件中，具有关联功能的待处理的静态资源文件聚合到同一个第一集合中；

第二聚合子模块，被配置为执行在存在剩余未聚合的待处理的静态资源文件时，将所述剩余未聚合的待处理的静态资源文件中，文件名称的首字母相同的待处理的静态资源文件聚合到同一个第一集合中。

9.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至6中任一项所述的资源打包方法。

10.一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至6中任一项所述的资源打包方法。

Images