应用程序安装包文件编译构建方法、装置及电子设备

摘要

本申请实施例公开了应用程序安装包文件编译构建方法、装置及电子设备，所述方法包括：从与安装目标应用程序相关的文件中确定目标文件；利用第一压缩算法对所述目标文件进行压缩，得到压缩后的目标文件；设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述目标应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件；所述自定义加载类用于在所述目标应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。通过本申请实施例，能够优化安装包的体积。

说明书

技术领域

本申请涉及应用程序安装包编译构建技术领域，特别是涉及应用程序安装包文件编译构建方法、装置及电子设备。

背景技术

随着应用程序中功能的增加，会导致应用程序安装文件的体积增大。而如果一个应用的安装文件体积比较大，则至少可能带来以下几点影响：第一，下载转化率低，通常而言，用户比较倾向于选择体积比较小的安装包进行下载，因此，安装包的体积越小，对应的下载率越高。另外，应用程序在进行大版本更新时通常会丢失用户，安装包越大，则丢失比例越大。第二，在需要对应用程序进行推广等场景中，具体的推广平台一般按照流量进行计费，因此，安装包体积越大，则推广成本越高。

因此，如何优化安装包体积是一个很重要的问题。现有技术中优化安装包体积的方式通常是对资源文件或者第三方开源库的代码进行优化。例如，对于资源文件的优化主要包括在图片文件的格式的选择(对于没有透明度需求的图片，则选择jpg和jpeg，相对png的文件体积更小)、图片的压缩、重复图片的删除等。第三方开源库方法的优化主要包括裁剪掉第三方开源库的一些代码等。

但是，在以上各种优化方式的基础上，如何进一步优化安装包的体积，现有技术中并没有给出相应的解决方案。

发明内容

本申请提供了应用程序安装包文件编译构建方法、装置及电子设备，能够优化安装包的体积。

本申请提供了如下方案：

一种应用程序安装包文件编译构建方法，包括：

从与安装目标应用程序相关的文件中确定目标文件；

利用第一压缩算法对所述目标文件进行压缩，得到压缩后的目标文件；

设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；

利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述目标应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件；

其中，所述自定义加载类用于在所述目标应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。

一种应用程序安装包文件处理方法，包括：

在通过编译构建工具对应用程序进行安装包文件的编译及构建的过程中，从与安装目标应用程序相关的文件中确定目标文件；

利用第一压缩算法，对所述目标文件进行压缩，得到压缩后的目标文件；

设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；

将所述压缩后的目标文件以及所述代码文件提供给所述编译构建工具，所述编译构建工具用于利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件；

其中，所述自定义加载类用于在所述应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。

一种文件加载方法，包括：

在应用程序运行过程中，对加载目标文件的请求进行拦截，所述目标文件在所述应用程序安装完成后处于压缩状态；

对处于压缩状态的所述目标文件进行解压处理；

将所述加载目标文件的请求放行，以进行对解压后的目标文件的加载。

一种应用程序安装包文件编译构建装置，包括：

目标文件确定单元，用于从与安装目标应用程序相关的文件中确定目标文件；

第一压缩单元，用于利用第一压缩算法对所述目标文件进行压缩，得到压缩后的目标文件；

代码文件设置单元，用于设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；

第二压缩单元，用于利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述目标应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件；

其中，所述自定义加载类用于在所述目标应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。

一种应用程序安装包文件处理装置，包括：

目标文件确定单元，用于在通过编译构建工具对应用程序进行安装包文件的编译及构建的过程中，从与安装目标应用程序相关的文件中确定目标文件；

压缩单元，用于利用第一压缩算法，对所述目标文件进行压缩，得到压缩后的目标文件；

代码设置单元，用于设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；

文件提供单元，用于将所述压缩后的目标文件以及所述代码文件提供给所述编译构建工具，所述编译构建工具用于利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件；

其中，所述自定义加载类用于在所述应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。

一种文件加载装置，包括：

请求拦截单元，用于在应用程序运行过程中，对加载目标文件的请求进行拦截，所述目标文件在所述应用程序安装完成后处于压缩状态；

解压处理单元，用于对处于压缩状态的所述目标文件进行解压处理；

请求放行单元，用于将所述加载目标文件的请求放行，以进行对解压后的目标文件的加载。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，在对应用程序进行安装包文件的编译及构建的过程中，可以确定出与安装所述应用程序相关的文件，利用第一压缩算法，对其中的目标文件进行压缩，得到压缩后的目标文件，并将其中的代码文件中对所述目标文件进行加载的相关代码设置为自定义加载类。之后，编译构建工具用于可以利用第二压缩算法，对压缩后的目标文件、代码文件以及与安装应用程序相关的其他文件进行压缩，生成应用程序的安装包文件。在利用这种安装包文件完成对应用程序的安装之后，之前通过第一压缩算法进行了压缩的目标文件仍然处于压缩状态，因此，后续在具体应用程序被安装后的运行阶段，可以通过自定义加载类对加载目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。通过该方案，由于在对所有文件统一构建成一个压缩包之前，还对其中的部分文件进行了压缩处理，因此，可以减小安装包的体积。同时，通过自定义加载类，可以在应用程序运行阶段对加载目标文件的请求进行拦截，并将处于压缩状态的目标文件进行解压处理，以确保具体动态链接库文件的正常加载。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的第二方法的流程图；

图4是本申请实施例提供的第三方法的流程图；

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的第三装置的示意图；

图8是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

为了便于理解本申请实施例提供的技术方案，下面对一些基础知识进行简单的介绍。首先，对于应用程序的安装包是可自行解压缩文件的集合，其中包括应用程序安装的所有文件。例如，对于安卓(Android)操作系统中的应用程序而言，安装应用程序所需的文件通常包括：应用程序的源代码文件，动态链接库文件，资源文件，签名文件等。

其中，动态链接库文件是为了实现代码的重用是出现的，它们是一些独立的文件，其中包含能被可执行程序或其他动态链接库调用来完成某些工作的函数。动态链接库通常都是不能直接运行的，只有在其他模块调用动态链接库中的函数时，它才发挥作用。如果同一应用程序中有多个服务或者多个功能模块需要使用同一个动态链接库，则只需要加载一份到内存中共享，因此，动态链接库也称共享库。

资源文件主要对应应用程序运行过程中所需的图片、视频、音频等各类资源。

在传统的方案中，通常可以通过编译构建工具实现对应用程序安装包的构建。这种工具在具体进行应用程序安装包构建时，在完成编译、文件优化(例如，动态链接库文件中关于调试用的符号表等内容的裁剪等)等处理后，可以将各类文件统一进行压缩，封装在同一个压缩文件中，该压缩文件也即应用程序的安装包文件。之后可以将安装包文件进行发布，用户可以从具体的应用市场等平台中进行下载安装，在安装的过程中，安装包可以自动进行解压，解压后的文件可以保存在终端设备本地。之后，在用户的启动操作下，可以使得应用程序进入运行状态。在运行的过程中，如果应用程序中的某个服务或者功能模块需要使用某个动态链接库文件等，则可以首先对该动态链接库文件加载到内存中。

而在本申请实施例中，为了进一步优化应用程序安装包的体积，提供了相应的解决方案。在该方案中，可以在通过编译构建工具对应用程序进行安装包文件的编译及构建的过程中，可以首先利用第一压缩算法，对其中的部分文件(例如，其中的动态链接库文件、资源文件等)进行压缩，得到压缩后的目标文件，之后，再利用第二压缩算法，对所述压缩后的目标文件与安装应用程序相关的其他文件(未通过第一压缩算法进行压缩的文件)进行压缩，生成应用程序的安装包文件。也就是说，在对全部文件进行压缩封装成一个安装包文件之前，首先可以对其中的部分文件用另一种压缩算法进行压缩，这样，可以使得最终生成的安装包文件的体积有所减小。

另外，具体实现时，由于对部分目标文件进行了两次压缩，因此，在应用程序被安装到目标终端设备的过程中，按照第二压缩算法对安装包文件进行解压，得到的解压结果中包括的上述目标文件仍然处于压缩状态。此时，在应用程序运行阶段是无法直接对上述目标文件进行加载的。

为此，本申请实施例还提供了自定义加载类，具体在构建安装包的过程中，除了利用第一压缩算法对目标文件进行压缩，还可以对应用程序的代码文件进行遍历，将其中对所述目标文件进行加载的相关代码修改为自定义加载类。这样，在应用程序的运行阶段，就可以通过该自定义加载类对加载目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。之后便可以对加载请求进行放行，从而完成对目标文件的加载。

其中，具体的目标文件可以包括动态链接库文件，或者，还可以包括资源文件等。其中，对于动态链接库文件，由于代码文件中通常是通过调用某个目标系统接口的方式对动态链接库文件进行加载，因此，具体可以对通过目标系统接口的方式对动态链接库文件进行加载的相关代码修改为自定义加载类。其中，关于目标系统接口，就是具体需要对动态链接库文件进行加载时，所需调用的系统接口，例如，具体可以是“System.loadLibrary”等。这里需要说明的是，本申请实施例中，之所以可以对动态链接库文件进行两次压缩处理，其中一个原因在于，动态链接库文件的加载方式通常比较单一，也即通常都是通过调用同一系统接口的方式来进行加载。这样，可以方便具体的自定义加载类对加载动态链接库文件的请求进行拦截。当然，对于资源文件等，由于加载方式比较复杂且多样，因此，可以将各种可能的加载方式进行列举，从而对具体代码文件中加载资源文件的相关代码也修改为自定义加载类。另外，安装包可能还包括除了动态资源库文件以及资源文件之外的其他文件，包括代码文件，签名文件等，这些文件不适合进行两次压缩，因此，可以在完成对上述目标文件的第一次压缩之后，再与这些其他文件一起按照第二压缩算法进行压缩处理即可。

从系统架构角度而言，本申请实施例提供的功能可以通过编译构建工具的插件程序形式实现，或者，还可以直接对编译构建工具的现有功能进行改进，增加本申请实施例提供的相关功能，等等。如图1所示，以插件形式为例，可以在现有的编译构建工具中安装本申请实施例提供的插件程序。这样，在通过该编译构建工具对应用程序进行安装包的编译以及构建的过程中，在编译构建工具具体对各个文件进行统一的打包压缩之前，该插件程序可以首先利用第一压缩算法，对其中包含的目标文件进行压缩，并对应用程序的代码文件中与目标文件加载请求相关的代码替换成自定义加载类。之后再由编译构建工具进行统一的打包压缩处理，以生成安装包文件。后续在应用程序安装到具体终端设备中并运行的过程中，可以通过具体的自定义加载类对加载目标文件的请求进行拦截，并对对应的目标文件进行解压处理，之后再对加载请求进行放行，以实现对该目标文件的加载。

下面对本申请实施例提供的具体实现方案进行详细介绍。

实施例一

首先，该实施例一从在编译构建工具中实现相关功能的角度，提供了一种应用程序安装包文件编译构建方法，参见图2，该方法具体可以包括：

S201：从与安装目标应用程序相关的文件中确定目标文件。

具体与安装应用程序相关的文件可以包括动态链接库文件，代码文件，资源文件，签名文件，等等。其中，动态链接库文件、资源文件通常都可以有多个。具体在，本申请实施例中可以根据具体文件的类型等确定目标文件，例如，可以将其中的多个动态链接库文件和/或资源文件确定为目标文件，等等。这里需要说明的是，上述动态链接库文件、资源文件等的选择，主要是以安卓系统中的应用程序为例进行的介绍，在其他操作系统中，可能会有其他类型的文件，按照本申请实施例中的方式进行类似处理即可。

S202：利用第一压缩算法对所述目标文件进行压缩，得到压缩后的目标文件。

在确定出具体的目标文件之后，可以利用第一压缩算法，对所述目标文件进行压缩，得到压缩后的目标文件。具体实现时，可以分别对每个目标文件进行压缩，得到多个压缩后的目标文件。具体的，目标文件可以包括动态链接库文件、资源文件等，因此，具体可以通过第一压缩算法对动态链接库文件、资源文件等进行压缩。其中，第一压缩算法可以有多种，在其中一种优选的实现方式下，可以是使用lzma2(Lempel-Ziv-Markov chain-Algorithm)算法对目标文件进行压缩，并使用7z格式进行封装。

这里需要说明的是，在具体实现时，具体对目标文件进行压缩的时机可以有多种，而在一种优选的实施方式下，可以是在编译构建工具完成对目标文件自身的优化处理(例如，对于动态链接库文件，优化处理可以是通过stripDebugSymbol裁剪掉调试用的符号表等)之后，最终通过第二压缩算法把所有的文件封装成一个文件包中(packageRelease)之前，利用具体的第一压缩算法对目标文件进行压缩处理。

另外，通过本申请实施例的方式对目标文件进行压缩之后，每个压缩后文件的文件名通常会发生变化，例如，文件的扩展名可能会变为.7z，而原始的动态链接库文件通常可以以.so为扩展名。而具体应用程序的代码中通常是通过动态链接库文件的原始文件名对动态链接库文件进行加载，因此，为了避免影响应用程序相关代码的执行，在对所述目标文件进行压缩后，还可以将压缩后的目标文件的文件名修改为与压缩前的文件名相同。这里的文件名可以包括文件的主名以及扩展名。当然，在其他实现方式下，还可以对应用程序的相关代码进行修改，例如，原始的代码中，与目标文件加载相关的代码中，是以目标文件的原始文件名作为加载对象进行描述，而在本申请实施例中，可以将代码中的加载对象修改为压缩后的目标文件的文件名，等等。

S203：所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类。所述自定义加载类用于在所述目标应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。

由于本申请实施例中，对目标文件进行了压缩，使得应用程序的安装包在安装过程中被解压后，这种目标文件仍然处于压缩状态。而在压缩状态下，具体的目标文件是无法直接被应用程序加载的，因此，本申请实施例还可以将应用程序的代码文件中对所述目标文件进行加载的相关代码进行设置，具体设置为自定义加载类。例如，对于动态链接库文件，可以将代码文件中通过调用目标系统接口(例如，System.loadLibrary)对动态链接库文件进行加载的相关代码修改为自定义加载类。

该修改代码的操作是在生成安装包的过程中进行，但是，具体的自定义加载类是在应用程序被安装到具体的终端设备并运行的过程中发挥作用。具体的，应用程序在运行过程中，如果其中的某服务或者应用模块需要使用某目标文件的功能，则可以通过调用具体系统接口等方式发起对该目标文件的加载请求。而本申请实施例中，由于已经将与加载该目标文件的请求相关的代码替换成了本申请实施例中的自定义加载类，因此，该自定义加载类就可以对加载目标文件的请求进行拦截。拦截之后，可以确定出具体需要加载的目标文件，如果该文件处于未解压状态，则可以对其进行解压处理；如果已解压，说明该文件之前可能已经被加载过，并在历史加载过程中完成解压，因此，不必再次执行解压操作。之后，可以将之前所拦截的加载目标文件的请求进行放行，以完成对目标文件的加载。

这里需要说明的是，在本申请实施例中，由于在具体的应用程序被安装到终端设备中之后，具体的目标文件处于压缩状态，只有目标文件被加载时，才会被解压。因此，在实际应用中可能出现以下情况：某应用程序提供的服务或者功能模块可能非常多，但是作为具体的用户而言，可能只会使用其中的部分服务(为便于描述，这部分服务用“A”来代替)，其他的服务(为便于描述，这部分服务用“B”来代替)可能永远不会用到。此时，如果某些目标文件仅会被服务B使用，则这部分目标文件则无需被解压，始终以压缩的状态存在于终端设备的存储介质中，这样其实也可以从一定程度上节省终端设备的存储资源。

S204：利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件。

在完成对目标文件的压缩以及对代码文件的设置之后，可以利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件。其中，编译构建工具可以按照传统的实现方式，将与安装所述应用程序相关的所有文件统一进行压缩，并封装成一个压缩文件，得到具体的安装包。该安装包便可以向应用市场等平台进行发布，以供用户进行下载安装。在安装的过程中，可以将安装包自动进行解压。但此时，具体的目标文件仍然为压缩状态。完成安装后，在运行应用程序的过程中，可以在具体的目标文件被加载时，由自定义加载类进行拦截，并对处于压缩状态的目标文件进行解压处理。

具体实现时，第一压缩算法与第二压缩算法可以是不同的，例如，第一压缩算法可以是lzma或者lzma2等，第二压缩算法可以是deflate。当然，在其他实施方式下，具体的第一压缩算法也可以与第二压缩算法相同，例如，都使用deflate算法进行压缩，等等。

需要说明的是，由于不同的目标文件之间可能存在依赖关系，例如，对于动态链接库文件而言，某动态链接库A可能依赖于动态链接库B，此时，如果某服务需要加载该动态链接库A，则需要对动态链接库B一起进行加载，否则动态链接库A可能会出现无法运行等情况。因此，在安装包的编译构建阶段，具体在构建安装包的过程中，除了按照第一压缩算法对目标文件进行压缩之外，还可以获取不同的目标文件之间的依赖关系信息(例如，具体可以通过objdump–x命令获取)，并保存到应用程序的代码文件所在的目录(例如，assets目录等)中。这样，具体的自定义加载类在拦截到加载目标文件的请求后，还可以根据所述依赖关系信息，确定与目标文件具有依赖关系的文件，之后，可以对处于压缩状态的目标文件以及与其具有依赖关系的文件进行解压。

另外，同样在安装包的编译构建阶段，还可以获取原始的目标文件的散列函数值(例如，Hash值等)，并保存到所述代码文件所在的目录中。这样，具体的自定义加载类在对所述压缩后的目标文件进行解压后，还可以通过获取解压后的文件的散列函数值，并通过与所述原始的目标文件的散列函数值进行一致性对比，确定解压后的文件与原始的目标文件是否一致。

需要说明的是，在具体实现是，由于同一应用程序可能存在面向不同操作系统的安装包版本，而在生成不同操作系统中的安装包时，具体的需求可能不同。例如，对于某些操作系统，可能需要按照本申请实施例中的方法，在生成最终的安装包之前，对其中的部分目标文件预先进行压缩处理，而在另一些操作系统中则不需要按照该方式进行处理。因此，具体实现时，还可以提供用于对安装包生成方式进行选择的操作选项，以用于对利用所述第二压缩算法进行压缩之前，是否采用所述第一压缩算法对所述目标文件进行压缩进行选择。

总之，通过本申请实施例，在对应用程序进行安装包文件的编译及构建的过程中，可以确定出与安装所述应用程序相关的文件，利用第一压缩算法，对其中的目标文件进行压缩，得到压缩后的目标文件，并将其中的代码文件中对所述目标文件进行加载的相关代码设置为自定义加载类。之后，编译构建工具用于可以利用第二压缩算法，对压缩后的目标文件、代码文件以及与安装应用程序相关的其他文件进行压缩，生成应用程序的安装包文件。在利用这种安装包文件完成对应用程序的安装之后，之前通过第一压缩算法进行了压缩的目标文件仍然处于压缩状态，因此，后续在具体应用程序被安装后的运行阶段，可以通过自定义加载类对加载目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。通过该方案，由于在对所有文件统一构建成一个压缩包之前，还对其中的部分文件进行了压缩处理，因此，可以减小安装包的体积。同时，通过自定义加载类，可以在应用程序运行阶段对加载目标文件的请求进行拦截，并将处于压缩状态的目标文件进行解压处理，以确保具体动态链接库文件的正常加载。

实施例二

在前述实施例一中，是通过直接在编译构建工具中增加相应的功能模块，使得编译构建工具可以具有本申请实施例中提供的对目标文件进行预压缩，对代码文件进行修改等功能。而在该实施例二中，可以通过编译构建工具的插件程序的方式来实现上述具体的功能。具体的，参见图3，该实施例二提供了一种应用程序安装包文件处理方法，该方法可以包括：

S301：在通过编译构建工具对应用程序进行安装包文件的编译及构建的过程中，从与安装目标应用程序相关的文件中确定目标文件；

S302：利用第一压缩算法，对所述目标文件进行压缩，得到压缩后的目标文件；

S303：设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；所述自定义加载类用于在所述应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理；

S304：将所述压缩后的目标文件以及所述代码文件提供给所述编译构建工具，所述编译构建工具用于利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件。

实施例三

该实施例三是从前述自定义加载类的角度，提供了一种动态链接库文件加载方法，参见图4，该方法可以包括：

S401：在应用程序运行过程中，对加载目标文件的请求进行拦截，所述目标文件在所述应用程序安装完成后处于压缩状态；

S402：对处于压缩状态的所述目标文件进行解压处理；

S403：将所述加载目标文件的请求放行，以进行对解压后的目标文件的加载。

具体实现时，所述目标文件包括动态链接库文件，此时，还可以从目标应用程序的代码文件所在目录中获取不同的动态链接库文件之间的依赖关系信息。这样，拦截到所述加载目标动态链接库文件的请求后，还可以确定与所述目标动态链接库文件具有依赖关系的动态链接库文件，并对处于压缩状态的所述目标动态链接库文件以及与其具有依赖关系的动态链接库文件进行解压。

另外，还可以从所述目标应用程序的代码文件所在目录中获取原始的目标文件的散列函数值。在对所述目标文件进行解压后，通过获取解压后的文件的散列函数值，并通过与所述原始的目标文件的散列函数值进行一致性对比，确定解压后的文件与原始的目标文件是否一致。

关于上述实施例二、三中的未详述部分内容，可以参见实施例一以及前述其他部分的记载，这里不再赘述。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

与实施例一相对应，本申请实施例还提供了一种应用程序安装包文件编译构建装置，参见图5，该装置可以包括：

目标文件确定单元501，用于从与安装目标应用程序相关的文件中确定目标文件；

第一压缩单元502，用于利用第一压缩算法对所述目标文件进行压缩，得到压缩后的目标文件；

代码文件设置单元503，用于设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；

第二压缩单元504，用于利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述目标应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件；

其中，所述自定义加载类用于在所述目标应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。

具体实现时，该装置还可以包括：

文件名修改单元，用于将所述压缩后的目标文件的文件名修改为与压缩前的文件名相同。

其中，所述目标文件包括动态链接库文件。

此时，代码文件设置单元具体可以用于：

设置所述目标应用程序的代码文件中通过调用目标系统接口对所述动态链接库文件进行加载的相关代码为自定义加载类；

所述自定义加载类用于在所述目标应用程序被安装后的运行阶段，对通过加载所述目标文件的请求进行拦截，并对处于压缩状态的动态链接库文件进行解压处理。

所述目标文件还可以包括资源文件。

另外，该装置还可以包括：

依赖关系获取单元，用于获取不同的目标文件之间的依赖关系信息，并保存到所述代码文件所在的目录中；

此时，所述自定义加载类具体用于，在拦截到加载所述目标文件的请求后，根据所述依赖关系信息，确定与所述目标文件具有依赖关系的文件，并对处于压缩状态的所述目标文件以及与其具有依赖关系的文件进行解压。

再者，该装置还可以包括：

散列函数值获取单元，用于获取原始的目标文件的散列函数值，并保存到所述代码文件所在的目录中；

此时，所述自定义加载类还用于，在对处于压缩状态的目标文件进行解压后，通过获取解压后的文件的散列函数值，并通过与所述原始的目标文件的散列函数值进行一致性对比，确定解压后的文件与原始的目标文件是否一致。

其中，所述目标文件为多个；所述第一压缩单元具体可以用于：利用第一压缩算法，分别对所述目标文件进行压缩，得到多个压缩后的目标文件。

另外，该装置还可以包括：

操作选项提供单元，用于提供用于对安装包生成方式进行选择的操作选项，以用于对利用所述第二压缩算法进行压缩之前，是否采用所述第一压缩算法对所述目标文件进行压缩进行选择。

其中，所述第一压缩算法与所述第二压缩算法不同。

与实施例二相对应，本申请实施例还提供了一种应用程序安装包文件处理装置，参见图6，该装置可以包括：

目标文件确定单元601，用于在通过编译构建工具对应用程序进行安装包文件的编译及构建的过程中，从与安装目标应用程序相关的文件中确定目标文件；

压缩单元602，用于利用第一压缩算法，对所述目标文件进行压缩，得到压缩后的目标文件；

代码设置单元603，用于设置所述目标应用程序的代码文件中对所述目标文件进行加载的相关代码为自定义加载类；

文件提供单元604，用于将所述压缩后的目标文件以及所述代码文件提供给所述编译构建工具，所述编译构建工具用于利用第二压缩算法，对所述压缩后的目标文件、所述代码文件以及与安装所述应用程序相关的其他文件进行压缩，生成所述应用程序的安装包文件；

其中，所述自定义加载类用于在所述应用程序被安装后的运行阶段，对加载所述目标文件的请求进行拦截，并对处于压缩状态的目标文件进行解压处理。

与实施例三相对应，本申请实施例还提供了一种文件加载装置，参见图7，该装置可以包括：

请求拦截单元701，用于在应用程序运行过程中，对加载目标文件的请求进行拦截，所述目标文件在所述应用程序安装完成后处于压缩状态；

解压处理单元702，用于对处于压缩状态的所述目标文件进行解压处理；

请求放行单元703，用于将所述加载目标文件的请求放行，以进行对解压后的目标文件的加载。

具体实现时，该装置还可以包括：

依赖关系信息获取单元，用于从所述目标应用程序的代码文件所在目录中获取不同的目标文件之间的依赖关系信息；

依赖文件确定单元，用于拦截到加载目标文件的请求后，确定与所述目标文件具有依赖关系的文件；

所述解压处理单元具体可以用于：

对处于压缩状态的所述目标文件以及与其具有依赖关系的文件进行解压。

再者，该装置还可以包括：

散列函数值获取单元，用于从所述目标应用程序的代码文件所在目录中获取原始的目标文件的散列函数值；

比对单元，用于在对所述处于压缩状态的目标文件进行解压后，通过获取解压后的文件的散列函数值，并通过与所述原始的目标文件的散列函数值进行一致性对比，确定解压后的文件与原始的目标文件是否一致。

另外，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。

以及一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述方法实施例中任一项所述的方法的步骤。

其中，图8示例性的展示出了电子设备的架构，具体可以包括处理器810，视频显示适配器811，磁盘驱动器812，输入/输出接口813，网络接口814，以及存储器820。上述处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814，与存储器820之间可以通过通信总线830进行通信连接。

其中，处理器810可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器820可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器820可以存储用于控制电子设备800运行的操作系统821，用于控制电子设备800的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器823，数据存储管理系统824，以及安装包文件处理系统825等等。上述安装包文件处理系统825就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器820中，并由处理器810来调用执行。

输入/输出接口813用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口814用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线830包括一通路，在设备的各个组件(例如处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814，与存储器820)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814，存储器820，总线830等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的应用程序安装包文件编译构建方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。