CN105740298A - 文件处理方法、装置及服务端设备 - Google Patents

Abstract

本发明是关于一种文件处理方法、装置及服务端设备。其中，所述方法包括：提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；将各所述压缩项对应的所述解压数据进行合并，得到合并数据；对所述合并数据进行压缩处理，生成新的压缩数据。本发明实施例提供的技术方案可为用户节省应用下载流量，缩短下载等待时间，提升了用户的使用体验。

Description

文件处理方法、装置及服务端设备

技术领域

本发明涉及一种计算机领域，特别是涉及一种文件处理方法、装置及服务端设备。

背景技术

随着科技的发展，现有服务端设备，如智能手机，平板电脑等，的应用越来越广泛。目前，安卓(Android)平台手机的全球市场份额已经达到78.1％。Android是一种基于Linux的自由及开放源代码的操作***，主要使用于服务端设备，如智能手机和平板电脑。为了迎合用户的使用需求，安卓应用市场上出现了多种多样的应用软件供用户下载并安装使用。

APK是AndroidPackage的缩写，即Android安装包。现有技术中，通常采用zip的压缩方式，将每个要安装到安卓(Android)平台的应用安装程序包里的每一个文件分别进行zip压缩，然后打包为一个文件，生成后缀名为APK的安装包，其中包含了应用软件的二进制代码、资源、配置文件等。用户下载apk文件到安卓***中后，执行该APK即可安装应用了。

zip文件格式是一种数据压缩和归档格式。一个zip文件包含一个或多个已被压缩或未被压缩文件。zip采用分别压缩文件的方式，允许不必读取另外的数据而检索独立的文件，zip压缩最常用的是deflate算法。

现有技术的AndroidAPK的压缩方法，对包里的每一个文件分别进行zip压缩，造成压缩比率不高，安装包比较大，致使下载速度慢，进而使得下载服务提供方和最终用户的带宽费用都比较高。

发明内容

鉴于上述问题，提出了本发明以便于提供一种克服上述问题或者至少部分地解决上述问题的文件处理方法、装置及服务端设备。

依据本发明的第一个方面，提供了一种文件处理方法，包括：

提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

对所述合并数据进行压缩处理，生成新的压缩数据。

依据本发明的第二个方面，提供了一种文件处理装置，包括：

提取模块，用于提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

解压模块，用于分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

合并模块，用于将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

压缩模块，用于对所述合并数据进行压缩处理，生成新的压缩数据。

依据本发明的第三个方面，提供了一种服务端设备，包括文件处理装置；其中，所述文件处理装置，包括：

提取模块，用于提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

解压模块，用于分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

合并模块，用于将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

压缩模块，用于对所述合并数据进行压缩处理，生成新的压缩数据。

借由上述技术方案，本发明实施例提供的技术方案至少具有下列优点：

本发明实施例提供的技术方案通过将多个压缩项分别进行解压缩处理，再对解压出的所有解压数据进行合并处理，以对合并处理后得到的合并数据进行整体压缩，可有效的提高文件的压缩率。经实际测试，采用本发明实施例提供的技术方案，文件的大小比采用现有技术提供的压缩算法平均能减少20％～30％左右。由此可知，本发明实施例提供的技术方案，可为用户节省应用下载流量，缩短下载等待时间，提升了用户的使用体验。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例一提供的文件处理方法的一种实现的流程示意图；

图2示出了本发明实施例一提供的文件处理方法的另一种实现的流程示意图；

图3示出了本发明实施例二提供的一种文件处理装置的结构示意图；

图4示出了本发明实施例三提供的一种服务端设备的实现结构示意图。

具体实施方式

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

如图1所示，本发明实施例一提供的一种文件处理方法的流程示意图。本实施例提供的所述方法的执行主体可以是文件处理装置。该装置可具体为服务端设备，如云端设备。本实施例提供的所述方法可适用于新安装软件安装包的压缩或者是版本差异过大的升级安装包的压缩处理。采用本实施例提供的所述方法对新安装软件安装包或升级安装包进行压缩处理后，可有效的降低安装包的大小，进而为用户节省了下载安装包所需的流量，缩短下载等待时间。具体的，本实施例提供的所述方法包括：

步骤101、提取第一应用安装包中的压缩数据。

其中，所述的压缩数据包含有两个以上的压缩项(zipentry)。在安卓应用平台中，所述第一应用安装包就是一个APK文件，APK文件其实是zip格式，但后缀名被修改为apk。一个zip文件包含一个或多个已被压缩或未被压缩文件。zip采用分别压缩文件的方式，即压缩包中包含有多个压缩项(zipentry)。第一应用安装包中的压缩数据包含的压缩项，目前常用的有两种格式：一种是不压缩格式，一种是deflate压缩格式；这些压缩项在服务端为nz格式，nz格式的数据是需要解压缩的。deflate压缩是使用了哈夫曼编码(HuffmanCoding)的一种无损数据压缩算法。

步骤102、分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据。

具体的，可采用现有通用的解压缩算法分别对各压缩项进行解压缩处理。在实际应用中，还可能出现这样一种情况，如有些压缩项的压缩参数并不能获得(即推导不出)，或者，有些压缩项为加密的压缩项；这些压缩项可不用对其进行解压缩处理，直接保持不变即可。

步骤103、将各所述压缩项对应的所述解压数据进行合并，得到合并数据。

这里需要说明的是：通过上述步骤102解压出的所有解压数据中可能包含有多种内容格式的数据。为提高压缩率，同时保证采用本实施例提供的所述方法对数据被压缩后与第一应用安装包中的原压缩数据的一致性，本步骤103可根据数据内容格式对解压数据进行合并，即本步骤可采用如下方法实现：

首先，识别各所述压缩项对应的解压数据的内容格式。

在实际应用中，内容格式的识别可通过识别文件扩展名和识别文件头，这两种方式来实现。采用识别文件扩展名的方式识别速度快，但准确度要低于采用识别文件头的方式。例如，扩展名是.zip和.jar都是zip格式。文件头是PK开头，表示是zip格式。所有格式都可采用lzma2/lzma作为压缩算法。

然后，将所述内容格式相同的解压数据合并为一个待压缩单元。

其中，所述合并数据包含有至少一个所述待压缩单元。例如，应用安装包中包含两种内容格式的解压数据，一种是zip格式；另一种是PNG(PortableNetworkGraphic，可移植网络图形)格式。由此，通过本步骤可将所有zip格式的解压数据合并为第一待压缩单元；将所有PNG格式的解压数据

在实际应用中，安装包中包含的数据大多具有相同的内容格式，因此，本步骤直接将所有解出的解压数据合并成一整块数据也是可以的。

步骤104、对所述合并数据进行压缩处理，生成新的压缩数据。

其中，生成的新的压缩数据与第一应用压缩数据包中的压缩数据的内容保持不变，即新的压缩数据恢复后可以与第一应用压缩数据包中的压缩完全一致，也可不完全一致。

本步骤可直接采用固实压缩算法对所述合并数据进行压缩处理，得到新的压缩数据。固实压缩文件是一种压缩方式，它把压缩文件中的全部文件都当成一个连续数据流来看待。本实施例所涉及的固实压缩不支持rar和7z格式的压缩文件，是一种自定义的固实压缩格式。本实施例所提到的固实压缩可增加压缩性能，特别是添加大量的小文件的时候。固实数据就是将所有文件中相同的部分统一压缩，这样能使压缩后文件就变很小。采用本实施例提供的所述方法得到的所述新的压缩数据，与上述步骤101中的原所述压缩数据相比，可能只包含一个压缩项。

进一步的，若本实施例提供的所述方法，在上述103合并处理时，对解压数据进行了根据内容格式进行的划分和合并，则本步骤104可具体采用如下方法实现：

首先，根据所述待压缩单元所包含的解压数据的内容格式，选取对应的压缩算法。

然后，根据选取的所述压缩算法，对所述待压缩单元进行压缩处理，生成所述待压缩单元对应的压缩数据。

其中，所述新的压缩数据包括有所述合并数据中包含的所有所述待压缩单元对应的压缩数据。

本实施例提供的技术方案通过将多个压缩项分别进行解压缩处理，再对解压出的所有解压数据进行合并处理，以对合并处理后得到的合并数据进行整体压缩，可有效的提高文件的压缩率。经实际测试，采用本实施例提供的技术方案，文件的大小比采用现有技术提供的压缩算法平均能减少20％～30％左右。由此可知，本实施例提供的技术方案，可为用户节省应用下载流量，缩短下载等待时间，提升了用户的使用体验。

进一步的，上述实施例提供的所述方法，还可包括如下步骤：

步骤105、提取所述第一应用安装包中的元数据信息。

其中，所述元数据信息包括：所述第一应用安装包的目录信息(cde)和文件头信息。元数据(meta)信息中保存有用于恢复压缩文件的相关信息。

步骤106、将所述元数据信息和所述新的压缩数据重新打包成第二应用安装包。

这里需要补充的是：上述步骤103在将得到的所有所述解压数据进行合并的时候，要把数据流的位置记录到元数据(meta)信息中。

由于所述第二应用安装包中的压缩数据采用本实施例提供的所述方法进行了处理，与采用现有压缩处理得到的第一应用安装包相比，其数据大小更小，因此，用户下载该第二应用安装包可节省一定的下载流量，且能有效的缩短下载等待时间，提升了用户的使用体验。

进一步的，本实施例提供的所述方法还可包括如下步骤：

步骤107、获取所述新的压缩数据在压缩时的压缩参数。

步骤108、将所述压缩参数保存到所述元数据信息中，以根据所述元数据信息中的所述压缩参数对所述新的压缩数据进行解压缩。

采用现有解压缩算法，压缩数据可能绝大部分能被完整的解出(即内容完全一样)，但还是有有些部分不太可能恢复的与原包一模一样。虽然，从运行结构来看，并不存在任何影响，但还是有出错的可能。为了保证压缩数据解出的解压数据与原包(即第一应用安装包)完全一样，且保证不出错，本发明实施例即采用上述过程将所述新的压缩数据在压缩时的压缩参数记录下来并保存到元数据信息中。

元数据信息为第二应用安装包恢复至与原包(第一应用安装包)中包含的数据内容保持不变提供了数据支持。即，第二应用安装包可根据元数据信息恢复至成原包(第一应用安装包)。

进一步的，本实施例提供的所述方法是为了保证所述第一应用安装包采用上述方法进行处理后，得到的压缩数据与原有压缩数据保证一致性，即数据无损，且解压安装后能具有与原包相同的实现功能。若采用本发明提供的方法对第一应用安装包减少了包的大小，但若不能保持与原包一致，这样是没有意义的。因此，上述实施例提供的所述方法，还可以包括如下步骤，便于后续对生成的第二应用安装包进行验证：

步骤109、确定所述第一应用安装包的第一校验值。

其中，所述第一校验值为用于验证所述第一应用安装包与另一应用安装包的内容一致性的参数值。具体的，该第一校验值可以是：消息摘要算法第五版(Message-DigestAlgorithm5，简称MD5)值。

步骤110、将所述第一校验值添加到所述第二应用安装包中。

再进一步的，上述实施例提供的所述方法，还可以包括：

步骤111、确定所述第二应用安装包的第二校验值。

其中，所述第二校验值为用于验证所述第二应用安装包与另一应用安装包的内容一致性的参数值。具体的，当所述第一校验值为MD5值时，所述第二校验值也即为MD5值。

步骤112、对比所述第一校验值和第二校验值。

步骤113、根据所述对比结果，确定所述第二应用安装包中的数据是否有损坏。

具体的，若根据对比结果，确定出所述第二应用安装包中的数据有损坏，则可不提供给用户进行下载，以避免用户下载了该第二应用安装包后不能进行安装或安装后出错的问题出现，为用户提供原第一应用安装包的下载服务。当然，也可采用本实施例提供的方法重新进行处理。若根据对比结果，确定出所述第二应用安装包中的数据没有损坏，则可确定该第二应用安装包可供用户下载。

除了采用上述通过对比MD5值来确定第二应用安装包中的数据没有损坏外，还可通过对比第一应用安装包和第二应用安装包中的每项原始数据是否一致。若通过对比第一应用安装包和第二应用安装包中的每项原始数据都一致，则确定出第二应用安装包中的数据没有损坏；否则，确定出第二应用安装包中的数据有损坏。后者通过对比每项原始数据的方案，适合更高压缩率的情况，即不要求与原始包一摸一样，只要能实现相同功能即可。

这里需要说明的是：对于一些比较大的数据包，其中可能包含有很多的jar包和zip包。其中，jar包本质上就是一个zip包。zip包解压缩后，得到的解压数据中，可能还包含有压缩文件。因为，对于这类文件，本发明提供了如下实施例二，以对所述压缩文件进行完全的解压缩，以将压缩文件中的所有数据都解压出来。通俗来说：大包拆开后，再对里面的小包进行拆包，直至没有可拆的包为止。所有解压完成后，就可以得到一个数据拓扑结构(数据树)。作这样的处理是为了保证本实施例是一个流式的处理，不用分配很大的内存，一次I/O就能完成。

如图2所示，本发明实施例二提供的文件处理方法的流程示意图。同上述实施例一一样，本实施例二提供的所述方法的执行主体可以是文件处理装置。该装置可具体为服务端设备，也可以是设置在服务器端设备上的应用程序。具体的，本实施二提供的所述方法包括：

步骤201、提取第一应用安装包中的压缩数据。

其中，所述压缩数据包含有两个以上的压缩项。第一应用安装包中的压缩数据包含的压缩项目前常用的有两种格式。一种是不压缩格式，一种是deflate压缩格式；这些压缩项在服务端做成nz格式。

这里需要说明的是：第一应用安装包中的压缩数据包含的不压缩格式以及deflate压缩格式的这些压缩项在服务端做成nz格式，nz格式都是要解压缩的。

步骤202、分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据。

步骤203、判断所述解压数据中是否还包含有压缩文件，若有，则进入步骤204；否则，进入步骤205～206。

步骤204、对所述压缩文件进行解压缩处理，得到所述压缩文件的解压数据，并返回步骤203。

步骤205、将得到的所有所述解压数据进行合并，得到合并数据。

其中，在将得到的所有所述解压数据进行合并的时候，要把数据流的位置记录到元数据(meta)信息中。

步骤206、对所述合并数据进行压缩处理，生成新的压缩数据。

这里需要说明的是：本实施例提供的所述方法对不能推导出压缩参数或者加密的zip项是不做处理的，保留原始格式；对于能推导出压缩参数的进行压缩处理。

本实施例提供的所述方法中，执行步骤203和204的目的就是不断对解压数据进行拆包的过程，即在执行步骤205之前实现进行合并处理的数据中不再包含有具有压缩格式的压缩文件。

本实施例提供的技术方案通过将多个压缩项分别进行解压缩处理，再对解压出的所有解压数据进行合并处理，以对合并处理后得到的合并数据进行整体压缩，可有效的提高文件的压缩率。经实际测试，采用本实施例提供的技术方案，文件的大小比采用现有技术提供的压缩算法平均能减少20％～30％左右。由此可知，本实施例提供的技术方案，可为用户节省应用下载流量，缩短下载等待时间，提升了用户的使用体验。另外，本实施例提供的所述方法将第一应用安装包中包含的大包小包全部解压出，以后续的处理过程是一个流式的处理过程，不用分配很大的内存。

这里需要说明的是：上述实施例提供的所述方法中步骤205和步骤206均可采用上述实施例一提供的方法实现，此处步骤赘述。

进一步的，上述实施例二提供的所述方法，还可包括如下步骤：

步骤207、提取所述第一应用安装包中的元数据信息。

其中，所述元数据信息包括：所述第一应用安装包的目录信息和文件头信息。

步骤208、将所述元数据信息和所述新的压缩数据重新打包成第二应用安装包。

进一步的，本实施例二提供的所述方法还可包括如下步骤：

步骤209、获取所述新的压缩数据在压缩时的压缩参数。

步骤210、将所述压缩参数保存到所述元数据信息中，以根据所述元数据信息中的所述压缩参数对所述新的压缩数据进行解压缩。

进一步的，上述实施例二提供的所述方法，还可以包括：

步骤211、确定所述第一应用安装包的第一校验值。

其中，所述第一校验值为用于验证所述第一应用安装包与另一应用安装包的内容一致性的参数值。具体的，该第一校验值可以是：MD5值。

步骤212、将所述第一校验值添加到所述第二应用安装包中。

再进一步的，上述实施例二提供的所述方法，还可以包括：

步骤213、确定所述第二应用安装包的第二校验值。

其中，所述第二校验值为用于验证所述第二应用安装包与另一应用安装包的内容一致性的参数值。具体的，当所述第一校验值为MD5值时，所述第二校验值也即为MD5值。

步骤214、对比所述第一校验值和第二校验值。

步骤215、根据所述对比结果，确定所述第二应用安装包中的数据是否有损坏。

具体的，若根据对比结果，确定出所述第二应用安装包中的数据有损坏，则可不提供给用户进行下载，以避免用户下载了该第二应用安装包后不能进行安装或安装后出错的问题出现，用户还可下载原第一应用安装包。当然，也可采用本实施例提供的方法重新进行处理。若根据对比结果，确定出所述第二应用安装包中的数据没有损坏，则可确定该第二应用安装包可供用户下载。

除了采用上述通过对比MD5值来确定第二应用安装包中的数据没有损坏外，还可通过对比第一应用安装包和第二应用安装包中的每项原始数据是否一致。若通过对比第一应用安装包和第二应用安装包中的每项原始数据都一致，则确定出第二应用安装包中的数据没有损坏；否则，确定出第二应用安装包中的数据有损坏。后者通过对比每项原始数据的方案，适合更高压缩率的情况，即不要求与原始包一摸一样，只要能实现相同功能即可。

需要说明的是：对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

如图3所示，本发明实施例二提供的文件处理装置的结构示意图。本实施例提供的所述装置可实现上述实施例一提供的所述方法。本实施例提供的所述装置可具体表征为安装在服务端上的应用程序。具体的，本实施例提供的所述装置包括：提取模块1、解压模块2、合并模块3和压缩模块4。其中，所述提取模块1，用于提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项。所述解压模块2，用于分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据。所述合并模块3，用于将各所述压缩项对应的所述解压数据进行合并，得到合并数据。所述压缩模块4，用于对所述合并数据进行压缩处理，生成新的压缩数据。

本实施例提供的技术方案通过将多个压缩项分别进行解压缩处理，再对解压出的所有解压数据进行合并处理，以对合并处理后得到的合并数据进行整体压缩，可有效的提高文件的压缩率。经实际测试，采用本实施例提供的技术方案，文件的大小比采用现有技术提供的压缩算法平均能减少20％～30％左右。由此可知，本实施例提供的技术方案，可为用户节省应用下载流量，缩短下载等待时间，提升了用户的使用体验。

进一步的，上述实施例提供的所述合并模块可采用如下结构实现。具体的，所述合并模块包括：识别单元和合并单元。其中，所述识别单元，用于识别各所述压缩项对应的解压数据的内容格式。所述合并单元，用于将所述内容格式相同的解压数据合并为一个待压缩单元。其中，所述合并数据包含有至少一个所述待压缩单元。

进一步的，上述实施例提供的所述压缩模块可采用如下结构实现。具体的，所述压缩模块，包括：选取单元和压缩单元。其中，所述选取单元，用于根据所述待压缩单元所包含的解压数据的内容格式，选取对应的压缩算法。所述压缩单元，用于根据选取的所述压缩算法，对所述待压缩单元进行压缩处理，生成所述待压缩单元对应的压缩数据。其中，所述新的压缩数据包括有所述合并数据中包含的所有所述待压缩单元对应的压缩数据。

进一步的，上述实施例提供的所述装置，还可包括：判断模块。其中，所述判断模块，用于判断所述解压数据中是否还包含有压缩文件。上述实施例中所述的解压模块，还用于若所述判断模块判断出所述解压数据中还包含有压缩文件，则对所述压缩文件进行解压缩处理，得到所述压缩文件的解压数据。

进一步的，上述实施例提供的所述装置，还可包括：提取模块和打包模块。其中，所述提取模块，用于提取所述第一应用安装包中的除所述压缩数据外的数据信息。所述打包模块，用于将所述数据信息和所述新的压缩数据重新打包成第二应用安装包。

进一步的，上述实施例提供的所述装置，还可包括：获取模块和保存模块。其中，所述获取模块用于获取所述新的压缩数据在压缩时的压缩参数。所述保存模块用于将所述压缩参数保存到所述元数据信息中，以根据所述元数据信息中的所述压缩参数对所述新的压缩数据进行解压缩。

进一步的，上述实施例提供的所述装置，还可包括：第一确定模块和添加模块。其中，所述第一确定模块，用于确定所述第一应用安装包的第一校验值，其中，所述第一校验值为用于验证所述第一应用安装包与另一应用安装包的内容一致性的参数值。所述添加模块，用于将所述第一校验值添加到所述第二应用安装包中。

再进一步的，上述实施例提供的所述装置，还可以包括：对比模块。其中，上述实施例中所述的第一确定模块，还用于确定所述第二应用安装包的第二校验值，其中，所述第二校验值为用于验证所述第二应用安装包与另一应用安装包的内容一致性的参数值。所述对比模块，用于对比所述第一校验值和第二校验值。所述第二确定模块，用于根据所述对比结果，确定所述第二应用安装包中的数据是否有损坏。

本发明实施例三提供了一种服务端设备。该服务端设备包括：基于安卓平台的文件处理装置。其中，基于安卓平台的文件处理装置用于：

提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

对所述合并数据进行压缩处理，生成新的压缩数据。

这里需要说明的是：本实施例中的所述文件处理装置可以具体采用上述实施例二中所提供的装置，具体的实现结构和工作原理可参见上述实施例中的相应内容，此处不再赘述。

本实施例中所述的文件处理装置可以是安装在服务端设备上的应用程序，也可以是设置在服务端设备中并与所述服务端设备中的处理器通信连接的具有上述功能的逻辑电路或芯片。

具体的，图4示出了本实施例三提供的所述服务端设备的一种实现结构示意图。如图4所示，本实施例三所述的服务端设备50包括：处理器51和存储器53。其中，所述处理器51和所述存储器53通过通信线路54完成相互间的通信。所述处理器51用于执行应用程序531。所述存储器53用于存放所述应用程序531。其中，所述应用程序531为文件处理装置，该应用程序用于：

提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

对所述合并数据进行压缩处理，生成新的压缩数据。

本实施例提供的技术方案通过将多个压缩项分别进行解压缩处理，再对解压出的所有解压数据进行合并处理，以对合并处理后得到的合并数据进行整体压缩，可有效的提高文件的压缩率。经实际测试，采用本实施例提供的技术方案，文件的大小比采用现有技术提供的压缩算法平均能减少20％～30％左右。由此可知，本实施例提供的技术方案，可为用户节省应用下载流量，缩短下载等待时间，提升了用户的使用体验。

下面依照本发明所述的方案，提供本发明的一个应用软件更新升级和/或安装***的具体实施例。

具体实现中，移动设备可以通过启动移动数据或者无线(如无线网路通信技术WiFi)等形式连接到服务端设备，服务端设备通过监控程序监控移动设备与服务端设备的连通情况。其中，所述移动设备是一种可以在移动中使用的计算设备，如手机。

在本发明所述***实施例中，移动设备安装有与服务端设备进行交互的客户端程序(如360手机助手)，可以通过所述客户端程序读取移动设备上安装的一个或多个应用的安装包信息，所述安装包信息可以包括安装包标识、安装包版本号等，其中，所述安装包标识可以用于判断该安装包是属于哪一款应用；所述安装包版本号用于标识移动设备当前安装的应用是属于哪个版本。

具体应用中，所述移动设备的客户端程序的配置文件中设置有开关状态字段0和1(0标识开关关闭，1表示开关打开)，当所述客户端程序启动时，可以首先读取该开关状态字段的值，判断该开关是否是打开状态，若开关为打开状态，则开启对移动设备应用的自动升级功能，此时，客户端程序可以自动读取移动设备中的应用的安装包信息。所述服务端设备保存有目前市面上能在移动设备中安装的最新版本的应用，具体的，服务端设备可以不定期或周期性地到论坛或其他下载站点抓取最新版本的应用软件安装包，将所述最新版本的应用软件安装包保存在服务端设备的数据库，从而可以保持服务端设备数据库中保存的应用软件安装包是市面上最新的；同时服务端设备将保存的应用软件安装包，按照本方案的文件处理方法生成相应的新的应用软件安装包，以减小原有应用软件安装包的大小，供移动设备应用的下载和更新，进而为移动设备节省下载流量。

相应的，移动设备中有供用户选择的升级应用列表和/或应用安装列表，所述升级应用列表和/或应用安装列表可以包括需要升级或安装的应用的安装包标识(或应用标识)或应用的常用图标(对于常用应用，使用常用图标和应用标识的形式进行列表提示，对于一般的应用，用应用标识的形式进行列表提示)、安装包版本号、最新安装包版本号、应用描述等信息的一种或多种。针对每个应用有对应的选定框供用户选择是否对该应用进行更新或安装，用户可以在升级应用列表和/或应用安装列表中选定一个或多个应用进行升级或安装。下载选中的应用所对应的安装包，采用本发明提供的文件处理方法，其包的大小要小于原安装包。

针对上述应用软件更新升级和/或安装***，以“360手机助手”为例作进一步说明。

手机上安装有“360手机助手”，手机连接WiFi或开启移动数据连接，当手机助手打开时，开启应用自动升级功能，具体过程为：

1.手机助手读取手机A的所有应用的安装包信息，生成手机A的应用安装包信息的应用列表1；

2.手机助手将手机A的应用列表1的各个安装包信息提取出来，提取其中的安装包标识和安装包版本号发送至服务端设备，并接收所述服务端设备返回的升级安装包信息，所述升级安装包信息包括升级安装包版本号；

3.手机助手将所述升级安装包版本号与所述安装包版本号进行比较，若所述安装包版本号小于所述升级安装包版本号，则判定对应的应用为需要升级的应用，并在升级应用列表中显示可更新的提示；

4.所述升级应用列表显示检测到的所有需要更新的应用，所述升级应用列表包括应用软件大小、应用描述、应用的常用图标等信息。用户可以通过点击“更新”按钮、“卸载”按钮或“忽略更新”按钮选择是否更新升级或直接卸载相应应用；

5.手机助手接收用户选定的“更新”指令，从服务端下载选定应用的相应升级包到手机，同时显示一个应用下载进度条，在下载完成的瞬间提示用户是否确认安装；

6.手机助手接收用户选定的“确认”安装指令，将升级包下载到手机中，并完成安装升级。

当然，上述应用升级过程仅作为本发明的一种示例，并不能解释为对本发明的限制。本发明所述方案适用于任何zip结构的应用软件，不受***平台限制。

对于新安装的应用软件，手机助手可以在应用安装列表中显示出各应用软件。应用安装列表中包括有应用软件大小、应用描述、应用的常用图标等信息。用户可以通过点击“安装”按钮或“卸载”按钮选择是否安装或卸载相应应用。手机助手接收用户选定的“安装”指令，从服务端下载选定应用的相应安装包到手机，同时显示一个应用下载进度条，在下载完成的瞬间提示用户是否确认安装。手机助手接收用户选定的“确认”安装指令，将安装包下载到手机中，并完成安装。

目前的智能手机市场中，手机应用的竞争日趋激烈，为了能够持续得到用户青睐，手机应用开发商加紧了自家应用的更新升级频率以及新应用软件的开发速度。而手机用户更新应用或下载新应用难免会需要高额的流量，并且一定数量的应用一同下载或升级时的等待时间也较长，因此，诸如“应用宝”、“安卓市场”、“360手机助手”等应用商店纷纷推出了“省流量”更新和下载软件功能。采用本发明所述方案可以实现“省流量”更新和下载软件功能。

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

可以理解的是，上述方法及交换机中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述，构造这类***所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例提供的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了A1、一种文件处理方法，包括：

提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

对所述合并数据进行压缩处理，生成新的压缩数据。

A2、如A1所述的方法，其中，所述将各所述压缩项对应的解压数据进行合并，得到合并数据，包括：

识别各所述压缩项对应的解压数据的内容格式；

将所述内容格式相同的解压数据合并为一个待压缩单元；

其中，所述合并数据包含有至少一个所述待压缩单元。

A3、如A2所述的方法，其中，所述对所述合并数据进行压缩处理，生成新的压缩数据，包括：

根据所述待压缩单元所包含的解压数据的内容格式，选取对应的压缩算法；

根据选取的所述压缩算法，对所述待压缩单元进行压缩处理，生成所述待压缩单元对应的压缩数据；

其中，所述新的压缩数据包括有所述合并数据中包含的所有所述待压缩单元对应的压缩数据。

A4、如A1～A3中任一项所述的方法，其中，所述分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据之后，还包括：

判断所述解压数据中是否还包含有压缩文件；

若有，则对所述压缩文件进行解压缩处理，得到所述压缩文件的解压数据。

A5、如A1～A3中任一项所述的方法，还包括：

提取所述第一应用安装包中的元数据信息；

将所述元数据信息和所述新的压缩数据重新打包成第二应用安装包。

A6、如A5所述的方法，其中，

所述元数据信息包括：所述第一应用安装包的目录信息和文件头信息。

A7、如A5所述的方法，还包括：

获取所述新的压缩数据在压缩时的压缩参数；

将所述压缩参数保存到所述元数据信息中，以根据所述元数据信息中的所述压缩参数对所述新的压缩数据进行解压缩。

A8、如A1～A3中任一项所述的方法，还包括：

确定所述第一应用安装包的第一校验值，其中，所述第一校验值为用于验证所述第一应用安装包与另一应用安装包的内容一致性的参数值；

将所述第一校验值添加到所述第二应用安装包中。

A9、如A8所述的方法，还包括：

确定所述第二应用安装包的第二校验值，其中，所述第二校验值为用于验证所述第二应用安装包与另一应用安装包的内容一致性的参数值；

对比所述第一校验值和第二校验值；

根据所述对比结果，确定所述第二应用安装包中的数据是否有损坏。

A10、如A9所述的方法，其中，所述第一校验值和所述第二校验值均为消息摘要算法第五版MD5值。

本发明还公开了B11、一种文件处理装置，其特征在于，包括：

提取模块，用于提取第一应用`安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

解压模块，用于分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

合并模块，用于将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

压缩模块，用于对所述合并数据进行压缩处理，生成新的压缩数据。

B12、如B11所述的装置，所述合并模块，包括：

识别单元，用于识别各所述压缩项对应的解压数据的内容格式；

合并单元，用于将所述内容格式相同的解压数据合并为一个待压缩单元；

其中，所述合并数据包含有至少一个所述待压缩单元。

B13、如B12所述的装置，所述压缩模块，包括：

选取单元，用于根据所述待压缩单元所包含的解压数据的内容格式，选取对应的压缩算法；

压缩单元，用于根据选取的所述压缩算法，对所述待压缩单元进行压缩处理，生成所述待压缩单元对应的压缩数据；

其中，所述新的压缩数据包括有所述合并数据中包含的所有所述待压缩单元对应的压缩数据。

B14、如B11～B13中任一项所述的装置，还包括：

判断模块，用于判断所述解压数据中是否还包含有压缩文件；

所述解压模块，还用于若所述判断模块判断出所述解压数据中还包含有压缩文件，则对所述压缩文件进行解压缩处理，得到所述压缩文件的解压数据。

B15、如B11～B13中任一项所述的装置，还包括：

提取模块，用于提取所述第一应用安装包中的元数据信息；

打包模块，用于将所述元数据信息和所述新的压缩数据重新打包成第二应用安装包。

B16、如B15所述的装置，还包括：

获取模块，用于获取所述新的压缩数据在压缩时的压缩参数；

保存模块，用于将所述压缩参数保存到所述元数据信息中，以根据所述元数据信息中的所述压缩参数对所述新的压缩数据进行解压缩。

B17、如B11～B13中任一项所述的装置，还包括：

第一确定模块，用于确定所述第一应用安装包的第一校验值，其中，所述第一校验值为用于验证所述第一应用安装包与另一应用安装包的内容一致性的参数值；

添加模块，用于将所述第一校验值添加到所述第二应用安装包中。

B18、如B17所述的装置，还包括：

所述第一确定模块，还用于确定所述第二应用安装包的第二校验值，其中，所述第二校验值为用于验证所述第二应用安装包与另一应用安装包的内容一致性的参数值；

对比模块，用于对比所述第一校验值和第二校验值；

所述第二确定模块，用于根据所述对比结果，确定所述第二应用安装包中的数据是否有损坏。

本发明还公开了C19、一种服务端设备，其特征在于，包括上述的B11～B18中任一项所述的文件处理装置。

Claims (10)

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

提取第一应用安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

对所述合并数据进行压缩处理，生成新的压缩数据。

2.根据权利要求1所述的方法，其特征在于，所述将各所述压缩项对应的解压数据进行合并，得到合并数据，包括：

识别各所述压缩项对应的解压数据的内容格式；

将所述内容格式相同的解压数据合并为一个待压缩单元；

其中，所述合并数据包含有至少一个所述待压缩单元。

3.根据权利要求2所述的方法，其特征在于，所述对所述合并数据进行压缩处理，生成新的压缩数据，包括：

根据所述待压缩单元所包含的解压数据的内容格式，选取对应的压缩算法；

根据选取的所述压缩算法，对所述待压缩单元进行压缩处理，生成所述待压缩单元对应的压缩数据；

其中，所述新的压缩数据包括有所述合并数据中包含的所有所述待压缩单元对应的压缩数据。

4.根据权利要求1～3中任一项所述的方法，其特征在于，所述分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据之后，还包括：

判断所述解压数据中是否还包含有压缩文件；

若有，则对所述压缩文件进行解压缩处理，得到所述压缩文件的解压数据。

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

提取所述第一应用安装包中的元数据信息；

将所述元数据信息和所述新的压缩数据重新打包成第二应用安装包。

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

提取模块，用于提取第一应用`安装包中的压缩数据，其中，所述压缩数据包含有两个以上的压缩项；

解压模块，用于分别对两个以上的所述压缩项进行解压缩处理，得到各所述压缩项对应的解压数据；

合并模块，用于将各所述压缩项对应的所述解压数据进行合并，得到合并数据；

压缩模块，用于对所述合并数据进行压缩处理，生成新的压缩数据。

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

识别单元，用于识别各所述压缩项对应的解压数据的内容格式；

合并单元，用于将所述内容格式相同的解压数据合并为一个待压缩单元；

其中，所述合并数据包含有至少一个所述待压缩单元。

8.根据权利要求7所述的装置，其特征在于，所述压缩模块，包括：

选取单元，用于根据所述待压缩单元所包含的解压数据的内容格式，选取对应的压缩算法；

压缩单元，用于根据选取的所述压缩算法，对所述待压缩单元进行压缩处理，生成所述待压缩单元对应的压缩数据；

其中，所述新的压缩数据包括有所述合并数据中包含的所有所述待压缩单元对应的压缩数据。

9.根据权利要求6～8中任一项所述的装置，其特征在于，还包括：

判断模块，用于判断所述解压数据中是否还包含有压缩文件；

所述解压模块，还用于若所述判断模块判断出所述解压数据中还包含有压缩文件，则对所述压缩文件进行解压缩处理，得到所述压缩文件的解压数据。

10.一种服务端设备，其特征在于，包括上述权利要求6～9中任一项所述的文件处理装置。