应用程序包构成的拆分方法、装置、终端及介质与流程

本发明涉及计算机技术领域，特别是涉及一种应用程序包构成的拆分方法、装置、终端及计算机可读存储介质。

背景技术：

众所周知，安卓(android)系统上的应用程序(app，application)是以一种安卓安装包(apk，androidpackage)文件形式分发和被安装的，随着app业务的迭代，app包(即apk文件)的体积会累积膨胀，使得应用商店分发app包的转化效率降低。针对这种体积膨胀，现有技术中，仅能分析出app包中资源和源代码(dex)的体积占比，并不能计算出源代码(dex)中各业务代码的构成占比，也就无法长期监控每个业务的体积增长，无法对源代码部分的精准量化，不利于后续精简app包(apk文件)的体积。同时，用户安装体积较大的app包后在其移动终端(比如手机等)上占用的存储空间也会越来越大，从而降低了用户的使用性能。

因此，如何确定app包(apk文件)中各业务代码的构成进行量化，是目前有待解决的技术问题。

技术实现要素：

本发明实施例所要解决的技术问题是提供一种应用程序包构成的拆分方法，以解决现有技术中由于无法确定app包中各业务代码的构成占比，不能对app包(apk文件)的构成进行量化，导致用户使用性能差的技术问题。

相应的，本发明实施例还提供了一种应用程序包构成的拆分装置、终端及计算机可读存储介质，用以保证上述方法的实现及应用。

为了解决上述问题，本发明是通过如下技术方案实现的：

第一方面提供一种应用程序包的拆分方法，包括：

确定应用程序app包中待分拆的多个业务模块；

获取打包流程中生成的字典mapping文件；

根据所述mapping文件确定所述多个业务模块中每个业务模块的分类标识；

根据所述每个业务模块的分类标识生成对应的安卓虚拟机可执行dex文件；

对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包。

可选的，所述mapping文件包括：全部的源代码文件与字节码文件的对应关系，所述根据所述mapping文件确定所述多个业务模块中每个业务模块的分类标识，包括：

从所述mapping文件中获取所述多个业务模块中每个业务模块的源代码文件；

根据每个业务模块的源代码文件获取对应的字节码文件；

对所述多个业务模块中每个业务模块对应的字节码文件的起点标签和结束点标签进行标记，得到对应业务模块的分类标识。

可选的，在生成对应的dex文件之前，所述方法还包括：

对安卓编译源码的dex处理部分的源码进行修改，增加解析副dex列表标签的代码；

所述根据所述每个业务模块的分类标识生成对应的dex文件，具体包括：利用修改后的代码以及每个业务模块的分类标识，依次解析多个业务模块中每个业务模块对应的字节码文件，得到解析后每个业务模块的字节码文件；以及，根据解析后每个业务模块的字节码文件，生成对应的dex文件。

可选的，在对所有dex文件进行重新打包之前，还包括：

对dex文件的命名规则进行修改，得到识别每个业务模块的分类标识的dex文件命名规则；

所述对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包，具体包括：根据修改后的dex文件命名规则，对生成的所有dex文件按照多个业务模块的分类标识进行重新打包，得到已拆分dex文件的app包。

第二方面提供一种应用程序包构成的拆分装置，包括：

第一确定模块，用于确定应用程序app包中待分拆的多个业务模块；

获取模块，用于获取打包流程中生成的字典mapping文件；

第二确定模块，用于根据所述mapping文件确定所述多个业务模块中每个业务模块的分类标识；

生成模块，用于根据所述每个业务模块的分类标识生成对应的安卓虚拟机可执行dex文件；

重打包模块，用于对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包。

可选的，所述获取模块获取的所述mapping文件包括：全部的源代码文件与字节码文件的对应关系；

所述第二确定模块包括：

源代码文件获取模块，用于从所述mapping文件中获取所述多个业务模块中每个业务模块的源代码文件；

字节码文件获取模块，用于根据每个业务模块的源代码文件获取对应的字节码文件；

分类标识模块，用于对所述多个业务模块中每个业务模块对应的字节码文件的起点标签和结束点标签进行标记，得到对应业务模块的分类标识。

可选的，还包括：

编译源码修改模块，用于在所述生成模块生成对应的dex文件之前，对安卓编译源码的dex处理部分的源码进行修改，增加解析副dex列表标签的代码。

可选的，所述生成模块包括：

解析模块，用于利用所述编译源码修改模块修改后的所述代码以及每个业务模块的分类标识，依次解析多个业务模块中每个业务模块对应的字节码文件，得到解析后每个业务模块的字节码文件；

文件生成模块，用于根据解析后每个业务模块的字节码文件，生成对应的dex文件。

可选的，还包括：

规则修改模块，用于在所述重打包模块对所有dex文件进行重新打包之前，对dex文件的命名规则进行修改，得到识别每个业务模块的分类标识的dex文件命名规则；

所述重打包模块，具体用于利用修改后的dex文件命名规则，对生成的所有dex文件按照多个业务模块的分类标识进行重新打包，得到已拆分dex文件的app包。

第三方面提供一种终端，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上述的应用程序包构成的拆分方法中的步骤。

第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述的应用程序包构成的拆分方法中的步骤。

与现有技术相比，本发明实施例包括以下优点：

本发明实施例中，先确定app包中待分拆的多个业务模块，然后，根据打包流程中生成的字典mapping文件确定所述多个业务模块中每个业务模块的分类标识，并根据所述每个业务模块的分类标识生成对应的dex文件；最后，对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包。也就是说，本发明实施例中，可以根据需要先确定app(apk文件)包中待拆分的业务模块，然后，将app包中dex按各个业务模块的分类标识进行分拆，因为一个dex文件就对应一个业务模块，dex文件的大小的代表了业务模块的大小；所以，根据已拆分dex文件的app包，可以精准的计算出app包(apk文件)中各业务的体积占比，实现了对源代码部分的精准量化，提高了用户的使用性能，并为后续的分析和针对性地推动相关业务精简代码，提供有力的量化数据。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

图1是本发明实施例提供的一种应用程序包构成的拆分方法的流程图；

图2是本发明实施例提供的一种应用程序包构成的拆分方法的流程图；

图3是本发明实施例提供的一种应用程序包构成的拆分装置的结构示意图；

图4是本发明实施例提供的一种应用程序包构成的拆分装置的另一结构示意图；

图5是本发明实施例提供的一种应用程序包构成的拆分装置的另一结构示意图。

具体实施方式

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

本发明实施例中，app包(即apk文件)通常包括资源和代码，对于资源(比如图片等)的构成，可以通过现有的方法进行分析，而目前，对于代码的dex文件的构成还无法拆分，基于此，本发明实施例提供一种对app包中的dex文件的构成进行拆分的方法，其具体的实现过程详见下述实施例。

请参阅图1，为本发明实施例提供的一种应用程序包构成拆分方法的流程图，具体可以包括如下步骤：

步骤101：确定应用程序app包中待分拆的多个业务模块；

该步骤中，多个业务模块，可以包括播放视频模块、页面展示模块(即卡片)、支付模块等，这些业务模块可以从不同的维度来划分，也可以称为不同部门对应的业务模块。

也就是说，如果用户想了解或者量化app包中的哪些业务模块的构成，用户可以通过终端上的应用程序接口输入待拆分业务模块(比如播放视频模块、页面展示模块等)的名称，而终端在接收到用户输入的名称后，会在app包中dex源代码的位置生成一份待配置清单，配置希望分拆的各业务模块。而这些业务模块就作为待拆分的业务模块。

步骤102：获取打包流程中生成的字典mapping文件；

该步骤中，通过安卓(andorid)正常的打包流程，生成一份发布版本的安卓安装包(apk，androidpackage)文件，在此过程中，也会生成字典(mapping)文件，也可以称为索引文件，在该mapping文件中，包括全部的源代码文件(即java文件)、字节码文件(即class文件)，以及源代码文件与字节码文件的对应关系。

步骤103：根据所述mapping文件确定所述多个业务模块中每个业务模块的分类标识；

该步骤中，先从所述mapping文件中获取所述多个业务模块中每个业务模块的源代码文件，以及根据每个业务模块的源代码文件获取对应的字节码文件；然后，对所述多个业务模块中每个业务模块对应的字节码文件的起点标签和结束点标签进行标记，得到对应业务模块的分类标识。

也就是说，该步骤中，根据mapping文件中的源代码文件与字节码文件的对应关系，依次检索各个业务模块的源代码文件(java文件)，然后，根据源代码文件与字节码文件的对应关系，匹配到对应的各个业务模块的字节码文件(class文件)；之后，对每个业务模块对应的字节码文件的起点标签和结束点标签进行标识，该实施例中，可以用--subdex-start|far与--subdex-over|far标签来标识。--subdex-start|far与--subdex-over|far之间所包含的字节码文件(class文件)即为far业务对应的字节码文件。

步骤104：根据所述每个业务模块的分类标识生成对应的安卓虚拟机可执行dex文件；

该步骤中，利用预先修改的代码以及每个业务模块的分类标识，依次解析多个业务模块中每个业务模块对应的字节码文件，得到解析后每个业务模块的字节码文件；根据解析后每个业务模块的字节码文件，生成对应的dex文件。

也就是说，通过读取预先修改的代码，来解析--sub-dexes-list中的配置项，按照之前分类的--subdex-start，--subdex-over标签把每个业务模块对应字节码文件依次解析出来，即得到解析后每个业务模块的字节码文件。

在读取到每个--subdex-over时，就调用androiddex生成方法，将解析到的各业务模块的字节码文件(class文件)，转换成apk文件所需的dex文件。

步骤105：对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包。

该步骤中，根据预先修改后的dex文件命名规则，对生成的所有dex文件按照多个业务模块的分类标识进行重新打包，得到已拆分dex文件的app包。

其中，该步骤中，默认dex命名规则是以classes+数字+“.dex”依次进行命名的，如：classes.dex，classes2.dex…classesn.dex。而在重打包阶段，修改了getsubdexespath这部分命名规则的源码，使其按照业务名称进行命名，得到修改后的dex文件命名规则，之后，通过修改后的dex命名规则生成的app包(apk文件)中，dex文件的大小就是各个业务源代码在最终app包(apk文件)里的大小。例如，far.dex文件的大小对应的就是far业务模块的源代码在最终apk文件中所占的大小。

本发明实施例中，先确定app包中待分拆的多个业务模块，然后，根据打包流程中生成的字典mapping文件确定所述多个业务模块中每个业务模块的分类标识，并根据所述每个业务模块的分类标识生成对应的dex文件；最后，对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包。也就是说，本发明实施例中，可以根据需要先确定app(apk文件)包中的待拆分的业务模块，然后，将app包中dex按各个业务模块的分类标识进行分拆，因为一个dex文件就对应一个业务模块，dex文件的大小的代表了业务模块的大小；所以，根据已拆分dex文件的app包，可以精准的计算出app包(apk文件)中各业务模块的构成占比，实现了对源代码部分的精准量化，提高了用户的使用性能，并为后续的分析和针对性地推动相关业务精简代码，提供有力的量化数据。

还请参阅图2，为本发明实施例提供的一种应用程序包构成的拆分方法的另一流程图，所述方法包括：

步骤201：确定app包中待分拆的多个业务模块；

终端在接收到用户输入的待拆分业务模块的名称后，会在app包中dex源代码的位置生成一份待配置清单，配置希望分拆的各业务模块。具体的实现过程与步骤101同，具体详见上述，在此不再赘述。

步骤202：获取打包流程中生成的字典mapping文件；

该步骤与步骤102的实现过程相同，具体详见上述，在此不再赘述。

步骤203：根据所述mapping文件确定所述多个业务模块中每个业务模块的分类标识；

该实施例中，在从所述mapping文件中获取所述多个业务模块中每个业务模块的源代码文件，以及根据每个业务模块的源代码文件获取对应的字节码文件后，对每个业务模块对应的字节码文件的起点标签和结束点标签进行标识，可以用--subdex-start|far与--subdex-over|far标签来标识。为了便于理解，该标识称为对不同业务模块的分类标识。比如，以程序段1中下划线所指的内容为例：

程序段1

--subdex-over|hostproject

--subdex-start|far

com/example/far/b.class

com/example/far/a.class

com/example/far/faractivity.class

--subdex-over|far

由该程序段可知，--subdex-start|far与--subdex-over|far之间所包含的字节码文件(class文件)即为far业务对应的字节码文件。

步骤204：对安卓编译源码的dex处理部分的源码进行修改，增加解析副dex列表标签的代码；

也就是说，修改android编译源码(android.tools.build:gradle)中dex处理部分的源码，使其像支持识别android原生的主dex标识一样，具备识别配置文件中副dex列表标签的分类标识的能力，即增加解析副dex列表标签的代码。

也就是说，仿照android解析--main-dex-list标签，修改dex处理部分的源代码，得到代码，该编译源码修改支持新增的配置文件属性，比如，主dex列表(--sub-dexes-list)，具体如下述程序段中下划线所指的内容，为了便于理解，只是以该程序段2为例：

程序段2

之后，修改后的源码像解析android自有的主dex列表(—main-dex-list)一样去解析副dex列表--sub-dexes-list。比如，下述程序段中的下划线所指的内容，为了便于理解，只是以该程序段3为例：

程序段3

步骤205：利用修改的代码以及每个业务模块的分类标识，依次解析多个业务模块中每个业务模块对应的字节码文件，得到解析后每个业务模块的字节码文件；

该实施例中，读取修改后的代码后，解析--sub-dexes-list中的配置项，按照之前分类的--subdex-start，--subdex-over标签把每个业务模块对应字节码文件依次进行解析，得到解析后每个业务模块的字节码文件。具体如下述程序段4的下划线所示，为了便于理解，只是以该程序段4为例；

程序段4

步骤206：根据解析后每个业务模块的字节码文件，生成对应的dex文件；

该步骤中，在读取到每个--subdex-over时，调用androiddex生成方法，将解析到的各业务模块的字节码文件(class文件)，转换成apk文件所需的dex文件。

步骤207：对dex文件的命名规则进行修改，得到识别每个业务模块的分类标识的dex文件命名规则；

该步骤中，默认的命名规则是以classes+数字+“.dex”依次进行命名，如：classes.dex,classes2.dex…classesn.dex。而在重打包阶段，修改了getsubdexespath这部分命名规则的源码，使其按照业务名称进行名称，得到修改后的dex文件命名规则。

步骤208：根据修改后的dex文件命名规则，对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包。

该步骤中，通过修改后的dex命名规则编译生成的app包(apk文件)中，dex文件的大小就是各个业务源代码在最终app包(apk文件)里的大小。例如far.dex对应的就是far业务模块的源代码在最终apk文件中所占的大小。

本发明实施例中，可以根据需要先确定app(apk文件)包中的待拆分的业务模块，然后，将app包中dex按各个业务模块的分类标识进行分拆，精准的计算出app包(apk文件)中各业务的体积占比，按需生成最终的dex文件，并对dex文件进行重新打包，得到已拆分dex文件的app包，实现了对源代码部分的精准量化，提高了用户的使用性能，并为后续的分析和针对性地推动相关业务精简代码，提供有力的量化数据。

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

请参阅图3，为本发明实施例提供的一种应用程序包构成的拆分装置的结构示意图，具体可以包括如下模块：第一确定模块31，获取模块32，第二确定模块33，生成模块34和重打包模块35，其中，

第一确定模块31，用于确定应用程序app包中待分拆的多个业务模块；

获取模块32，用于获取打包流程中生成的字典mapping文件；

第二确定模块33，用于根据所述mapping文件确定所述多个业务模块中每个业务模块的分类标识；

生成模块34，用于根据所述每个业务模块的分类标识生成对应的安卓虚拟机可执行dex文件；

重打包模块35，用于对生成的所有dex文件进行重新打包，得到已拆分dex文件的app包。

可选的，在另一实施例中，该实施例在上述实施例的基础上，所述获取模块获取的所述mapping文件包括：全部的源代码文件与字节码文件的对应关系；

所述第二确定模块包括：源代码文件获取模块和字节码文件获取模块，分类标识模块(图中未示)，其中，

源代码文件获取模块，用于从所述mapping文件中获取所述多个业务模块中每个业务模块的源代码文件；

字节码文件获取模块，用于根据每个业务模块的源代码文件获取对应的字节码文件；

分类标识模块，用于对所述多个业务模块中每个业务模块对应的字节码文件的起点标签和结束点标签进行标记，得到对应业务模块的分类标识。

可选的，在另一实施例中，该实施例在上述实施例的基础上，所述装置还可以包括：编译源码修改模块41，其结构示意图如图4所示，其中，

编译源码修改模块41，用于在所述生成模块生成对应的dex文件之前，对安卓编译源码的dex处理部分的源码进行修改，增加解析副dex列表标签的代码；

可选的，在另一实施例中，该实施例在上述实施例的基础上，所述生成模块包括：解析模块和文件生成模块(图中未示)，其中，

解析模块，用于利用编译源码修改模块修改后的代码以及每个业务模块的分类标识，依次解析多个业务模块中每个业务模块对应的字节码文件，得到解析后每个业务模块的字节码文件；

文件生成模块，用于根据解析后每个业务模块的字节码文件，生成对应的dex文件。

可选的，在另一实施例中，该实施例在上述实施例的基础上，还包括：规则修改模块51，其结构示意图如图5所示，其中，

规则修改模块51，用于在所述重打包模块对所有dex文件进行重新打包之前，对dex文件的命名规则进行修改，得到识别每个业务模块的分类标识的dex文件命名规则；

所述重打包模块35，具体用于根据规则修改模块51修改后的dex文件命名规则，对生成的所有dex文件按照多个业务模块的分类标识进行重新打包，得到已拆分dex文件的app包。

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

本发明实施例中，可以根据需要先确定app(apk文件)包中的待拆分的业务模块，然后，将app包中dex按各个业务模块的分类标识进行分拆，精准的计算出app包(apk文件)中各业务的体积占比，按需生成最终的dex文件，并对dex文件进行重新打包，得到已拆分dex文件的app包，并为后续的分析和针对性地推动相关业务精简代码，提供有力的量化数据。

可选的，本发明实施例还提供一种终端，包括处理器，存储器，存储在存储器上并可在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述应用程序包构成的拆分方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述应用程序包构成的拆分方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(read-onlymemory，简称rom)、随机存取存储器(randomaccessmemory，简称ram)、磁碟或者光盘等。

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

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

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

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

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

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

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