Android分包方案multidex

xiaoxiao2021-02-28  11

对于功能越来越复杂的app的两大问题

问题一:当项目越来越大,方法数超过65536,编译时会出错(为什么是65536,参考下面关于dexopt对方法id检索存储介绍),这个所说的方法数包含用到的框架,依赖的jar包,当然还有我们应用本身的代码中的所有方法(我们自己写的)。

我们可以写个Demo看看报的具体错误。

那我们写个65536以上个方法,可以用Java的IO流向一个txt里写入65537个方法。

public class MethodWriter { public static void main(String[] args) throws IOException{ FileWriter fw = new FileWriter("demo.txt"); for(int i = 1 ; i <= 65537; i++){ fw.write( "public void me" + i + "(){ }\r\n" ); fw.flush(); } fw.close(); } }        

然后复制txt文件里的方法到AS工程里即可。注意,将这些方法分别放在几个类下面,保证每个类不要超过65536。我们所说的65536限制是整个项目的限制。下面,我们分两种方案放置这些方法,运行项目,看看AS会有什么结果。

方案一:我们自己应用的方法数超过了65536  我们所说的方法数限制,这个方法数包括了jar包,框架,还有我们自己应用的代码,当我们应用的代码超过65536时,结果如下:

我们看到,显示我们方法的引用是65579.而引用数最大是65536,建议我们开启分包方案。

方案二:我们应用的方法数没有超过65536,但是加上依赖的jar包,框架等,超过了65536(根据方案一的结果,我们应用方法数是65579,那我们删掉200个方法,就小于65536)

报错如下:

问题二:方法数并没有超过65536,编译也完成了,但是在android2.3以前的系统安装的时候,会异常中止安装。

这个问题会发生在Android 2.2以及Android 2.3的设备上,涉及到一个名为dexopt的程序,全称dex optimization,即dex文件优化程序。在优化过程中,dexopt采用一个固定大小的缓冲区(LinearAlloc)来存储应用中所有方法的信息,那么之所以会出现在老版本停止安装,是因为老版本的缓冲区的大小是5M,而在新版本中,这个缓冲区的大小是8M或者16M,在老版本中更容易超过这个限制。

dexopt的执行过程是在第一次加载dex文件的时候执行的。这个过程产生了一个ODEX文件,全称Optimised Dex。这个ODEX文件是在安装过程中从apk里提取出的可运行文件,是优化dex产生的,再把apk包里的dex文件删除,这样就做到了预先提取。如果没有ODEX文件,那么系统会从apk包中提取dex然后再运行。所以优化后可以加快软件的启动速度,预先提取,减少对RAM的占用。

在早期的Android系统中,dexopt会把每一个类的方法id检索起来,存在一个链表结构里,而这个链表的长度是用一个short类型来保存的,导致方法id的数目不能够超过65536个。虽然新版本的android系统中,dexopt修复了这个问题,但是老版本的android系统的用户市场占有率还是占一定比例,还是不能放弃这部分用户的,所以我们在开发中需要对老版本的这个问题进行兼容。

2.方法数越界的解决方案

插件化技术

我们可以采用动态加载部分dex,通过将一个dex拆分成两个或多个dex,解决方法数越界的问题。

插件化是一套重量级的技术方案,我们需要通过反射来调用插件的类或方法,要使用一套插件框架来配合,而且插件化适合一些独立的模块,兼容性问题往往较多,如果只是用于解决方法数越界的话,并不是最好的方案。

multidex解决方案

为了解决方法数越界的问题,Google在2014年提出了multidex的解决方案,这个方案主要是针对AndroidStudio和Gradle编译环境的,将一个dex文件拆成两个或多个dex文件。

不过需要注意的是multidex有一个版本问题,在Android 5.0以前使用multidex需要手动引入Google提供的android-support-multidex.jar这个jar包。这个jar包我们可以在Android SDK目录下的extras/android/support/multidex/library/libs下找到。而从Android 5.0开始,Andorid默认支持了multidex。

所以,我们就需要注意我们的SDK版本了,如果已经支持了multidex,而我们又把android-support-multidex.jar放在了项目的libs文件下,就会报错。

3.在Gradle和代码中配置使用Multidex

在Gradle中配置使用Multidex

由于Android的Gradle插件在Android Build Tool 21.1开始支持使用multidex,所以我们需要使用Android Build Tools 21.1及以上版本,修改app目录下的build.gradle文件,有两点需要修改。

(1)在defaultConfig中添加multiDexEnabled true这个配置项。  (2)在dependencies中添加multidex的依赖:  compile ‘com.android.support:multidex:1.0.0’

注意buildToolsVersion要高于21.1,配置好如下: 

在Gradle中配置好之后,我们还需要在代码中加入支持multidex的功能,有三种方案可选

方案一:在manifest文件中指定Application为MultiDexApplication,如下:

方案二:写一个Application类并继承MultiDexApplication,并在AndroidManifest.xml的application标签中进行注册(在application标签中增加name属性,并添加自己的Application类名即可),如果不是想重写MultiDexApplication中一些方法的话,还是方案一更方便些。如下:

注册如下:

方案三:如果不想按方案二继承,我们可以重写Application的attachBaseContext方法,注意,这个方法比onCreate方法先执行。具体方法是创建一个新类,继承Application,然后重写attachBaseContext方法,并在AndroidManifest.xml的application标签中进行注册(与方案二注册相同)如下:

对于在AndroidManifest.xml中注册,与方案二的注册相同。

3.使用Multide分包后两种情况的结果

我们的Demo图如下,我们根据该图和dex文件反编译的结果分析分包情况。

情况一:方法数没有越界  我们将方法数控制在65536以内,方法数没有越界的话,是不会分包的,解压apk,你会发现apk里只有一个classes.dex,如下

将其反编译后(不知道怎么反编译的可以看一下这篇博文:http://blog.csdn.net/gaozhan_csdn/article/details/51984056),结果如下:

可以发现,我们的类都在这个主dex文件里,并没有分包。

情况二:方法数越界

我们再将方法数增加到65536以上。解压apk,结果如下: 

对三个dex文件反编译一下,看看它们里面分别都包含了什么类。  classes.dex(主dex)下的类视图: 

classes2.dex的类视图

classes3.dex的类视图

可以发现Second类和Third类分别在classes2.dex文件和classes3.dex文件里,其他类都在主dex文件里(classes.dex),我们用multidex的确实现了分包从而解决了方法数越界的问题。

4.使用MultiDex存在的一些问题

1.Application 中的静态全局变量会比MutiDex的 instal()方法优先加载,所以建议避免在Application类中使用静态变量引用main classes.dex文件以外dex文件中的类。 或者这样解决:

一些在二级Dex加载之前,可能会被调用到的类(比如静态变量的类),需要放在主Dex中.否则会ClassNotFoundError. 通过修改Gradle,可以显式的把一些类放在Main Dex中.

afterEvaluate { tasks.matching { it.name.startsWith('dex') }.each { dx -> if (dx.additionalParameters == null) { dx.additionalParameters = [] } dx.additionalParameters += '--multi-dex' dx.additionalParameters += "--main-dex-list=$projectDir/<filename>".toString() } }

注意上面是修改后的Gradle,其中是一个文本文件的文件名,存放在和这个build.gradle脚本同一级的文件目录下,而不是 项目根目录。可以把这个文本文件起名为multidex.keep,内容如下.实际就是把需要放在Main Dex的类罗列出来.

android/support/multidex/BuildConfig/class android/support/multidex/MultiDex$V14/class android/support/multidex/MultiDex$V19/class android/support/multidex/MultiDex$V4/class android/support/multidex/MultiDex/class android/support/multidex/MultiDexApplication/class android/support/multidex/MultiDexExtractor$1/class android/support/multidex/MultiDexExtractor/class android/support/multidex/ZipUtil$CentralDirectory/class android/support/multidex/ZipUtil/class

project.afterEvaluate标签在特定的project配置完成后运行,而gradle.projectsEvaluated在所有projects配置完成后运行。 注意afterEvaluate需要放在android{}里,不可放外面。

但是最新的as中,会自动判断依赖关系来分dex,比如以下application中: public class MyApp extends MultiDexApplication { public static MutilTest5 mutilTest5 = new MutilTest5(); @Override public void onCreate() { super.onCreate(); } } 默认情况下,本来MuitlText5要分到class2.dex里面去,但是因为app里静态变量需要用到MuitlText5,如果放到class2.dex中会找不到(因为app中静态变量初始化会在加载主dex文件之前执行),所以会自动放到主dex文件里去 但是如果依靠as自动分析,在你代码存在反射和native的情况下,也不保证100%正确,如果不正确,还是需要自己配置哪个类放到主dex中
转载请注明原文地址: https://www.6miu.com/read-1400168.html

最新回复(0)