一种应用程序的压缩方法和装置与流程

文档序号:14940742发布日期:2018-07-13 20:40阅读:174来源:国知局

本申请涉及应用程序压缩技术领域,具体涉及一种应用程序的压缩方法和装置。



背景技术:

apk(androidapplicationpackage,安卓应用应用程序)是android操作系统使用的一种应用应用程序文件格式,用于分发和安装移动应用及中间件。一个android应用程序的代码想要在android设备上运行,必须先进行编译,然后被打包成为一个被android系统所能识别的文件才可以被运行,而这种能被android系统识别并运行的文件格式便是“apk”。一个apk文件内包含被编译的代码文件,文件资源,证书,和清单文件。

apk体积的减少是商业化应用不断优化的目标之一,减少apk应用的体积主要是通过本身应用功能,逻辑框架的修改来达到其目的。但如果当一个apk应用在本身业务逻辑上的取舍已经达到最优,还可以通过对已经生成的apk应用重新压缩,或者修改其视频,音频,图片资源的大小来进一步的减少体积。

在生成apk应用程序的时候,默认对其应用中的so文件采用的压缩算法是deflate算法。而当apk应用安装到android手机上以后,手机在运行这个apk应用的时候,当加载apk应用程序里面的so文件的时候,需要首先对其进行解压。android系统中内置的解压算法也是通过deflate算法,完成加载。

鉴于android系统的限制,无法改变其原有默认的deflate算法,也就没有办法直接使用更高压缩率的算法来进行压缩,主要原因就是apk应用在安装到android系统以后,android系统不支持更高压缩率的其他算法来解压对应算法压缩过的apk应用中的so文件。



技术实现要素:

鉴于上述问题,提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的一种应用程序的压缩方法和装置。

依据本申请的一个方面,提供了一种应用程序的压缩方法,包括:

采用预设压缩算法对源应用程序中的被调文件进行压缩;

将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用,所述解压功能文件用于解压和加载压缩后的被调文件;

封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

可选地,在所述采用预设压缩算法对源应用程序中的被调文件进行压缩之前,所述方法还包括:

查找所述源应用程序中可采用预设压缩算法进行压缩的被调文件。

可选地,所述被调文件为动态链接库文件,所述主调文件为调用所述动态链接库文件的可执行文件;所述查找所述源应用程序中可采用预设压缩算法进行压缩的被调文件包括:

在所述源应用程序包括的多种类型的文件中查找动态链接库文件。

可选地,所述方法还包括:

在所述主调文件的初始化对象中增加解压功能文件。

可选地,所述方法还包括:

将所述解压功能文件添加至归属于应用程序的主框架的主调文件。

可选地,所述在所述主调文件的初始化对象中增加解压功能文件包括:

在所述主调文件的程序入口位置查找运行的首个函数;

在所述首个函数的调用对象中增加对应所述预设压缩算法的解压功能文件。

可选地,在所述在所述主调文件的初始化对象中增加解压功能文件之前,所述方法还包括:

从所述源应用程序的应用全局配置文件中,提取所述源应用程序的程序入口位置的入口类名称。

可选地,所述方法还包括:

反编译对应的主调文件。

可选地,所述方法还包括:

确定所述被调文件之间的依赖关系,并生成记录依赖关系的依赖文件。

可选地,所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序包括:

封装所述依赖文件、修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

可选地,所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序包括:

对修改后的主调文件进行压缩,并替换至修改前的主调文件所处位置;

对所述压缩后的被调文件和解压功能文件进行压缩,并添加至所述源应用程序中,得到压缩应用程序。

可选地,所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序还包括:

提取归属于应用程序的主框架的主调文件并进行压缩,得到压缩后的主框架文件,所述主框架的主调文件中已添加所述解压功能文件;

采用压缩后的主框架文件替换所述源应用程序原有的主框架文件。

可选地,在所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序之后,所述方法还包括:

对所述主调文件在应用程序中所属的功能组件进行重新签名。

可选地,在所述对所述主调文件在应用程序中所属的功能组件进行重新签名之前,所述方法还包括:

判定所述主调文件在应用程序中所属的功能组件具有原始签名。

可选地,在所述采用预设压缩算法对源应用程序中的被调文件进行压缩之前,所述方法还包括:

解压所述源应用程序,并查找主调文件和被调文件。

可选地,所述方法还包括:

对所述压缩应用程序进行签名。

可选地,所述预设压缩算法为lzma算法。

依据本申请的另一个方面,提供了一种应用程序的解压方法,包括:

解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件;所述主调文件定义为调用所述解压功能文件;

在所述主调文件调用所述被调文件时,调用解压功能文件对压缩的被调文件进行解压和加载。

可选地,在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,所述方法还包括:

调用主框架的主调文件初始化压缩应用程序中解压功能文件。

可选地,在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,所述方法包括:

判定压缩的被调文件中存在主调文件所需调用的被调文件。

可选地,所述方法还包括:

若不存在主调文件所需调用的被调文件,则从当前操作系统查找被调文件或从网络下载所述被调文件。

可选地,在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,所述方法包括:

判定主调文件所需调用的被调文件依赖于另一被调文件;

调用解压功能文件从压缩的被调文件解压所述另一被调文件;

调用解压功能文件从压缩的被调文件解压主调文件所需调用的被调文件。

根据本申请的另一方面,提供了一种应用程序的压缩装置,包括:

被调文件压缩模块,用于采用预设压缩算法对源应用程序中的被调文件进行压缩;

调用修改模块,用于将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用,所述解压功能文件用于解压和加载压缩后的被调文件;

应用程序封装模块,用于封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

可选地,所述装置还包括:

被调文件查找模块,用于在所述采用预设压缩算法对源应用程序中的被调文件进行压缩之前,查找所述源应用程序中可采用预设压缩算法进行压缩的被调文件。

可选地,所述被调文件为动态链接库文件,所述主调文件为调用所述动态链接库文件的可执行文件;所述被调文件查找模块,具体用于在所述源应用程序包括的多种类型的文件中查找动态链接库文件。

可选地,所述装置还包括:

功能文件增加模块,用于在所述主调文件的初始化对象中增加解压功能文件。

可选地,所述装置还包括:

功能文件添加模块,用于将所述解压功能文件添加至归属于应用程序的主框架的主调文件。

可选地,所述功能文件增加模块包括:

函数查找子模块,用于在所述主调文件的程序入口位置查找运行的首个函数;

功能文件增加子模块,用于在所述首个函数的调用对象中增加对应所述预设压缩算法的解压功能文件。

可选地,所述装置还包括:

入口类名称提取子模块,用于在所述在所述主调文件的初始化对象中增加解压功能文件之前,从所述源应用程序的应用全局配置文件中,提取所述源应用程序的程序入口位置的入口类名称。

可选地,所述装置还包括:

主调文件反编译模块,用于反编译对应的主调文件。

可选地,所述装置还包括:

依赖文件生成模块,用于确定所述被调文件之间的依赖关系,并生成记录依赖关系的依赖文件。

可选地,所述应用程序封装模块,具体用于封装所述依赖文件、修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

可选地,所述应用程序封装模块包括:

主调文件压缩子模块,用于对修改后的主调文件进行压缩,并替换至修改前的主调文件所处位置;

压缩添加子模块,用于对所述压缩后的被调文件和解压功能文件进行压缩,并添加至所述源应用程序中,得到压缩应用程序。

可选地,所述应用程序封装模块还包括:

主框架文件压缩子模块,用于提取归属于应用程序的主框架的主调文件并进行压缩,得到压缩后的主框架文件,所述主框架的主调文件中已添加所述解压功能文件;

主框架文件替换子模块,用于采用压缩后的主框架文件替换所述源应用程序原有的主框架文件。

可选地,所述装置还包括:

组件签名模块,用于在所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序之前,对所述主调文件在应用程序中所属的功能组件进行重新签名。

可选地,所述装置还包括:

原始签名判定模块,用于在所述对所述主调文件在应用程序中所属的功能组件进行重新签名之前,判定所述主调文件在应用程序中所属的功能组件具有原始签名。

可选地,所述装置还包括:

源应用程序解压模块,用于在所述采用预设压缩算法对源应用程序中的被调文件进行压缩之前,解压所述源应用程序,并查找主调文件和被调文件。

可选地,所述装置还包括:

应用程序签名模块,用于对所述压缩应用程序进行签名。

可选地,所述预设压缩算法为lzma算法。

根据本申请的另一方面,提供了一种应用程序的解压装置,包括:

应用程序解封装模块,用于解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件;所述主调文件定义为调用所述解压功能文件;

解压和加载模块,用于在所述主调文件调用所述被调文件时,调用解压功能文件对压缩的被调文件进行解压和加载。

可选地,所述装置还包括:

功能文件初始化模块,用于在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,调用主框架的主调文件初始化压缩应用程序中解压功能文件。

可选地,所述装置包括:

被调文件存在判定模块,用于在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,判定压缩的被调文件中存在主调文件所需调用的被调文件。

可选地,所述装置还包括:

查找下载模块,用于若不存在主调文件所需调用的被调文件,则从当前操作系统查找被调文件或从网络下载所述被调文件。

可选地,所述装置包括:

依赖判定模块,用于在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,判定主调文件所需调用的被调文件依赖于另一被调文件;

依赖文件解压模块,用于调用解压功能文件从压缩的被调文件解压所述另一被调文件;

文件解压模块,用于调用解压功能文件从压缩的被调文件解压主调文件所需调用的被调文件。

依据本申请实施例,首先采用预设压缩算法对源应用程序中的被调文件进行压缩,例如采用比原有压缩算法压缩率更高的算法,可以提高压缩应用程序的压缩率,得到更小体积的应用程序。进一步,将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用,封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序,从而使得该应用程序运行时可以调用能够解压预设压缩算法的算法进行解压,从而可以解决了原先对压缩率高的算法无法兼容的问题,可以让应用程序本身具备解压压缩率高的压缩算法的功能,保证采用更高压缩率的应用程序的正常运行。

上述说明仅是本申请技术方案的概述,为了能够更清楚了解本申请的技术手段,而可依照说明书的内容予以实施,并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂,以下特举本申请的具体实施方式。

附图说明

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

图1示出了根据本申请实施例一的一种应用程序的压缩方法实施例的流程图;

图2示出了根据本申请实施例二的一种应用程序的压缩方法实施例的流程图;

图3示出了根据本申请实施例三的一种应用程序的解压方法实施例的流程图;

图4示出了根据本申请实施例四的一种应用程序的解压方法实施例的流程图;

图5示出了本申请实施例的一个示例中压缩过程示意图;

图6示出了本申请实施例的另一个示例中解压过程示意图;

图7示出了根据本申请实施例五的一种应用程序的压缩装置的结构框图;

图8示出了根据本申请实施例六的一种应用程序的解压装置的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。

本申请可以应用在应用程序的压缩以及应用程序的解压中,在开发应用程序的时候都需要对应用程序进行优化,从方方面面将应用程序的大小尽量优化。例如在android操作系统下使用的apk应用程序,在生成apk应用程序的时候,可以对其应用中的so文件采用压缩算法进行压缩,然后在将压缩后的文件封装成apk应用程序,这样就可以实现对应用程序的压缩,减少了应用的体积。

本申请中,源应用程序为需要通过主调文件调用被调文件来完成某项或多项特定工作的计算机程式,例如android操作系统下的apk应用程序就是源应用程序。主调文件为从源应用程序中提取出来的可执行代码文件,执行主调文件的代码可以调用其中的函数来加载被调文件,例如apk应用程序中提取的dex文件就是主调文件。被调文件为从源应用程序中提取出来的在程序运行过程中需要通过主调文件加载的代码文件,例如apk应用程序中提取的so文件就是被调文件。

本申请中,预设压缩算法为一种数据压缩算法,具体可以为任意适用的压缩算法,为产生好的技术效果,优选为压缩率较高的压缩算法,本申请对此不做限制。

参照图1,示出了根据本申请实施例一的一种应用程序的压缩方法实施例的流程图,该方法具体可以包括以下步骤:

步骤101,采用预设压缩算法对源应用程序中的被调文件进行压缩。

源应用程序中有至少一个被调文件,采用预设压缩算法对所有或部分被调文件进行压缩,具体可以将被调文件压缩为一个或多个压缩文件,本申请对此可以不作限制。

例如,从apk应用程序中提取出所有的so文件,将所有的so文件使用lzma(lempel-ziv-markovchain-algorithm的缩写)算法压缩到一个压缩文件,也就是压缩后的被调文件。

步骤102,将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用。

解压功能文件用于解压和加载压缩后的被调文件,是指针对预设压缩算法预先编写的可以解压压缩后的被调文件,并加载被调文件的代码的文件。解压功能文件也是一种主调文件可以调用的被调文件。

由于被调文件已经被预设压缩算法压缩,主调文件中原有的对被调文件的调用就无法成功执行,所以要对主调文件原有的逻辑进行修改。将主调文件对被调文件的调用修改为对预设压缩算法对应的解压功能文件的调用。如此修改后在执行主调文件的代码时,就可以加载能够解压预设压缩算法压缩的被调文件的解压功能文件,继而可以得到原有的被调文件。

例如,在apk应用程序的主dex文件中,将原有调用所有so文件修改为调用解压并加载lzma算法压缩的so文件。

步骤103,封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

压缩应用程序为经预设压缩算法压缩以及相应修改后的应用程序。将修改后的主调文件、压缩后的被调文件和解压功能文件重新打包,封装为新的应用程序,得到压缩应用程序。

例如,将修改后的dex文件、lzma算法压缩的所有so文件、预先编译好的能够处理lzma算法的so文件重新打包进入apk应用程序,得到的apk应用程序就是压缩应用程序。

依据本申请实施例,首先采用预设压缩算法对源应用程序中的被调文件进行压缩,例如采用比原有压缩算法压缩率更高的算法,可以提高压缩应用程序的压缩率,得到更小体积的应用程序。进一步,将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用,封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序,从而使得该应用程序运行时可以调用能够解压预设压缩算法的算法进行解压,从而可以解决了原先对压缩率高的算法无法兼容的问题,可以让应用程序本身具备解压压缩率高的压缩算法的功能,保证采用更高压缩率的应用程序的正常运行。

本申请的一种优选实施例中,在所述步骤101中所述采用预设压缩算法对源应用程序中的被调文件进行压缩之前,还可以包括:步骤104,查找所述源应用程序中可采用预设压缩算法进行压缩的被调文件。

源应用程序中可以有多种文件,可采用预设压缩算法进行压缩的被调文件为适用于预设压缩算法,且不会使程序无法正常运行的被调文件,从源应用程序的各种文件中查找到可采用预设压缩算法进行压缩的被调文件。例如,可以从源应用程序中找到所有类型的文件,其中所有的so文件都是可以采用预设压缩算法进行压缩的被调文件。

本申请的一种优选实施例中,所述被调文件为动态链接库文件,所述主调文件为调用所述动态链接库文件的可执行文件;所述步骤104中所述查找所述源应用程序中可采用预设压缩算法进行压缩的被调文件,具体可以包括:在所述源应用程序包括的多种类型的文件中查找动态链接库文件。

动态链接库文件,是一种不可执行的二进制程序文件,它允许程序共享执行特殊任务所必需的代码和其他资源。可执行文件指的是可以由操作系统进行加载执行的文件。在不同的操作系统环境下,可执行文件的呈现方式不一样。动态链接库文件为一种可采用预设压缩算法进行压缩的被调文件,从源应用程序包括的多种类型的文件中查找动态链接库文件。

本申请的一种优选实施例中,所述步骤103中所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序可以包括:

子步骤s1,对修改后的主调文件进行压缩,并替换至修改前的主调文件所处位置;

子步骤s2,对所述压缩后的被调文件和解压功能文件进行压缩,并添加至所述源应用程序中,得到压缩应用程序。

对修改后的主调文件进行压缩,具体可以使用任意适用的压缩方式,本申请对此不做限制。然后将压缩后的主调文件替换到修改前的主调文件所处的文件位置,具体可以将修改前的主调文件删除,再将压缩后的主调文件放入修改前主调文件所处的文件位置。如果应用程序包含插件,将修改后的主调文件压缩替换到其原有的插件中。例如,将所有修改后dex文件压缩替换到其原有的插件中。

对所述压缩后的被调文件和解压功能文件进行压缩,压缩至所述源应用程序中,得到压缩应用程序。具体可以使用任意使用的压缩方式,本申请对此不作限制。

本申请的一种优选实施例中,所述步骤103中所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序还可以包括:

子步骤s3,提取归属于应用程序的主框架的主调文件并进行压缩,得到压缩后的主框架文件;

子步骤s4,采用压缩后的主框架文件替换所述源应用程序原有的主框架文件。

如果应用程序只有一个主调文件,那么这个主调文件就是主框架的主调文件。如果应用程序是分为多个主调文件的,其中跟启动相关的组件会被放入一个主调文件中,这个主调文件称为主框架的主调文件,相应的其他主调文件可以被成为副主调文件,启动时可以动态加载。

本申请中,主框架的主调文件中已添加所述解压功能文件。提取归属于应用程序的主框架的主调文件,进行压缩,得到压缩后的主框架文件。用压缩后的主框架文件替换源应用程序原有的主框架文件,具体就是将压缩后的主框架文件替换到应用程序包的根目录中。

本申请的一种优选实施例中,所述预设压缩算法为lzma算法。

lzma(lempel-ziv-markovchain-algorithm的缩写)是2001年以来得到发展的一个数据压缩算法,它用于7-zip归档工具中的7z格式和unix-like下的xz格式。它使用类似于lz77的字典编码机制,在一般的情况下压缩率比bzip2为高,用于压缩的字典文件大小可达4gb。

lzma算法是一种比android系统默认的deflate算法具有更高压缩率的算法,采用该种算法可以为apk应用程序带来更高的压缩率。

参照图2,示出了根据本申请实施例二的一种应用程序的压缩方法实施例的流程图,该方法具体可以包括以下步骤:

步骤201,解压所述源应用程序,并查找主调文件和被调文件。

源应用程序是一个被压缩过的程序包,使用对应的解压方式对源应用程序进行解压,得到程序包中所有的文件,从中查找到所有的主调文件和被调文件。例如,解压缩apk应用程序,找到所有的dex文件和so文件。

步骤202,确定所述被调文件之间的依赖关系,并生成记录依赖关系的依赖文件。

根据查找到的被调文件,确定被调文件之间的依赖关系,记录每个被调文件的依赖关系到依赖文件中。依赖文件为记录所有被调文件依赖关系的文件。具体可以读取每个被调文件执行的动态依赖表。动态依赖表为被调文件相互调用依赖关系的表。记录每个被调文件的动态依赖表,生成所有被调文件加载的依赖表。

例如,将解析找到的apk应用程序的so文件,读取每个so文件执行的动态依赖表,记录每个so文件的动态依赖表,生成so加载的依赖表文件。

步骤203,采用预设压缩算法对源应用程序中的被调文件进行压缩。

在本申请实施例中,具体实现方式与其他实施例描述一致,不做赘述。

步骤204,将所述解压功能文件添加至归属于应用程序的主框架的主调文件。

将所述解压功能文件添加至归属于应用程序的主框架的主调文件可以有多种方式,具体可以是添加外部调用代码到主框架的主调文件中,使得主调文件可以外部调用解压功能文件。还可以是将解压功能文件的代码添加到归属于应用程序的主框架的主调文件中,这样在执行主调文件时就可以更快的执行解压功能文件的解压和加载压缩后的被调文件的功能。

如果应用程序只有一个主调文件,那么这个主调文件就是主框架的主调文件。如果应用程序是分为多个主调文件的,其中跟启动相关的组件会被放入一个主调文件中,这个主调文件称为主框架的主调文件。

例如,可以将初始化代码、自定义对lzma算法压缩的文件进行解压的so文件,然后加载的代码加入到apk应用程序的主dex文件中。

步骤205,在所述主调文件的初始化对象中增加解压功能文件。

主调文件的初始化对象是指执行主调文件时初始要创建的实例,解压功能文件增加到主调文件的初始化对象中。

本申请的一种优选实施例中,所述步骤205中所述在所述主调文件的初始化对象中增加解压功能文件可以包括:

子步骤s5,在所述主调文件的程序入口位置查找运行的首个函数;

子步骤s6,在所述首个函数的调用对象中增加对应所述预设压缩算法的解压功能文件。

从主调文件的程序入口查找运行的第一个函数,在首个函数的调用对象中,增加对应预设压缩算法的解压功能文件。解压功能文件为针对预设压缩算法预先编写的可以解压压缩后的被调文件,并加载被调文件的代码的文件

本申请的一种优选实施例中,在所述步骤205在所述在所述主调文件的初始化对象中增加解压功能文件之前,还可以包括:

子步骤s7,从所述源应用程序的应用全局配置文件中,提取所述源应用程序的程序入口位置的入口类名称。

应用全局配置文件是指整个应用程序的信息描述文件,描述了应用程序中包含的组件、定义了应用程序运行的进程、声明其他程序如果希望访问本程序组件所需要的权限、列出应用程序运行所需要连接的库等。从应用全局配置文件中,提取源应用程序的程序入口位置的入口类名称。例如,解析apk应用程序中的androidmanifest.xml文件获取程序入口点。

本申请的一种优选实施例中,还可以包括:

子步骤s8,反编译对应的主调文件。

在将所述解压功能文件添加至归属于应用程序的主框架的主调文件时,需要先反编译对应的主调文件,然后将解压功能文件添加到主调文件中。而且在将所有主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用时,也需要先反编译对应的主调文件,然后再修改调用。

例如,反编译所有的dex文件,找到apk应用程序的dex文件中所有有关so文件加载的函数,将这些函数统一修改成加入的自定义在lzma压缩文件解压so文件的加载代码。

步骤206,将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用。

在本申请实施例中,具体实现方式与其他实施例描述一致,不做赘述。

步骤207,对所述主调文件在应用程序中所属的功能组件进行重新签名。

签名是指对应用程序进行数字签名。由于对于一些操作系统,安装的程序都要求必须签名,所以这些系统要求所有的应用必须被证书进行数字签名之后才能进行安装。例如,android系统通过该证书来确认应用的作者,该证书是不需要权威机构认证的,一般情况下应用都是用开发者的自签名证书,该证书是确保应用程序和应用程序作者之间建立信任关系,而不是用来决定用户可以安装哪些应用程序。

功能组件是指应用程序中的部分功能或模块,通常以插件形式存在,对修改过的主调文件在应用程序中所属的功能组件进行重新签名。

本申请的一种优选实施例中,在所述步骤207中所述对所述主调文件在应用程序中所属的功能组件进行重新签名之前,还可以包括:

子步骤s9,判定所述主调文件在应用程序中所属的功能组件具有原始签名。

判断主调文件在应用程序中所属的功能组件是否具有原始签名,具体可以查看该功能组件是否有签名,并且判定主调文件在应用程序中所属的功能组件具有原始签名。

步骤208,封装所述依赖文件、修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

将依赖文件、修改后的主调文件、压缩后的被调文件和解压功能文件重新打包,封装为新的应用程序,得到压缩应用程序。具体封装方式为任意适用的方式,本实施例对此不做限制。

例如,将so加载的依赖表文件、修改后的dex文件、lzma算法压缩的所有so文件、预先编译好的能够处理lzma算法的so文件重新打包进入apk应用程序,得到的apk应用程序就是压缩应用程序。

步骤209,对所述压缩应用程序进行签名。

由于对于一些操作系统,安装的程序都要求必须签名,所以这些系统要求所有的应用必须被证书进行数字签名之后才能进行安装。对压缩应用程序进行签名,以保证应用程序能被正常安装运行。

依据本申请实施例,首先解压所述源应用程序,并查找主调文件和被调文件,确定所述被调文件之间的依赖关系,并生成记录依赖关系的依赖文件,采用预设压缩算法对源应用程序中的被调文件进行压缩,例如采用比原有压缩算法压缩率更高的算法,可以提高压缩应用程序的压缩率,得到更小体积的应用程序。进一步,将所述解压功能文件添加至归属于应用程序的主框架的主调文件,在所述主调文件的初始化对象中增加解压功能文件,将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用,对所述主调文件在应用程序中所属的功能组件进行重新签名,封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序,对所述压缩应用程序进行签名,从而使得该应用程序运行时可以调用能够解压预设压缩算法的算法进行解压,从而可以解决了原先对压缩率高的算法无法兼容的问题,可以让应用程序本身具备解压压缩率高的压缩算法的功能,保证采用更高压缩率的应用程序的正常运行。

参照图3,示出了根据本申请实施例三的一种应用程序的解压方法实施例的流程图,该方法具体可以包括以下步骤:

步骤301,解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件。

压缩应用程序为经预设压缩算法压缩以及相应修改后的应用程序。压缩应用程序中有主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件。其中,主调文件定义为调用解压功能文件。具体而言,主调文件在应用程序压缩时,将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用。

对压缩应用程序进行解封装,得到主调文件、采用预设压缩算法压缩的被调文件和预设压缩算法对应的解压功能文件。

例如,apk应用程序是一个压缩应用程序,对该apk应用程序进行解压,得到修改后的dex文件、lzma算法压缩的所有so文件、预先编译好的能够处理lzma算法的so文件。

步骤302,在所述主调文件调用所述被调文件时,调用解压功能文件对压缩的被调文件进行解压和加载。

主调文件调用被调文件时,调用解压功能文件,执行解压功能文件的代码,对压缩的被调文件进行解压和加载。例如,加载处理lzma算法的so文件,执行处理lzma算法的so文件的代码,将压缩的各so文件解压,并加载解压出的so文件,完成对压缩应用程序的解压。

依据本申请实施例,通过解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件,在所述主调文件调用所述被调文件时,调用解压功能文件对压缩的被调文件进行解压和加载,从而使得压缩的应用程序运行时可以调用能够解压预设压缩算法的算法进行解压,从而可以解决了原先对压缩率高的算法无法兼容的问题,实现了应用程序本身可以解压压缩率高的压缩算法,保证采用更高压缩率的应用程序的正常运行。

参照图4,示出了根据本申请实施例四的一种应用程序的解压方法实施例的流程图,该方法具体可以包括以下步骤:

步骤401,解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件。

在本申请实施例中,具体实现方式与其他实施例描述一致,不做赘述。

步骤402,调用主框架的主调文件初始化压缩应用程序中解压功能文件。

在主框架的主调文件的初始化对象中有解压功能文件,调用主框架的主调文件,初始化压缩应用程序中的解压功能文件,

例如,运行apk应用程序时,执行主dex文件,在应用程序压缩阶段已经将调用函数修改,所以会调用到加载处理lzma算法的so文件的函数,将处理lzma算法的so文件加载。

步骤403,判定压缩的被调文件中存在主调文件所需调用的被调文件。

判断压缩的被调文件中是否存在主调文件所需调用的被调文件,如果压缩的被调文件中存在主调文件所需调用的被调文件,则执行步骤405。

例如,判定要加载的so文件存在于lzma算法压缩的文件中。

步骤404,若不存在主调文件所需调用的被调文件,则从当前操作系统查找被调文件或从网络下载所述被调文件。

在本申请实施例中,主调文件调用的被调文件有些是在压缩的被调文件中,有些是在操作系统中,有些是在网络上,如果压缩的被调文件中不存在主调文件所需调用的被调文件,就可以从当前操作系统查找被调文件或从网络下载所述被调文件。

步骤405,在所述主调文件调用所述被调文件时,判定主调文件所需调用的被调文件依赖于另一被调文件。

在主调文件调用被调文件时,先判断主调文件所需调用的被调文件是否依赖于另一被调文件,具体可以根据压缩应用程序中解封装得到的依赖文件进行判断,依赖文件中记录有各被调文件的依赖关系,并且判定主调文件所需调用的被调文件依赖于另一被调文件。

步骤406,调用解压功能文件从压缩的被调文件解压所述另一被调文件。

调用解压功能文件从压缩的被调文件解压另一被调文件,具体可以用解压功能文件中对应的解压算法对预设压缩算法压缩的文件进行解压,得到被调文件依赖的另一被调文件。

步骤407,调用解压功能文件从压缩的被调文件解压主调文件所需调用的被调文件。

调用解压功能文件从压缩的被调文件解压所需的被调文件,具体可以用解压功能文件中对应的解压算法对预设压缩算法压缩的文件进行解压,得到所需调用的被调文件。

步骤408,调用解压功能文件对压缩的被调文件进行解压和加载。

在本申请实施例中,具体实现方式与其他实施例描述一致,不做赘述。

依据本申请实施例,通过解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件,调用主框架的主调文件初始化压缩应用程序中解压功能文件,判定压缩的被调文件中存在主调文件所需调用的被调文件,若不存在主调文件所需调用的被调文件,则从当前操作系统查找被调文件或从网络下载所述被调文件,在所述主调文件调用所述被调文件时,判定主调文件所需调用的被调文件依赖于另一被调文件,调用解压功能文件从压缩的被调文件解压所述另一被调文件,调用解压功能文件从压缩的被调文件解压主调文件所需调用的被调文件,调用解压功能文件对压缩的被调文件进行解压和加载,从而使得压缩的应用程序运行时可以调用能够解压预设压缩算法的算法进行解压,从而可以解决了原先对压缩率高的算法无法兼容的问题,实现了应用程序本身可以解压压缩率高的压缩算法,保证采用更高压缩率的应用程序的正常运行。

为使本领域技术人员更好地理解本申请,以下通过具体的示例对本申请的一种验证方法进行说明。

参见图5,示出了本申请实施例的一个示例中压缩过程示意图。

步骤1:文件解析;对于传入的android应用程序apk包,进行解压,找到压缩包中的所有的so文件,并解析其中的androidmanifest.xml文件。

步骤2:so依赖表生成;so加载需要相应的依赖关系,生成该apk应用程序中各so文件的依赖关系表。

步骤3:so处理;为减少体积,将所有的so文件使用lzma算法压缩到一个压缩文件,同时添加一个预先编译好的能够处理lzma算法的so文件。

步骤4:dex文件修改;由于原先程序所有的so文件都压缩成一个so文件,所以必须拦截java层加载so文件的函数,在运行时调用的时候通过so文件依赖关系表进行转换。

步骤5:文件打包;将预先编译好的能够处理lzma算法的so文件以及so依赖关系表,lzma算法压缩的所有so文件,修改后的dex文件重新打包进入android应用程序中,同时删除原有的so文件。

步骤6:重新签名;使用原来程序的签名文件对重新打包后的android应用程序进行重新签名。

参见图6,示出了本申请实施例的另一个示例中解压过程示意图。

步骤1,首先加载能够解压lzma算法压缩文件的so文件,让该apk应用程序具有解压lzma压缩文件的功能。

步骤2,当应用程序需要加载so文件时,也就是执行so文件加载逻辑,由于在打包阶段已经将调用函数修改,所以会调用到自定义加载so文件的函数。

步骤3,首先判断要加载的so文件是否在lzma压缩文件中,如果在则执行步骤4,如果不在表示加载系统so文件或者从网上动态下载的so文件,无需解压,直接调用系统函数加载。

步骤4,根据传入的so文件名称来在预先内置的lzma压缩文件中,解压出来这个so文件,如果该so的加载需要依赖其他的so文件,也需要将其他so文件也解压出来。

步骤5,得到解压出来的so文件路径,调用系统接口来加载这个so文件,完成加载。

参考图7,示出了根据本申请实施例五的一种应用程序的压缩装置的结构框图,具体可以包括:

被调文件压缩模块501,用于采用预设压缩算法对源应用程序中的被调文件进行压缩;

调用修改模块502,用于将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用,所述解压功能文件用于解压和加载压缩后的被调文件;

应用程序封装模块503,用于封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

可选地,所述装置还包括:

被调文件查找模块,用于在所述采用预设压缩算法对源应用程序中的被调文件进行压缩之前,查找所述源应用程序中可采用预设压缩算法进行压缩的被调文件。

可选地,所述被调文件为动态链接库文件,所述主调文件为调用所述动态链接库文件的可执行文件;所述被调文件查找模块,具体用于在所述源应用程序包括的多种类型的文件中查找动态链接库文件。

可选地,所述装置还包括:

功能文件增加模块,用于在所述主调文件的初始化对象中增加解压功能文件。

可选地,所述装置还包括:

功能文件添加模块,用于将所述解压功能文件添加至归属于应用程序的主框架的主调文件。

可选地,所述功能文件增加模块包括:

函数查找子模块,用于在所述主调文件的程序入口位置查找运行的首个函数;

功能文件增加子模块,用于在所述首个函数的调用对象中增加对应所述预设压缩算法的解压功能文件。

可选地,所述装置还包括:

入口类名称提取子模块,用于在所述在所述主调文件的初始化对象中增加解压功能文件之前,从所述源应用程序的应用全局配置文件中,提取所述源应用程序的程序入口位置的入口类名称。

可选地,所述装置还包括:

主调文件反编译模块,用于反编译对应的主调文件。

可选地,所述装置还包括:

依赖文件生成模块,用于确定所述被调文件之间的依赖关系,并生成记录依赖关系的依赖文件。

可选地,所述应用程序封装模块,具体用于封装所述依赖文件、修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序。

可选地,所述应用程序封装模块包括:

主调文件压缩子模块,用于对修改后的主调文件进行压缩,并替换至修改前的主调文件所处位置;

压缩添加子模块,用于对所述压缩后的被调文件和解压功能文件进行压缩,并添加至所述源应用程序中,得到压缩应用程序。

可选地,所述应用程序封装模块还包括:

主框架文件压缩子模块,用于提取归属于应用程序的主框架的主调文件并进行压缩,得到压缩后的主框架文件,所述主框架的主调文件中已添加所述解压功能文件;

主框架文件替换子模块,用于采用压缩后的主框架文件替换所述源应用程序原有的主框架文件。

可选地,所述装置还包括:

组件签名模块,用于在所述封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序之前,对所述主调文件在应用程序中所属的功能组件进行重新签名。

可选地,所述装置还包括:

原始签名判定模块,用于在所述对所述主调文件在应用程序中所属的功能组件进行重新签名之前,判定所述主调文件在应用程序中所属的功能组件具有原始签名。

可选地,所述装置还包括:

源应用程序解压模块,用于在所述采用预设压缩算法对源应用程序中的被调文件进行压缩之前,解压所述源应用程序,并查找主调文件和被调文件。

可选地,所述装置还包括:

应用程序签名模块,用于对所述压缩应用程序进行签名。

可选地,所述预设压缩算法为lzma算法。

依据本申请实施例,首先采用预设压缩算法对源应用程序中的被调文件进行压缩,例如采用比原有压缩算法压缩率更高的算法,可以提高压缩应用程序的压缩率,得到更小体积的应用程序。进一步,将主调文件对被调文件的调用修改为对所述预设压缩算法对应的解压功能文件的调用,封装修改后的主调文件、压缩后的被调文件和解压功能文件,得到压缩应用程序,从而使得该应用程序运行时可以调用能够解压预设压缩算法的算法进行解压,从而可以解决了原先对压缩率高的算法无法兼容的问题,可以让应用程序本身具备解压压缩率高的压缩算法的功能,保证采用更高压缩率的应用程序的正常运行。

参考图8,示出了根据本申请实施例六的一种应用程序的解压装置的结构框图,具体可以包括:

应用程序解封装模块601,用于解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件;所述主调文件定义为调用所述解压功能文件;

解压和加载模块602,用于在所述主调文件调用所述被调文件时,调用解压功能文件对压缩的被调文件进行解压和加载。

可选地,所述装置还包括:

功能文件初始化模块,用于在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,调用主框架的主调文件初始化压缩应用程序中解压功能文件。

可选地,所述装置包括:

被调文件存在判定模块,用于在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,判定压缩的被调文件中存在主调文件所需调用的被调文件。

可选地,所述装置还包括:

查找下载模块,用于若不存在主调文件所需调用的被调文件,则从当前操作系统查找被调文件或从网络下载所述被调文件。

可选地,所述装置包括:

依赖判定模块,用于在所述调用解压功能文件对压缩的被调文件进行解压和加载之前,判定主调文件所需调用的被调文件依赖于另一被调文件;

依赖文件解压模块,用于调用解压功能文件从压缩的被调文件解压所述另一被调文件;

文件解压模块,用于调用解压功能文件从压缩的被调文件解压主调文件所需调用的被调文件。

依据本申请实施例,通过解封装压缩应用程序得到主调文件、采用预设压缩算法压缩的被调文件和所述预设压缩算法对应的解压功能文件,在所述主调文件调用所述被调文件时,调用解压功能文件对压缩的被调文件进行解压和加载,从而使得压缩的应用程序运行时可以调用能够解压预设压缩算法的算法进行解压,从而可以解决了原先对压缩率高的算法无法兼容的问题,实现了应用程序本身可以解压压缩率高的压缩算法,保证采用更高压缩率的应用程序的正常运行。

由于所述装置实施例基本相应于前述图1、图2、图3和图4所示的方法实施例,故本实施例的描述中未详尽之处,可以参见前述实施例中的相关说明,在此就不赘述了。

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

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

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

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

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

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

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

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1