CN109145236A - 页面文件处理方法、装置及*** - Google Patents

Abstract

本公开是关于一种页面文件处理方法、装置及***。该方法包括：获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。本公开可以可以提高页面加载性能，提升网页运行时的性能。

Description

页面文件处理方法、装置及***

技术领域

本公开涉及互联网技术领域，尤其涉及一种页面文件处理方法、页面文件处理装置以及页面文件处理***。

背景技术

随着互联网时代的到来，尤其是近年来移动互联网的发展，各种Web应用大量涌现，由此使得网站的前端发生了翻天覆地的变化。例如，网页不再只是承载单一的文字和图片，各种丰富的媒体让网页的内容更加生动，且网页上的交互形式为用户提供了更好的使用体验。然而这些都是基于Web前端技术实现的。

相关技术中，通常需要为网页编写用于提供网页功能的多个模块，以供页面在展现时可以从服务器获取相应的模块文件资源，从而实现相应的功能。比较典型的是通过编写JavaScript脚本来实现模块功能。而目前的网页中由于功能较多导致模块数量较多，相应的生成的文件数量也就越多。这些文件提供到网站服务器供网页调用时，会导致网页从服务器获取大量的文件，造成传输效率低下，影响网页加载效率。且随着网页功能越来越多样化，其Web前端开发也变得越来越复杂，此时就需要兼顾开发的便捷性和网页运行时的性能，而目前还未有较好的解决方案。

因此，有必要提供一种新的技术方案改善上述方案中存在的一个或者多个问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种页面文件处理方法、页面文件处理装置以及页面文件处理***，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开实施例的第一方面，提供一种页面文件处理方法，该方法包括：

获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；

通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；

响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。

本公开的一种示例性实施例中，所述通过加载器将多个所述第一文件打包生成统一预设格式的多个第二文件包括：

根据所述第一文件的类型，使用不同的加载器将不同类型的多个所述第一文件打包生成统一js文件格式的多个所述第二文件。

本公开的一种示例性实施例中，所述获取用于页面加载的多个第一文件之后，所述方法还包括：

分析多个所述第一文件的依赖关系，将具有第一预设依赖关系的第一文件合并为第三文件，将具有第二预设依赖关系的第一文件生成为独立的第四文件；

所述通过加载器将多个所述第一文件打包生成统一预设格式的多个第二文件包括：

将所述第三文件和第四文件分别打包生成所述统一预设格式的所述第二文件。

本公开的一种示例性实施例中，所述方法还包括：

分析预设源代码以得到该源代码中包含的多个所述模块的依赖关系，进而确定对应的多个所述第一文件的依赖关系。

本公开的一种示例性实施例中，所述方法还包括：

根据预设环境参数过滤掉所述源代码中的无效代码。

本公开的一种示例性实施例中，所述方法还包括：

根据所述模块的依赖关系，生成依赖指定模块版本和/或依赖更新模块版本的文件夹。

本公开的一种示例性实施例中，所述方法还包括：

根据所述第二文件的内容进行md5编码生成所述第二文件的文件名。

本公开的一种示例性实施例中，当从客户端缓存中未加载到所述页面内容所需的第二文件时，所述方法还包括：

向服务器发送一文件请求，接收所述服务器响应所述文件请求而返回的第二文件；

将返回的所述第二文件更新至所述客户端本地缓存。

根据本公开实施例的第二方面，提供一种页面文件处理装置，该装置包括：

文件获取模块，用于获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；

文件打包模块，通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；以及

文件加载模块，用于响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。

根据本公开实施例的第三方面，提供一种页面文件处理***，该***包括：

客户端，用于获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；响应所述页面上的一加载请求，从该客户端缓存中加载所述页面内容所需的第二文件；

服务器，用于当从该客户端缓存中未加载到所述页面内容所需的第二文件时，接收该客户端发送的一文件请求，响应所述文件请求而返回第二文件，以使该客户端将返回的该第二文件更新至本地缓存。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开的一种实施例中，通过上述页面文件处理方法及装置，首先获取用于页面加载的多个仅对应一个模块的第一文件，将多个所述第一文件分别打包生成统一预设格式的多个第二文件，之后响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。这样，一方面，由于每个所述第一文件仅对应一个模块，也就是说，缓存文件的单位是模块，所以不同页面之间可以达到模块级缓存复用，这样不同页面之间共用缓存就越多，从而可以达到提高页面加载性能的目的，另一方面，由于页面加载性能的提高，进而可以提升网页运行时的性能。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中页面文件处理方法流程图；

图2示意性示出本公开示例性实施例中文件合并示意图；

图3示意性示出本公开示例性实施例中打包后的文件格式示意图；

图4示意性示出本公开示例性实施例中另一页面文件处理方法流程图；

图5示意性示出本公开示例性实施例中页面文件处理流程示意图；

图6示意性示出本公开示例性实施例中页面文件处理装置示意图；

图7示意性示出本公开示例性实施例中页面文件处理***示意图；

图8示意性示出本公开示例性实施例中一种服务器示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本示例实施方式中首先提供了一种页面文件处理方法。参考图1中所示，该方法可以包括以下步骤：

步骤S101：获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能。

步骤S102：通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件。

步骤S103：响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。

通过上述页面文件处理方法，一方面，由于每个所述第一文件仅对应一个模块，也就是说，缓存文件的单位是模块，所以不同页面之间可以达到模块级缓存复用，这样不同页面之间共用缓存就越多，从而可以达到提高页面加载性能的目的，另一方面，由于页面加载性能的提高，进而可以提升网页运行时的性能。

下面，将参考图1至图5对本示例实施方式中的上述方法的各个步骤进行更详细的说明。

在步骤S101中，获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能。示例性的，可以通过打包器获取第一文件。所述页面可以是Web网页页面，所述第一文件可以是Javascript、层叠样式表CSS(Cascading StyleSheets)以及各种静态文件(图片、字体等)。所述模块即通过如Javascript编写的源代码中的一个功能模块。

需要说明的是，所述打包器是一个模块打包工具，可以管理模块依赖关系，并编绎输出模块们所需的静态文件。打包器能够很好地管理、打包Web开发中所用到的超文本标记语言HTML(Hyper Text Markup Language)、Javascript、CSS以及各种静态文件，让开发过程更加高效。

在一种示例性实施例中，所述方法还可以包括如下步骤：分析预设源代码以得到该源代码中包含的多个所述模块的依赖关系，进而确定对应的多个所述第一文件的依赖关系。

例如，可以采用打包器从配置的入口开始，分析源代码得到模块依赖关系，进而获取对应的具有依赖关系的所有会被使用到的第一文件，如Javascript文件等。

本示例实施方式中，该打包器负责将编写的源代码打包转换为Web引擎可识别的代码，之后由下文提到的另一种加载器将打包后的代码以优化的方式加载进Web引擎以获取对应的如静态资源文件，该部分内容由下文详述，此处不再赘述。此处称Web引擎而不是浏览器，是因为通过配置不同的打包配置，打包器不仅可以在浏览器中使用，还可以用在其他类Web引擎如ReactNative中使用。

在步骤S102中，通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件。

示例性的，该步骤S102中所述通过加载器将多个所述第一文件打包生成统一预设格式的多个第二文件可以包括：根据所述第一文件的类型，使用不同的加载器将不同类型的多个所述第一文件打包生成统一js文件格式的多个所述第二文件。

具体来说，所述打包器可以根据第一文件类型(如Javascript、CSS)，使用不同的加载器加载第一文件并统一转换成js文件格式，这样使得Web前端开发在一定程度上变得简单，兼顾到开发的便捷性。

为了提高处理效率，在一种示例性实施例中，所述获取用于页面加载的多个第一文件之后，所述方法还可以包括如下步骤：分析多个所述第一文件的依赖关系，将具有第一预设依赖关系的第一文件合并为第三文件，将具有第二预设依赖关系的第一文件生成为独立的第四文件。示例性的，所述第一预设依赖关系和第二预设依赖关系是不同的依赖关系。

参考图2中所示，所述打包器可以分析依赖关系，将大量碎片文件合并成高内聚低耦合的少量文件。例如，一个文件仅被另一个文件依赖，则将该一个文件合并入此另一个文件，而一个文件被两个及以上的独立文件依赖，则生成独立文件。

相应的，所述通过加载器将多个所述第一文件打包生成统一预设格式的多个第二文件可以包括：将所述第三文件和第四文件分别打包生成所述统一预设格式的所述第二文件。也就是说，在将大量文件合并后，再对合并后的少量文件进行打包生成统一js文件格式的文件，以减少文件量，提高处理效率。

为了过滤掉代码中的无效分支，减小文件体积，进一步提高处理效率。在一种示例性实施例中，所述方法还可以包括如下步骤：根据预设环境参数过滤掉所述源代码中的无效代码。

示例性的，可以根据配置的环境变量，过滤掉代码中的无效分支，减小文件体积。例如，根据预设变量值，移除代码中例如if/三元运算/逻辑运算中的无效分支。

假设预设变量如下：

源代码如下：

则过滤后的代码如下：

Console.log(“123”)。

通过过滤处理方式，可以使得开发者在开发时放心地根据环境写一些特定代码，而不用担心代码体积增大。

为了打出不同级别的版本包，方便版本的自动化增量升级，在另一示例性实施例中，所述方法还可以包括：根据所述模块的依赖关系，生成依赖指定模块版本和/或依赖更新模块版本的文件夹。也即可以同时生成依赖指定模块版本的文件夹和依赖更新模块版本的文件夹，或者单独生成依赖指定模块版本的文件夹，或者单独生成依赖更新模块版本的文件夹。以上这些可以根据具体情况来设置，不作具体限定。

示例性的，可以根据模块package.json文件中描述的模块版本依赖规则，生成模块版本号。模块的版本使用语义化版本SemVer(X.Y.Z，X位为非向前兼容的升级，Y位为向前兼容的功能增加，Z位为功能未发生改变的bug修复)。进而根据不同的依赖规则，打出不同级别的版本包，方便版本的自动化增量升级。

具体的，生成依赖指定版本的文件夹指的是对于风险较高的模块(如支付相关等)，可以采用指定版本的方式，使其不会受到其他模块升级影响。如模块A依赖模块B的1.2.3版本，则打包的时候，会打出[email protected]文件夹。

生成依赖更新模块版本的文件夹，如依赖x版本范围(如1.2.x、1.x等)，举例来说，如模块A依赖模块B的1.2.x版本，则打包的时候，会打出[email protected]文件夹，以后B模块末尾版本升级都会打在[email protected]文件夹内，则模块A就自动依赖到B模块1.2.x的最新版本。

对于依赖～范围(如～0.1.2、～1.2.3)，由于可自动升级的模块，可升级位的版本总是最新的，所以～1.2.3等同于上述1.2.x的打包方式。而对于依赖^范围(如^0.1.2、^1.2.3)，由于可自动升级的模块，可升级位的版本总是最新的，所以^1.2.3等同于上述1.x的打包方式。

本公开的一种示例性实施例中，所述方法还可以包括如下步骤：根据所述第二文件的内容进行md5(消息摘要算法第五版)编码生成所述第二文件的文件名。例如，可以根据打包出的独立文件的md5值，生成独立文件名。所述文件名中可以包含上述的版本号以及其他字符等。

需要说明是，以上各个方法步骤均可以由打包器实现，打包器可自定义插件、加载器、预设参数等。示例性的，打包器的使用方式如下所示：

所述打包器通过自定义加载器和插件，可以完成更多自定义文件的支持和功能。关于该打包器，其为现有成熟技术，如WebPack工具，不再详述。默认配置下，打包器打包完的示例性文件格式如图3所示。

在步骤S103中，响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。

例如，响应用户在浏览器网页页面上的加载请求，如请求显示一个图片或者视频等，则可以从客户端缓存中加载对应的实现该显示功能所需的资源文件。

参考图4中所示，在一种示例性实施例中，当从所述客户端缓存中未加载到所述页面内容所需的第二文件时，所述方法还包括以下步骤：

步骤S104：向服务器发送一文件请求，接收所述服务器响应所述文件请求而返回的第二文件。

示例性的，当客户端缓存中没有相应的资源文件，可以向服务器请求获取相应的资源文件。优化加载性能的目标是请求数越少越好，因此上述实施方式中有对第一文件进行合并，从而也可以减少请求数量，提高加载性能。

步骤S105：将返回的所述第二文件更新至所述客户端本地缓存。也即在从服务器获取相应的资源文件将该资源文件更新至该客户端本地缓存中，以便完成相应的加载请求对应的功能。

示例性的，可以采用另一种加载器(与上述用于文件加载的加载器不同，上述加载器主要用来将不同类型的第一文件做转换，打包为统一格式的js文件)将第二文件加载进Web引擎中。

本示例性实施例中用本地存储和服务端配合方式，达到更好的加载性能。

参考图5中所示，以浏览器为例说明，示例性的，该浏览器包括请求过程的加载方式具体步骤如下：

步骤501：根据浏览器页面page使用的入口文件，向服务器端请求入口文件，获取模块依赖列表。

步骤502：根据该模块依赖列表，过滤浏览器本地已缓存模块的文件，即获取未缓存模块对应的文件。

步骤503：将未缓存模块对应的文件中具有依赖关系的文件合并，生成一个合并文件请求，向服务器端请求合并文件内容。

示例性的，可以由内容分发网络CDN(Content Delivery Network)服务器实现转发合并文件请求至服务器，以及接收合并文件内容转发至浏览器的过程。其中示例性的所述合并文件请求的统一资源定位符URL(Uniform Resource Locator)如下所示：

“http://localhost:9993/static？？[email protected]/1,babel-polyfill@6/0,core-js@2/0,core-js@2/2，...”。

步骤504：浏览器获取根据上述合并文件请求返回的合并文件内容后，更新本地缓存LocalStorage。

在以上4个步骤中，步骤501和503两步会发送请求，所以单个页面的静态文件最多会发出两个请求，如果将入口文件依赖在服务器端直接输出在页面中的话，页面的静态文件将只会发出一个请求，如果第502步中判断出所有依赖文件本地都有缓存的话，页面将不会发送任何静态文件的请求。本示例性实施例中，缓存文件的单位是模块，所以不同页面之间可以达到模块级缓存复用，这样不同页面之间共用缓存就越多，从而可以达到进一步提高页面加载性能的目的。

需要说明的是，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。另外，也易于理解的是，这些步骤可以是例如在多个模块/进程/线程中同步或异步执行。

进一步的，本示例实施方式中，还提供了一种页面文件处理装置。参考图6中所示，装置100可以包括文件获取模块101、文件打包模块102和文件加载模块103。其中：

所述文件获取模块101，用于获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能。

所述文件打包模块102，通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件。

所述文件加载模块103，用于响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。

在本公开的一种示例性实施例中，所述文件打包模块102用于：

根据所述第一文件的类型，使用不同的加载器将不同类型的多个所述第一文件打包生成统一js文件格式的多个所述第二文件。

在本公开的一种示例性实施例中，所述装置还可以包括文件生成模块。所述文件获取模块101获取用于页面加载的多个第一文件之后，该文件生成模块用于分析多个所述第一文件的依赖关系，将具有第一预设依赖关系的第一文件合并为第三文件，将具有第二预设依赖关系的第一文件生成为独立的第四文件；

相应的，所述文件打包模块102还用于将所述第三文件和第四文件分别打包生成所述统一预设格式的所述第二文件。

在本公开的一种示例性实施例中，所述装置还可以包括依赖关系确定模块，用于分析预设源代码以得到该源代码中包含的多个所述模块的依赖关系，进而确定对应的多个所述第一文件的依赖关系。

在本公开的一种示例性实施例中，所述装置100还可以包括代码过滤模块，用于根据预设环境参数过滤掉所述源代码中的无效代码。

在本公开的一种示例性实施例中，所述装置100还可以包括文件夹生成模块，用于根据所述模块的依赖关系，生成依赖指定模块版本和/或依赖更新模块版本的文件夹。

在本公开的一种示例性实施例中，所述装置100还可以包括文件名生成模块，用于根据所述第二文件的内容进行md5编码生成所述第二文件的文件名。

在本公开的一种示例性实施例中，所述装置100还可以包括数据收发模块，用于当从客户端缓存中未加载到所述页面内容所需的第二文件时，向服务器发送一文件请求，接收所述服务器响应所述文件请求而返回的第二文件；之后，该数据收发模块将将返回的所述第二文件更新至所述客户端本地缓存。

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

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现木公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

参考图7中所示，本示例实施方式中，还提供一种页面文件处理***，该***可以包括客户端200和服务器400：其中：

所述客户端200，用于获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；响应所述页面上的一加载请求，从该客户端200缓存中加载所述页面内容所需的第二文件。

所述服务器400，用于当从该客户端200缓存中未加载到所述页面内容所需的第二文件时，接收该客户端200发送的一文件请求，响应所述文件请求而返回第二文件，以使该客户端200将返回的该第二文件更新至本地缓存。

在一种示例性实施例中，所述客户端200可以是运行浏览器的电脑等，所述客户端200还可以用于根据所述第一文件的类型，使用不同的加载器将不同类型的多个所述第一文件打包生成统一js文件格式的多个所述第二文件。

在一种示例性实施例中，所述获取用于页面加载的多个第一文件之后，所述客户端200还用于：分析多个所述第一文件的依赖关系，将具有第一预设依赖关系的第一文件合并为第三文件，将具有第二预设依赖关系的第一文件生成为独立的第四文件；将所述第三文件和第四文件分别打包生成所述统一预设格式的所述第二文件。

在一种示例性实施例中，所述客户端200还可以用于分析预设源代码以得到该源代码中包含的多个所述模块的依赖关系，进而确定对应的多个所述第一文件的依赖关系。

在一种示例性实施例中，所述客户端200还可以用于根据预设环境参数过滤掉所述源代码中的无效代码。

在一种示例性实施例中，所述客户端200还可以用于根据所述模块的依赖关系，生成依赖指定模块版本和/或依赖更新模块版本的文件夹。

在一种示例性实施例中，所述客户端200还可以用于根据所述第二文件的内容进行md5编码生成所述第二文件的文件名。

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

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

服务器400还可以包括一个电源组件426被配置为执行装置400的电源管理，一个有线或无线网络接口450被配置为将装置400连接到网络，和一个输入输出(I/O)接口458。服务器400可以操作基于存储在存储器432的操作***，例如Windows ServerTM，Mac OSXTM，UnixTM,LinuxTM，FreeBSDTM或类似。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。

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

Claims (10)

1.一种页面文件处理方法，其特征在于，该方法包括：

获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；

通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；

响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。

2.根据权利要求1所述方法，其特征在于，所述通过加载器将多个所述第一文件打包生成统一预设格式的多个第二文件包括：

根据所述第一文件的类型，使用不同的加载器将不同类型的多个所述第一文件打包生成统一js文件格式的多个所述第二文件。

3.根据权利要求1所述方法，其特征在于，所述获取用于页面加载的多个第一文件之后，所述方法还包括：

分析多个所述第一文件的依赖关系，将具有第一预设依赖关系的第一文件合并为第三文件，将具有第二预设依赖关系的第一文件生成为独立的第四文件；

所述通过加载器将多个所述第一文件打包生成统一预设格式的多个第二文件包括：

将所述第三文件和第四文件分别打包生成所述统一预设格式的所述第二文件。

4.根据权利要求3所述方法，其特征在于，所述方法还包括：

分析预设源代码以得到该源代码中包含的多个所述模块的依赖关系，进而确定对应的多个所述第一文件的依赖关系。

5.根据权利要求4所述方法，其特征在于，所述方法还包括：

根据预设环境参数过滤掉所述源代码中的无效代码。

6.根据权利要求3所述方法，其特征在于，所述方法还包括：

根据所述模块的依赖关系，生成依赖指定模块版本和/或依赖更新模块版本的文件夹。

7.根据权利要求1～6任一项所述方法，其特征在于，所述方法还包括：

根据所述第二文件的内容进行md5编码生成所述第二文件的文件名。

8.根据权利要求1～6任一项所述方法，其特征在于，当从客户端缓存中未加载到所述页面内容所需的第二文件时，所述方法还包括：

向服务器发送一文件请求，接收所述服务器响应所述文件请求而返回的第二文件；

将返回的所述第二文件更新至所述客户端本地缓存。

9.一种页面文件处理装置，其特征在于，该装置包括：

文件获取模块，用于获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；

文件打包模块，通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；以及

文件加载模块，用于响应所述页面上的一加载请求，从客户端缓存中加载所述页面内容所需的第二文件。

10.一种页面文件处理***，其特征在于，该***包括：

客户端，用于获取用于页面加载的多个第一文件，每个所述第一文件仅对应一个模块，不同的所述模块用于提供所述页面需要的不同功能；通过加载器将多个所述第一文件分别打包生成统一预设格式的多个第二文件；响应所述页面上的一加载请求，从该客户端缓存中加载所述页面内容所需的第二文件；

服务器，用于当从该客户端缓存中未加载到所述页面内容所需的第二文件时，接收该客户端发送的一文件请求，响应所述文件请求而返回第二文件，以使该客户端将返回的该第二文件更新至本地缓存。