一种可自定义的dex分包的方法与流程

本发明涉及dex文件转换技术领域，具体说是一种可自定义的dex分包的方法。

背景技术：

在android系统中，开发app的工作随着业务规模发展，不断的加入新的代码，添加新的类库，当工程中的方法数超过65535时，就会遇到以下这个错误INSTALL FAILED DEXOPT，导致app无法安装，开发无法进行。

出现上述问题的原因是：因为Android系统使用Dalvik虚拟机，所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的dex文件。当Android系统启动一个应用(app)的时候DexOpt(系统内部的一个工具，用来优化dex文件，及查看源文件的详细信息)会对dex文件进行优化。DexOpt会把每一个类的方法id检索起来，存在一个链表结构里面，但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过65535个。

Dexopt使用一个固定大小的缓冲区LinearAlloc来存储应用的方法信息。Android 2.2和2.3的LinearAlloc只有5MB，Android 4.x提高到了8MB或16MB。当方法数量过多会导致超出缓冲区LinearAlloc大小，这也会造成Dexopt崩溃。

现有技术对此的解决方案通常是：使用谷歌官方的Multidex Support Library来解决这个问题，实现原理是将class编译进不同的classes.dex文件中。这种方法存在以下技术缺陷：

不能根据项目实际需求自动智能的指定哪些类必须包含在主dex中，需要人工分析，手动指定哪些类应该放在主dex中，在大的工程开发中，人工分析、手动添加文件列表的方式显然不现实，很容易导致应用启动时某些类找不到，出现Class Not Found Exception，造成应用崩溃无法使用。

技术实现要素：

针对现有技术中存在的缺陷，本发明的目的在于提供一种可自定义的dex分包的方法，在生成dex文件的过程中，对类文件进行依赖分析，动态的指定主dex文件，避免应用安装时出现错误INSTALL FAILED DEXOPT，避免运行时出现Class Not Found Exception造成应用崩溃无法使用。

为达到以上目的，本发明采取的技术方案是：

一种可自定义的dex分包的方法，其特征在于，包括如下步骤：

步骤101，根据app首次启动加载所必需类，配置规则文件，所述规则文件包括自定义配置的main_dex保留类规则文件；

步骤102，在编译过程中，当执行到dex前置任务时，根据步骤101所述规则文件寻找自定义配置的main_dex保留类的依赖关系，将找到的自定义配置的main_dex保留类的所有依赖类的全路径名称输出到指定文件；

步骤103，将步骤102所述指定文件中记载的依赖类的全路径名称列表，和系统在构建时生成的默认的main_dex保留类文件列表合并。

在上述技术方案的基础上，步骤101中，所述app首次启动加载所必需类尤指启动页及程序初始化相关所必需类。

在上述技术方案的基础上，步骤101中，所述规则文件记载希望保留在main_dex中的类；

规则具体格式如下：

保留单个类，以class：开头，类文件的全路径名称为一行；

保留整个类库，以jar：开头，以类库的全路径名称为一行；

以*代表通配符。

在上述技术方案的基础上，步骤102的具体步骤如下：

步骤201，在Android Gradle脚本的编译过程中，在生成main_dex任务队列中插入自定义Task任务；

步骤202，在自定义Task任务中，调用分析工具对步骤101中所述自定义配置的main_dex保留类以及该保留类所依赖的类进行循环分析。

在上述技术方案的基础上，步骤201中，任务队列指在Android Gradle脚本编译构建应用时，生成main_dex的文件列表，需要经历的Task任务队列。

在上述技术方案的基础上，在自定义Task任务中，调用Class Dependency Analyzer分析工具，动态的干预main_dex的文件列表的生成。

在上述技术方案的基础上，步骤202的具体步骤如下：

步骤301，读取步骤101中的规则文件，将该规则文件中所有保留类文件名称列表存在内存中；

步骤302，读取系统混淆后生成的mapping文件，根据mapping文件中混淆后和混淆前的对应关系，查找步骤301中所有保留类文件名称列表对应的混淆之后的类名字，所述混淆之后的类名字为混淆后的类文件名；

步骤303，调用Class Dependency Analyzer分析工具，以步骤302读取出来的混淆后的类文件名为索引，通过类文件字节码的constant pool，找出类的依赖关系，这些依赖包括super class、fields、methods及interfaces中出现的类的依赖，将查找出来的保留类的依赖类输出到临时文件中，然后以查找出来的保留类的依赖类为索引，继续调用Class Dependency Analyzer分析工具，直到查找不到类的依赖关系。

在上述技术方案的基础上，在步骤103中，将步骤303所述临时文件中记载的所有互相依赖的类的全路径名称列表，和系统在构建时生成的默认的main_dex保留类文件列表合并，完成干预系统生成main_dex保留类文件列表的目的。

本发明所述的可自定义的dex分包的方法，在打包过程中嵌入，针对系统的主dex文件列表进行依赖分析，将遗漏的同时程序启动时所必要的类文件打包到主dex中，不依赖于人为的分析主dex文件依赖，避免了人为因素分析不完整，不正确导致出现Class Not Found Exception，造成应用崩溃无法使用，稳定性、可靠性好。

本发明所述的可自定义的dex分包的方法，对其他所有的安卓项目工程同样具有非常好的适用性。

附图说明

本发明有如下附图：

图1本发明方法流程图。

图2分析工具进行循环分析流程图。

具体实施方式

以下结合附图对本发明作进一步详细说明。

如图1所示，本发明所述的可自定义的dex分包的方法，包括如下步骤：

步骤101，根据app首次启动加载所必需类(尤指启动页及程序初始化相关所必需类)，配置规则文件，所述规则文件包括自定义配置的main_dex保留类规则文件；

步骤102，在编译过程中，当执行到dex前置任务时，根据步骤101所述规则文件寻找自定义配置的main_dex保留类的依赖关系，将找到的自定义配置的main_dex保留类的所有依赖类的全路径名称输出到指定文件；

步骤103，将步骤102所述指定文件中记载的依赖类的全路径名称列表，和系统在构建时生成的默认的main_dex保留类文件列表合并。

在上述技术方案的基础上，步骤101中，所述规则文件记载希望保留在main_dex中的类；

规则具体格式如下：

保留单个类，以class：开头，类文件的全路径名称为一行；

保留整个类库，以jar：开头，以类库的全路径名称为一行；

以*代表通配符。

在上述技术方案的基础上，步骤102的具体步骤如下：

步骤201，在Android Gradle脚本的编译过程(指编译构建应用)中，在生成main_dex任务队列中插入自定义Task任务；

步骤202，在自定义Task任务中，调用分析工具对步骤101中所述自定义配置的main_dex保留类以及该保留类所依赖的类进行循环分析。

在上述技术方案的基础上，步骤201中，任务队列指在Android Gradle脚本编译构建应用时，生成main_dex的文件列表(即默认的main_dex保留类文件列表)，需要经历的Task任务队列，任务队列具体包括以下Task任务队列：

Task1：collectReleaseMultiDexComponents

该Task1根据AndroidManifest(指Andriod应用程序的清单文件)，保留Activity，Service，Broadcastreceiver，ContentProvider，Instrumentation，application，输出到：

build\intermediates\multi-dex\release\manifest_keep.txt

Task2：PackageAllReleaseClassesForMultiDex

该Task2打包所有的jar，输出到：build\intermediates\multi-dex\release\allclasses.jar

Task3：ShrinkReleaseMultiDexComponents

该Task3根据上面的Task 1生成的manifest_keep.txt和Task2生成的allclasses.jar，加上proguard混淆文件，生成混淆后的jar，输出到：

build\intermediates\multi-dex\release\componentClasses.jar

Task4：createReleaseMainDexClassList

该Task4根据上面Task 3产生的componentsClasses.jar和Task2产生的allclasses.jar，最终生成main dex list，包含了所有main_dex的class文件，输出到：

build\intermediates\multi-dex\release\maindexlist.txt

。在Task1～4任务队列中插入自定义Task任务。

在上述技术方案的基础上，在自定义Task任务中，调用Class Dependency Analyzer分析工具，动态的干预main_dex的文件列表的生成。

在上述技术方案的基础上，如图2所示，步骤202的具体步骤如下：

步骤301，读取步骤101中的规则文件，将该规则文件中所有保留类文件名称列表存在内存中；

步骤302，读取系统混淆后生成的mapping文件，根据mapping文件中混淆后和混淆前的对应关系，查找步骤301中所有保留类文件名称列表对应的混淆之后的类名字，所述混淆之后的类名字为混淆后的类文件名；

所述对应关系可以通过混淆后生成的类的格式来进行精确查找，混淆后的类在类名后面有“：”作为标示，以下是一个示例：

混淆前的类名“android.net.http.SslError”，

混淆后的类名“android.a.a.a:”，

步骤303，调用Class Dependency Analyzer分析工具，以步骤302读取出来的混淆后的类文件名为索引，通过类文件字节码的constant pool(常量池)，找出类的依赖关系，这些依赖包括super class(类的父类)、fields(类的字段)、methods(类的方法)及interfaces(类的接口)中出现的类的依赖，将查找出来的保留类的依赖类输出到临时文件中，然后以查找出来的保留类的依赖类为索引，继续调用Class Dependency Analyzer分析工具，直到查找不到类的依赖关系。

在上述技术方案的基础上，在步骤103中，将步骤303所述临时文件中记载的所有互相依赖的类的全路径名称列表，和系统在构建时生成的默认的main_dex保留类文件列表合并，完成干预系统生成main_dex保留类文件列表的目的。

本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。