CN110554867A - 一种应用程序的处理方法和装置 - Google Patents

Abstract

本申请实施例提供了一种应用程序的处理方法和一种应用程序的处理装置，所述方法包括确定待处理应用程序的依赖模块；获取所述待处理应用程序的主资源类；获取所述依赖模块的依赖资源类；建立所述依赖资源类与所述主资源类之间的映射关系；根据所述映射关系调整所述依赖模块。应用本申请实施例，可以根据映射关系并发调整应用程序的依赖模块，减少依赖模块的字段数，从而精简了应用程序。

Description

一种应用程序的处理方法和装置

技术领域

本申请涉及数据处理技术领域，特别是涉及一种应用程序的处理方法和一种应用程序的处理装置。

背景技术

随着应用程序的功能越来越多，应用程序也越来越大，而应用程序通常是打包之后进行发包以供用户下载安装。

对某些大型应用程序而言，例如购物平台和视频平台，功能繁多，代码量非常大，如果不做代码精简优化而直接打包，会导致整个安装包非常大，同时大量的可执行代码也会影响应用程序的线上稳定性，因此对代码的精简、优化等打包是必须的。

目前，应用程序打包通常是直接使用proguard工具对应用程序的代码一次性进行精简、优化和混淆后打包，如果在代码构建过程中生成的资源类R.java非常多，那么代码编译后的dex文件也会变大，这样安装包会比较大，打包也会耗时较长，降低了应用程序的打包效率和应用程序的发布效率。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种应用程序的处理方法和相应的一种应用程序的处理装置。

为了解决上述问题，本申请公开了一种应用程序的处理方法，包括：

确定待处理应用程序的依赖模块；

获取所述待处理应用程序的主资源类；

获取所述依赖模块的依赖资源类；

建立所述依赖资源类与所述主资源类之间的映射关系；

根据所述映射关系调整所述依赖模块。

优选地，在所述确定待处理应用程序的依赖模块之前，还包括：

获取待处理应用程序；

对所述待处理应用程序进行解压缩处理，得到所述待处理应用程序的可执行文件；

对所述可执行文件进行反编译，得到所述待处理应用程序的源代码。

优选地，所述待处理应用程序具有对应的清单文件，所述获取所述依赖模块的依赖资源类，包括：

获取依赖模块的包名；

根据所述包名在所述清单文件中查找到依赖资源类名；

根据所述依赖资源类名确定所述依赖模块的依赖资源类。

优选地，所述建立所述依赖资源类与所述主资源类之间的映射关系，包括：

确定所述依赖资源类所归属的主资源类；

建立所述主资源类与归属与所述主资源类的依赖资源类之间的映射关系。

优选地，所述根据所述映射关系调整所述依赖模块，包括：

根据所述映射关系删除所述依赖模块的依赖资源类；

根据所述映射关系将删除依赖资源类后的依赖模块的资源类指向所述主资源类。

优选地，所述根据所述映射关系将删除依赖资源类后的依赖模块的资源类指向所述主资源类，包括：

根据所述映射关系确定删除的依赖资源类对应的主资源类；

将删除依赖资源类后的依赖模块指向所述主资源类。

优选地，所述清单文件为androidManifest.xml。

本申请实施例还公开了一种应用程序的处理装置，包括：

依赖模块确定模块，用于确定待处理应用程序的依赖模块；

主资源类获取模块，用于获取所述待处理应用程序的主资源类；

依赖资源类获取模块，用于获取所述依赖模块的依赖资源类；

映射关系建立模块，用于建立所述依赖资源类与所述主资源类之间的映射关系；

依赖模块调整模块，用于根据所述映射关系调整所述依赖模块。

优选地，还包括：

待处理应用程序获取模块，用于获取待处理应用程序；

解压缩处理模块，用于对所述待处理应用程序进行解压缩处理，得到所述待处理应用程序的可执行文件；

源代码获得模块，用于对所述可执行文件进行反编译，得到所述待处理应用程序的源代码。

优选地，所述映射关系建立模块包括：

归属确定子模块，用于确定所述依赖资源类所归属的主资源类；

映射关系建立子模块，用于建立所述主资源类与归属与所述主资源类的依赖资源类之间的映射关系。

本申请还公开了一种装置，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行如上述的方法。

本申请还公开了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如上述的方法。

本申请实施例包括以下优点：

本申请实施例中，在确定待处理应用程序的依赖模块后，获取该应用程序的主资源类，以及依赖模块的依赖资源类，然后建立所述依赖资源类与所述主资源类之间的映射关系，并根据映射关系调整依赖模块。应用本申请实施例，可以根据映射关系并发调整应用程序的依赖模块，减少依赖模块的字段数，从而精简了应用程序。

附图说明

图1是本申请的一种应用程序的处理方法实施例1的步骤流程图；

图2是本申请的一种应用程序的处理方法实施例2的步骤流程图；

图3是本申请的一种应用程序的依赖模块处理过程的示意图；

图4是本申请的一种应用程序的处理装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

行业内目前广泛采用的是proguard来做资源类的裁剪，proguard是利用如下两种方式裁剪字段数：

1、将常量属性直接内敛，从而减少该字段数。

具体地，常量属性在java里是用关键字final表示的，表明这个属性的值在运行过程中是不可以修改的。

例如：

使用proguard优化后会被内敛为：

public void printA(){

System.out.println(100)；

}

2、通过代码引用关系，分析出没有被引用的属性，从而删除该字段数。

例如：

由于A_NO_USE没有被方法printA引用，所以会被proguard认为是无用代码，从而裁剪掉：

因此可以看出proguard比较明显的缺点有：

1、依赖proguard，明显降低构建速度，而通常debug(排除故障)构建不做proguard；

2、需要资源类必须开启常量否则不生效，而当前的插件化常量并未开启；

3、通过代码引用关系裁剪资源类，这个又要求不能对资源类做反射操作，有一定的限制性。

本申请实施例针对上述问题，提出了一种对应用程序的代码处理策略，对代码进行裁剪的同时，保证资源类能够被正常调用。下面对于本申请实施例进行介绍。

参照图1，示出了本申请的一种应用程序的处理方法实施例1的步骤流程图，具体可以包括如下步骤：

步骤101，确定待处理应用程序的依赖模块。

应用程序可以是为完成某项或多项特定工作的计算机程序，它运行在用户模式，可以和用户进行交互，具有可视的用户界面，对应于不同的系统平台，应用程序可以通过不同的编写语言构建，例如对于安卓平台，可以通过Java语言进行编写，其源代码可以为JavaScript代码。

应用程序的源代码可以从应用程序的开发文档中直接读取，也可以是对已打包过的应用程序进行解压后进行反汇编获取应用程序的源代码，本申请实施例对应用程序的源代码的获取方式不加以限制。

本申请的一种优选实施例中，在所述步骤101之前，还可以包括如下子步骤：

子步骤S11，获取待处理应用程序。

子步骤S12，对所述待处理应用程序进行解压缩处理，得到所述待处理应用程序的可执行文件；

子步骤S13，对所述可执行文件进行反编译，得到所述待处理应用程序的源代码。

本申请实施例中，应用程序可以在项目开发者中获取，该应用程序可以是以压缩包的形式存在，因此需要对应用程序进行解压缩，得到可执行文件(dex文件)。可执行文件是指可以有操作系统进行加载执行并可以进行编译的文件，其是通过对源代码进行编译和处理后得到的，因此可以对可执行文件进行反编译，得到应用程序的源代码。

在实际应用中，一个应用程序通常包括多个不同的依赖模块，各个依赖模块对应相应的代码，以利于项目的模块化开发，例如，在一个购物应用程序中，通常包括首页、购物车、商品详情等依赖模块，因此可以确定应用程序里的多个业务模块。

步骤102，获取所述待处理应用程序的主资源类。

在具体实现中，应用程序具有其对应的资源类，可以通过获取到应用程序对应的主资源类，该主资源类所对应的资源类是一个全量的资源类。

步骤103，获取所述依赖模块的依赖资源类。

获取应用程序的主资源后，还会获取应用程序的依赖模块的依赖资源类，依赖模块的资源类跟主资源类为包含关系。

步骤104，建立所述依赖资源类与所述主资源类之间的映射关系。

在得到主资源和依赖资源后，将比对两者建立映射关系。

步骤105，根据所述映射关系调整所述依赖模块。

在得到映射关系后，就可以根据映射关系去调整依赖模块，去除依赖模块中不必要的字段数，从而精简依赖模块。

本申请实施例中，在确定待处理应用程序的依赖模块后，获取该应用程序的主资源类，以及依赖模块的依赖资源类，然后建立所述依赖资源类与所述主资源类之间的映射关系，并根据映射关系调整依赖模块。应用本申请实施例，可以根据映射关系并发调整应用程序的依赖模块，减少依赖模块的字段数，从而精简了应用程序。

参照图2，示出了本申请的一种应用程序的处理方法实施例2的步骤流程图，具体可以包括如下步骤：

步骤201，确定待处理应用程序的依赖模块。

在实际应用中，应用程序通常有多个依赖模块，各个依赖模块都有其对应的依赖资源类，依赖模块的资源类都在应用程序的主资源类里都有，本申请实施例的目标在于精简依赖模块。

步骤202，获取所述待处理应用程序的主资源类。

应用程序对应的主资源类，主资源类所对应的资源类是一个全量的资源类，包括依赖模块的依赖资源类。

步骤203，获取依赖模块的包名。

在具体实现中，依赖模块具有对应的包名(packagename)。

步骤204，根据所述包名在所述清单文件中查找到依赖资源类名。

步骤205，根据所述依赖资源类名确定所述依赖模块的依赖资源类。

每个应用程序都会对应一个主要的清单文件中(AndroidManifest文件)，里面存储了包的详细信息，是一个xml结构的文件。解析xml文件，获取它的package字段(包名)，可以推算出资源类对应的类名，比如xml中取得的package字段是a.b.c,那么资源类就应该是a.b.c.R及其所有的内部类。

步骤206，建立所述依赖资源类与所述主资源类之间的映射关系。

在本申请的一种优选实施例中，所述步骤206可以包括如下子步骤：

子步骤S21，确定所述依赖资源类所归属的主资源类；

子步骤S22，建立所述主资源类与归属与所述主资源类的依赖资源类之间的映射关系。

在实际中，依赖模块的依赖资源类跟主资源类为包含关系，可以通过比对确定两者之间的归属，在确定两者的归属后，就可以建立存在归属的依赖资源类与主资源类之间的映射关系。

步骤207，根据所述映射关系删除所述依赖模块的依赖资源类。

本申请实施例可以根据映射关系进行字节码操作，删除依赖模块的依赖资源。

具体地，先获取确定应用程序的依赖模块，分析出各个依赖模块的包名，比如a.b.e和a.b.f，依赖模块的资源类都是可以被删除的，所以可以建立诸如a.b.e.R->a.b.c.R.和a.b.f.R->a.b.c.R的映射关系，a.b.e.R$String->a.b.c.R$String等等。

步骤208，根据所述映射关系将删除依赖资源类后的依赖模块的资源类指向所述主资源类。

通过映射关系进行字节码的操作，删除依赖模块对应的资源类后，随后还将所有的引用依赖资源类的依赖模块重新指向主app的资源类，这样，虽然依赖模块删除了其依赖资源类，但是还可以引用主资源类，故而不影响其正常工作。

本申请实施例处理应用程序时在代码层面上处理，在完成对于依赖模块的处理后，将保存修改后的数据。这些数据通常主要是jar或者包含class的文件，可以在经过一系列的处理会转换成dex文件，结合资源编译后的产物，形成最终的一个编译好的独立插件。

下面采用一个具体的实例对于本申请的应用程序处理过程进行说明。参照图3，所示为本申请的一种应用程序的依赖模块处理过程的示意图，具体过程包括有：

1、获取应用程序(APP)的包名(packagename)，确定需要处理的应用程序；

2、分析出所述应用程序的所有主资源类；

3、对于依赖1和依赖2(依赖模块)，获取依赖1和依赖2的包名(packagename)；

4、根据包名并发分析出所有依赖模块的依赖资源类；

5、根据主资源类和依赖资源类建立映射关系；

6、根据映射关系并发删除依赖模块的依赖资源类；

7、根据映射关系，修改字节码，并调整依赖模块的资源引用关系，具体来说，将依赖模块引用指向主资源类，由于主资源类中包含了依赖模块的依赖资源类，故而依赖模块引用主资源类仍然可以正常工作；

9、保存修改后的依赖模块。

本发明实施例通过字节码的操作，直接合并了分散的资源类，统一指向应用程序的主资源类，在效果上只保留了一份应用程序的主资源类，至少去除了一半的字段数，另外在插件化的方案中，比如atlas的业务bundle中，由于依赖模块对应的资源类都包含了应用程序的主资源类，导致字段数也非常大，这样会导致可执行文件无法构建，本申请实施例则很好的解决了这个问题。另外在构建速度上，对于一个超大型的应用程序，仅仅只需要消耗很短时间就可以完成。

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

参照图4，示出了本申请的一种应用程序的处理装置实施例的结构框图，具体可以包括如下模块：

依赖模块确定模块301，用于确定待处理应用程序的依赖模块；

主资源类获取模块302，用于获取所述待处理应用程序的主资源类；

依赖资源类获取模块303，用于获取所述依赖模块的依赖资源类；

映射关系建立模块304，用于建立所述依赖资源类与所述主资源类之间的映射关系；

依赖模块调整模块305，用于根据所述映射关系调整所述依赖模块。

在本申请的一种优选实施例中，还包括：

待处理应用程序获取模块，用于获取待处理应用程序；

解压缩处理模块，用于对所述待处理应用程序进行解压缩处理，得到所述待处理应用程序的可执行文件；

源代码获得模块，用于对所述可执行文件进行反编译，得到所述待处理应用程序的源代码。

在本申请的一种优选实施例中，所述待处理应用程序具有对应的清单文件，所述依赖资源类获取模块303包括：

包名获取子模块，用于获取依赖模块的包名；

依赖资源类名查找子模块，用于根据所述包名在所述清单文件中查找到依赖资源类名；

依赖资源类确定子模块，用于根据所述依赖资源类名确定所述依赖模块的依赖资源类。

在本申请的一种优选实施例中，所述映射关系建立模块304包括：

归属确定子模块，用于确定所述依赖资源类所归属的主资源类；

映射关系建立子模块，用于建立所述主资源类与归属与所述主资源类的依赖资源类之间的映射关系。

在本申请的一种优选实施例中，所述依赖模块调整模块305包括：

依赖资源类删除子模块，用于根据所述映射关系删除所述依赖模块的依赖资源类；

主资源类指向子模块，用于根据所述映射关系将删除依赖资源类后的依赖模块的资源类指向所述主资源类。

在本申请的一种优选实施例中，所述主资源类指向子模块包括：

主资源类确定单元，用于根据所述映射关系确定删除的依赖资源类对应的主资源类；

主资源类指向单元，用于将删除依赖资源类后的依赖模块指向所述主资源类。

在本申请的一种优选实施例中，所述清单文件为androidManifest.xml。

本申请实施例还提供了一种装置，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行实施例1和实施例2所述的一个或多个的方法。

本申请实施例还提供了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行实施例1和实施例2所述的一个或多个的方法。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

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

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

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

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

Claims (10)

1.一种应用程序的处理方法，其特征在于，包括：

确定待处理应用程序的依赖模块；

获取所述待处理应用程序的主资源类；

获取所述依赖模块的依赖资源类；

建立所述依赖资源类与所述主资源类之间的映射关系；

根据所述映射关系调整所述依赖模块。

2.如权利要求1所述的打包方法，其特征在于，在所述确定待处理应用程序的依赖模块之前，还包括：

获取待处理应用程序；

对所述待处理应用程序进行解压缩处理，得到所述待处理应用程序的可执行文件；

对所述可执行文件进行反编译，得到所述待处理应用程序的源代码。

3.根据权利要求1所述的方法，其特征在于，所述待处理应用程序具有对应的清单文件，所述获取所述依赖模块的依赖资源类，包括：

获取依赖模块的包名；

根据所述包名在所述清单文件中查找到依赖资源类名；

根据所述依赖资源类名确定所述依赖模块的依赖资源类。

4.根据权利要求1所述的方法，其特征在于，所述建立所述依赖资源类与所述主资源类之间的映射关系，包括：

确定所述依赖资源类所归属的主资源类；

建立所述主资源类与归属与所述主资源类的依赖资源类之间的映射关系。

5.根据权利要求4所述的方法，其特征在于，所述根据所述映射关系调整所述依赖模块，包括：

根据所述映射关系删除所述依赖模块的依赖资源类；

根据所述映射关系将删除依赖资源类后的依赖模块的资源类指向所述主资源类。

6.根据权利要求5所述的方法，其特征在于，所述根据所述映射关系将删除依赖资源类后的依赖模块的资源类指向所述主资源类，包括：

根据所述映射关系确定删除的依赖资源类对应的主资源类；

将删除依赖资源类后的依赖模块指向所述主资源类。

7.一种应用程序的处理装置，其特征在于，包括：

依赖模块确定模块，用于确定待处理应用程序的依赖模块；

主资源类获取模块，用于获取所述待处理应用程序的主资源类；

依赖资源类获取模块，用于获取所述依赖模块的依赖资源类；

映射关系建立模块，用于建立所述依赖资源类与所述主资源类之间的映射关系；

依赖模块调整模块，用于根据所述映射关系调整所述依赖模块。

8.如权利要求7所述的打包装置，其特征在于，还包括：

待处理应用程序获取模块，用于获取待处理应用程序；

解压缩处理模块，用于对所述待处理应用程序进行解压缩处理，得到所述待处理应用程序的可执行文件；

源代码获得模块，用于对所述可执行文件进行反编译，得到所述待处理应用程序的源代码。

9.根据权利要求7所述的装置，其特征在于，所述映射关系建立模块包括：

归属确定子模块，用于确定所述依赖资源类所归属的主资源类；

映射关系建立子模块，用于建立所述主资源类与归属与所述主资源类的依赖资源类之间的映射关系。

10.一种装置，其特征在于，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，其特征在于，当由所述一个或多个处理器执行时，使得所述装置执行如权利要求1-7所述的一个或多个的方法。