CN113449216A - 一种文件处理方法、装置及存储介质 - Google Patents

Abstract

本申请涉及计算技术领域，尤其涉及一种文件处理方法、装置及存储介质，以提高线上服务的稳定性。该方法中，通过将第一加载文件和第二加载文件分别上传到文件存储库中，且可以根据第一加载文件的加载信息获取第二加载文件；在响应加载指令进行页面加载时，获取第一加载文件和第二加载文件进行加载。这样，若第二加载文件需要频繁变动，则可以直接更新第二加载文件，无需对第一加载文件进行重新打包，这样，只需要将第二加载文件单独上传到云服务器中更新，减少了第一加载文件打包的次数，以及减少了第一加载文件上传到云服务器中的次数，从而提高了云服务器在线上服务的稳定性。

Description

一种文件处理方法、装置及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种文件处理方法、装置及存储介质。

背景技术

互联网用户通过浏览器访问服务时会加载相应的文件，而该文件通常是由多个文件打包得到的。而加载的文件中若存在动态文件，即，内容经常发生变化的文件，则需要对更新后的动态文件和其他文件重新打包，用户再次访问服务时会加载重新打包后的文件。因此，目前的文件处理方式由于动态文件，若动态文件发生变化，则需要重新对各文件进行打包，从而导致占用资源较多，且会影响云服务器在线上服务的稳定性。

发明内容

本申请实施例提供一种文件处理方法、装置及存储介质，用以减少加载文件打包的次数，以及减少打包的加载文件上传到线上服务的次数，从而提高线上服务的稳定性。

第一方面，本申请实施例提供的一种文件处理方法，包括：

获取各待打包文件；其中，所述待打包文件包括用于获取第二加载文件的中间文件；

将各待打包文件进行打包，得到第一加载文件；

将所述第一加载文件和所述第二加载文件分别上传到文件存储库中；

响应加载页面的加载指令，从文件存储库中获取加载页面的第一加载文件；

根据所述第一加载文件中的加载信息，获取所述加载页面的第二加载文件；

加载所述第一加载文件和所述第二加载文件。

第二方面，本申请实施例提供的一种文件处理装置，包括：

第一获取模块，用于获取各待打包文件；其中，所述待打包文件包括用于获取第二加载文件的中间文件；

打包模块，用于将各待打包文件进行打包，得到第一加载文件；

第一上传模块，用于将所述第一加载文件和所述第二加载文件上传到文件存储库中；

第二获取模块，用于响应加载页面的加载指令，从文件存储库中获取加载页面的第一加载文件；

第三获取模块，用于根据所述第一加载文件中的加载信息，获取加载页面的第二加载文件；

第一加载模块，用于加载所述第一加载文件和所述第二加载文件。

可选的，所述加载单元包括：

第一加载子单元，用于若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳不相同，则根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件；

所述装置还包括：

第二加载模块，用于若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳相同，则从缓存中获取所述第二加载文件。

可选的，所述第一加载文件和所述第二加载文件为爪哇脚本JavaScrip文件。

第三方面，提供一种计算装置，包括至少一个处理单元、以及至少一个存储单元，其中，存储单元存储有计算机程序，当程序被处理单元执行时，使得处理单元执行上述任意一种文件处理方法的步骤。

在一个实施例中，计算装置可以使服务器，也可以是终端设备。

第四方面，提供一种计算机可读介质，其存储有可由终端设备执行的计算机程序，当程序在终端设备上运行时，使得终端设备执行上述任意一种文件处理方法的步骤。

本申请有益效果如下：

本申请实施例提供的文件处理方法、装置、电子设备和存储介质，通过将第一加载文件和第二加载文件分别上传到文件存储库中，且可以根据第一加载文件的加载信息获取第二加载文件；在响应加载指令进行页面加载时，获取第一加载文件和第二加载文件进行加载。这样，若第二加载文件需要频繁变动，则可以直接更新第二加载文件，无需对第一加载文件进行重新打包，这样，只需要将第二加载文件单独上传到云服务器中更新，减少了第一加载文件打包的次数，以及减少了第一加载文件上传到云服务器中的次数，从而提高了云服务器在线上服务的稳定性。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中现有技术中文件处理方法的流程示意图；

图2为本申请实施例中一个可选的应用场景图；

图3为本申请实施例中一个文件处理方法的交互时序图；

图4为本申请实施例中一种文件处理方法的流程示意图；

图5为本申请实施例中一种文件打包方法的流程示意图；

图6为本申请实施例中一种文件加载方法的流程示意图；

图7为本申请实施例中一种文件加载完整方法的流程示意图；

图8为本申请实施例中一种文件处理装置的结构示意图；

图9为本申请实施方式中终端设备结构示意图。

具体实施方式

为了减少加载文件打包的次数，以及减少打包的加载文件上传到线上服务的次数，从而提高线上服务的稳定性，本申请实施例中提供一种文件处理方法、装置及存储介质。为了更好的理解本申请实施例提供的技术方案，这里对该方案的基本原理做一下简单说明：

为了便于本领域技术人员更好地理解本申请实施例中的技术方案，下面对本申请实施例涉及到的专业术语进行示例说明。

Js(JavaScrip，爪哇脚本)文件：后缀名称为js的文本文件。JavaScript是一种直译式脚本语言，是一种动态类型、弱类型、基于原型的语言，内置支持类型。JavaScript已经被广泛用于Web(网络)应用开发，常用来为网页添加各式各样的动态功能，为用户提供更流畅美观的浏览效果。

打包：使用工具将多个js文件进行编译混淆压缩最终合并成一个js文件，以达到减少页面加载js文件数和文件大小的目的过程，是当下前端开发经常使用的一种技术方案。在本申请实施例中，可通过webpack(网络打包)工具对js文件进行打包。webpack是一个开源的前端打包工具，它提供了前端开发缺乏的模块化开发方式，将各种静态资源视为模块，并可通过babel-loader(编译器—文件预处理器)编译代码。其中，babel是一个用于web开发，且自由开源的JavaScript编译器、转译器。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请实施例中的实施例及实施例中的特征可以相互组合。

互联网用户通过浏览器访问服务时会加载相应的文件，浏览器加载JavaScript脚本，主要通过<script>(脚本)元素完成。网页加载流程如下：

浏览器一边下载HTML(HyperText Markup Language，超文本标记语言)网页，一边开始解析。在解析过程中，浏览器发现<script>元素，就暂停解析，把网页渲染的控制权转交给JavaScript引擎。JavaScript引擎执行完毕，控制权交还渲染引擎，恢复解析HTML网页。在本申请实施例中，<script>元素为后缀名称为js的文本文件。

而在现有技术中，JavaScript引擎加载js文件时，加载的js文件是由多个js文件打包后得到的js文件。如：有5个js文件，分别为文件1、文件2、文件3、文件4、文件5，通过工具对这5个js文件进行打包，得到文件总。在JavaScript引擎加载js文件时，加载文件总即可。若文件2的内容发生了变化，则需要对文件1、变化后的文件2、文件3、文件4、文件5重新进行打包。

如图1所示，其为现有技术中打包js文件的流程图。在图1中，将内容变动较为频繁的js文件作为change.js；将其它文件作为other.js。将change.js和other.js进行打包，得到打包后的文件bundle.js。将bundle.js发布到线上服务，这样，互联网用户通过浏览器访问服务时会加载bundle.js文件。

因此，若有文件内容变动较为频繁时(如change.js文件)，就需要频繁的去重新打包，然后将新的打包文件重新发布到线上服务，这样既带来各种频繁的重复打包劳动，频繁发布打包文件还会影响线上服务的稳定性。

基于上述问题，本申请实施例提供的文件处理方法、装置、电子设备和存储介质，通过将第一加载文件和第二加载文件分别上传到文件存储库中，且可以根据第一加载文件的加载信息获取第二加载文件；在响应加载指令进行页面加载时，获取第一加载文件和第二加载文件进行加载。这样，在加载文件时，可以对打包的第一加载文件和第二加载文件进行加载；若第二加载文件需要频繁变动，则可以直接更新第二加载文件，无需对第一加载文件进行重新打包，这样，减少了第一加载文件打包的次数，以及减少了第一加载文件上传到线上服务的次数，可以提高线上服务的稳定性。

本申请实施例中的文件处理方法可以应用于如图2所示的应用场景，在该应用场景中包括用户A、电子设备201、服务器202和电子设备203。电子设备203获取各打包文件，例如获取文件1、文件2、文件3、文件4、文件5，其中，上述5个文件均为内容不变动的文件，且可以根据文件2可获取第二加载文件；将各待打包文件进行打包，得到第一加载文件。电子设备203将第一加载文件和第二加载文件上传到服务器202的文件存储库中。用户A通过电子设备201的浏览器浏览网页时，电子设备201会从服务器202中获取并加载第一加载文件和第二加载文件。

需要说明的是，为了体现打包过程和加载过程的区别，本申请实施例是以两个电子设备进行说明。当然，打包过程和加载过程也可以在一个电子设备上实现。

在本申请实施中，电子设备201和电子设备203可以是个人计算机、手机、平板电脑、笔记本等具有一定计算能力并且运行有即时通讯类软件及网站或者社交类软件及网站的计算机设备。服务器202可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识(ID，ID entity)等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。

存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(RAID，Redundant Array of Independent Disk)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。在本申请实施例中，服务器中的存储系统即为文件存储库，用以存储加载页面所必需的文件。

值得说明的是，本申请实施例中的架构图是为了更加清楚地说明本申请实施例中的技术方案，并不构成对本申请实施例提供的技术方案的限制，对于其它的应用场景架构和业务应用，本申请实施例提供的技术方案对于类似的问题，同样适用。

基于图2所示的应用场景图，下面对本申请实施例提供的一种文件处理方法进行介绍。本申请实施例侧重于说明电子设备201、电子设备203和服务器202之间的交互过程。下面结合图3，对文件打包和加载的过程进行说明。

S301，电子设备201获取各待打包文件；其中，待打包文件包括用于获取第二加载文件的中间文件。

其中，第二加载文件可以是内容变动较为频繁的动态文件，也可以是内容不变动的文件。

在本申请实施例中，各待打包文件为执行加载页面时所必需的文件，为JavaScrip类型的文件，即后缀名为.js的文件。

在本申请实施例中，中间文件包含了第二加载文件的加载信息；根据中间文件的加载信息，即可获取第二加载文件。其中，加载信息可以是第二加载文件的文件名和时间戳。

S302，电子设备201将各待打包文件进行打包，得到第一加载文件。

其中，第一加载文件为一个文件。

在本申请实施例中，将各待打包文件进行打包得到第一加载文件是将各待打包文件中的内容整合到一个文件中。例如：待打包文件共有3个，分别为文件1、文件2和文件3。其中，文件1包含内容1，文件2包含内容2，文件3包含内容3，则打包后得到的文件包含内容1、内容2和内容3。

若文件2为获取第二加载文件的中间文件，则打包后得到的文件也包含获取第二加载文件的信息。

S303，电子设备201将第一加载文件和第二加载文件分别上传到服务器202的文件存储库中。

在本申请实施例中，若第二加载文件是内容变动较为频繁的动态文件，则会预先设置一个更新频率，并以预定的更新频率将更新后的第二加载文件上传到文件存储库中。其中，更新频率可以是以天、小时等单位的更新频率，根据具体情况进行限定。

例如：设定更新频率为12小时，则第二加载文件按照12小时的时间间隔上传。如：2020年3月3日8点上传了第二加载文件，在2020年3月3日20点上传更新后的第二加载文件。这样，以预定的更新频率上传第二加载文件，可以降低服务的请求压力。

在本申请实施例中，若第二加载文件是内容变动较为频繁的动态文件，则中间文件中关于第二加载文件的加载信息包含时间戳，并根据时间戳确定第二加载文件，以保证获取的第二加载文件的准确性。

需要说明的是，第一加载文件和第二加载文件为JavaScrip文件。

这样，通过将第一加载文件和第二加载文件分别上传，若第二加载文件需要频繁变动，则可以直接更新第二加载文件，无需对第一加载文件进行重新打包，减少了第一加载文件打包的次数，以及减少了第一加载文件上传到线上服务的次数，从而可以提高线上服务的稳定性。

在本申请实施例中，S301-S303为文件处理的打包部分，本申请实施例提供的文件打包方法与现有技术相比，引入了中间文件，并对中间文件和内容不变动的文件进行打包，而将内容变动较为频繁的文件单独上传至线上服务。这样，可以有效的避免因内容变动而导致频繁打包文件。

S304，服务器202将第一加载文件和第二加载文件进行保存。

在本申请实施例中，通过服务器的云存储技术将第一加载文件和第二加载文件存储到文件存储库中，这样，若有电子设备向服务器请求加载文件时，服务器可以将存储在文件存储库中的第一加载文件发送给该电子设备。

S305，电子设备203响应加载页面的加载指令，从服务器202的文件存储库中获取加载页面的第一加载文件。

在本申请实施例中，电子设备接收到用户发送的加载页面的请求后，向服务器202获取加载页面所需要的文件，服务器202经过计算检查后，将存储的第一加载文件发送给电子设备。

S306，电子设备203根据第一加载文件中的加载信息，获取加载页面的第二加载文件。

在本申请实施例中，所述第一加载文件是由待打包文件打包得到的，且所述待打包文件包括用于获取第二加载文件的中间文件；即，第一加载文件中包含了第二加载文件的加载信息；根据第一加载文件的加载信息，即可获取第二加载文件。

在本申请实施例中，根据所述中间文件对应在第一加载文件中的加载信息，确定第二加载文件的文件名和时间戳；根据第二加载文件的文件名和时间戳，从所述文件存储库中获取第二加载文件。

这样，通过第二加载文件名和时间戳来确定第二加载文件，可以找到唯一的第二加载文件，以保证获取的第二加载文件的准确性。

在本申请实施例中，若第二加载文件以预定的更新频率进行更新，则根据第二加载文件的文件名和时间戳，来确定从何处获取第二加载文件。

若浏览器是第一次获取第二加载文件，则根据第二加载文件的文件名和时间戳，从线上服务的文件存储库中获取第二加载文件；加载完成后，将第二加载文件存入缓存中。

若浏览器不是第一次获取第二加载文件，则根据此时第一加载文件中第二加载文件的时间戳与第二加载文件的更新频率进行比较，具体的：

若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳不相同，则根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件；

若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳相同，则从缓存中获取所述第二加载文件。

这样，根据时间戳确定从哪里获取第二加载文件，进一步保证了获取第二加载文件的准确性。

S307，电子设备203加载第一加载文件和第二加载文件。

在本申请实施例中，获取了用于加载页面的第一加载文件和第二加载文件后，对第一加载文件和第二加载文件进行加载，进而显示网页。

在本申请实施例中，S305-S306为文件处理的加载部分，本申请实施例提供的文件打包方法与现有技术相比，在加载第一加载文件(打包文件)时，若发现存在第二加载文件(动态文件)，根据第一加载文件中存储的信息获取第二加载文件。这样，通过将第一加载文件和第二加载文件分别上传，若第二加载文件需要频繁变动，则可以直接更新第二加载文件，无需对第一加载文件进行重新打包，减少加载文件打包的次数，以及减少打包的加载文件上传到线上服务的次数，，从而可以提高线上服务的稳定性。

如图4所示，其为本申请中打包js文件的流程图。在图4中，将内容变动较为频繁的js文件作为change.js；将用于加载动态文件的文件作为middle.js；将其它文件作为other.js。打包时，将middle.js和other.js进行打包，得到打包后的文件bundle.js。将bundle.js和change.js发布到线上服务，这样，互联网用户通过浏览器访问服务时会加载bundle.js文件，并根据bundle.js文件中的加载信息加载change.js文件。

基于同一发明构思，本申请实施例还提供一种文件处理方法，该方法应用于前文论述的电子设备201，请参照图5，该方法包括：

S501：获取各待打包文件；其中，待打包文件包括用于获取第二加载文件的中间文件。

S502：将各待打包文件进行打包，得到第一加载文件。

S503：将第一加载文件和第二加载文件分别上传到服务器202的文件存储库中。

其中，图5中的各个步骤的具体实现方式可以参照前文论述的内容，此处不再赘述。

基于同一发明构思，本申请实施例还提供一种文件处理方法，该方法应用于前文论述的电子设备203，请参照图6，该方法包括：

S601：响应加载页面的加载指令，从文件存储库中获取加载页面的第一加载文件。

S602：根据第一加载文件中的加载信息，获取加载页面的第二加载文件。

S603：加载第一加载文件和第二加载文件。

其中，图6中的各个步骤的具体实现方式可以参照前文论述的内容，此处不再赘述。

基于同一发明构思，本申请实施例还提供一种完整文件处理方法，请参照图7，该方法包括：

S701：获取各待打包文件；其中，待打包文件包括用于获取第二加载文件的中间文件。

S702：将各待打包文件进行打包，得到第一加载文件。

S703：将第一加载文件上传到文件存储库中。

S704：以预定的更新频率将更新后的所述第二加载文件上传到文件存储库中。

S705：响应加载页面的加载指令，从文件存储库中获取加载页面的第一加载文件。

S706：根据中间文件对应在第一加载文件中的加载信息，确定第二加载文件的文件名和时间戳。

S707：根据第二加载文件的文件名和时间戳，从文件存储库中获取第二加载文件。

S708：加载第一加载文件和第二加载文件。

其中，图7中的各个步骤的具体实现方式可以参照前文论述的内容，此处不再赘述。

基于相同的发明构思，本申请实施例还提供了一种文件处理装置。如图8所示，该装置包括：

第一获取模块801，用于获取各待打包文件；其中，所述待打包文件包括用于获取第二加载文件的中间文件；

打包模块802，用于将各待打包文件进行打包，得到第一加载文件；

第一上传模块803，用于将所述第一加载文件和所述第二加载文件上传到文件存储库中；

第二获取模块804，用于响应加载页面的加载指令，从文件存储库中获取加载页面的第一加载文件；

第三获取模块805，用于根据所述第一加载文件中的加载信息，获取加载页面的第二加载文件；

第一加载模块806，用于加载所述第一加载文件和所述第二加载文件。

可选的，所述装置还包括：

第二上传模块，用于以预定的更新频率将更新后的所述第二加载文件上传到文件存储库中。

可选的，第二获取模块802包括：

确定单元，用于根据所述中间文件对应在所述第一加载文件中的加载信息，确定所述第二加载文件的文件名和时间戳；

加载单元，用于根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件。

可选的，加载单元包括：

第一加载子单元，用于若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳不相同，则根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件；

所述装置还包括：

第二加载模块，用于若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳相同，则从缓存中获取所述第二加载文件。

可选的，所述第一加载文件和所述第二加载文件为爪哇脚本JavaScrip文件。

基于同一技术构思，本申请实施例还提供了一种终端设备900，参照图9所示，终端设备900用于实施上述各个方法实施例记载的方法，例如实施图2所示的实施例，终端设备900可以包括存储器901、处理器902、输入单元903和显示面板904。

存储器901，用于存储处理器902执行的计算机程序。存储器901可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据终端设备900的使用所创建的数据等。处理器902，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等。输入单元903，可以用于获取用户输入的用户指令。显示面板904，用于显示由用户输入的信息或提供给用户的信息，本申请实施例中，显示面板904主要用于显示终端设备中各应用程序的显示界面以及各显示界面中显示的控件实体。可选的，显示面板904可以采用液晶显示器(liquid crystaldisplay，LCD)或OLED(organic light-emitting diode，有机发光二极管)等形式来配置显示面板904。

本申请实施例中不限定上述存储器901、处理器902、输入单元903和显示面板904之间的具体连接介质。本申请实施例在图9中以存储器901、处理器902、输入单元903、显示面板904之间通过总线905连接，总线905在图9中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线905可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器901可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器901也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器901是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器901可以是上述存储器的组合。

处理器902，用于实现如图2所示的实施例，包括：

处理器902，用于调用存储器901中存储的计算机程序执行如实施图2所示的实施例。

本申请实施例还提供了一种计算机可读存储介质，存储为执行上述处理器所需执行的计算机可执行指令，其包含用于执行上述处理器所需执行的程序。

在一些可能的实施方式中，本申请提供的一种文件处理方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述描述的根据本申请各种示例性实施方式的一种文件处理方法中的步骤。例如，终端设备可以执行如实施图2所示的实施例。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的用于一种文件处理程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向实体的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

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

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

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

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

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种文件处理方法，其特征在于，所述方法包括：

获取各待打包文件；其中，所述待打包文件包括用于获取第二加载文件的中间文件；

将各待打包文件进行打包，得到第一加载文件；

将所述第一加载文件和所述第二加载文件分别上传到文件存储库中；

响应加载页面的加载指令，从文件存储库中获取加载页面的第一加载文件；

根据所述第一加载文件中的加载信息，获取所述加载页面的第二加载文件；

加载所述第一加载文件和所述第二加载文件。

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

以预定的更新频率将更新后的所述第二加载文件上传到文件存储库中。

3.根据权利要求1所述的方法，其特征在于，所述根据所述第一加载文件中的加载信息，获取加载页面的第二加载文件，包括：

根据所述中间文件对应在所述第一加载文件中的加载信息，确定所述第二加载文件的文件名和时间戳；

根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件。

4.根据权利要求3所述的方法，其特征在于，所述根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件，包括：

若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳不相同，则根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件；

所述方法还包括：

若此次获取所述第二加载文件的时间戳与上次获取所述第二加载文件的时间戳相同，则从缓存中获取所述第二加载文件。

5.根据权利要求1-4任一所述的方法，其特征在于，所述第一加载文件和所述第二加载文件为爪哇脚本JavaScrip文件。

6.一种文件处理装置，其特征在于，所述装置包括：

第一获取模块，用于获取各待打包文件；其中，所述待打包文件包括用于获取第二加载文件的中间文件；

打包模块，用于将各待打包文件进行打包，得到第一加载文件；

第一上传模块，用于将所述第一加载文件和所述第二加载文件上传到文件存储库中；

第二获取模块，用于响应加载页面的加载指令，从文件存储库中获取加载页面的第一加载文件；

第三获取模块，用于根据所述第一加载文件中的加载信息，获取加载页面的第二加载文件；

第一加载模块，用于加载所述第一加载文件和所述第二加载文件。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二上传模块，用于以预定的更新频率将更新后的所述第二加载文件上传到文件存储库中。

8.根据权利要求6所述的装置，其特征在于，第二获取模块包括：

确定单元，用于根据所述中间文件对应在所述第一加载文件中的加载信息，确定所述第二加载文件的文件名和时间戳；

加载单元，用于根据所述第二加载文件的文件名和时间戳，从所述文件存储库中获取所述第二加载文件。

9.一种电子设备，其特征在于，其包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行权利要求1至6中任一所述方法的步骤。

10.一种计算机可读存储介质，其特征在于，其包括程序代码，当所述程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行权利要求1至6中任一所述方法的步骤。

Images