Android MultiDex的用法记录

1、Multidex的产生

在android5.0之前,每一个android应用中只会含有一个dex文件,但是因为Android系统本身的BUG,使得这个dex的方法数量被限制在65535之内,这就是著名的"64K(64*1024)"事件。为了解决这个问题,Google官方推出了这个类似于补丁一样的support-library。关于这个库的详细使用,可以参考官方文档,当然使用起来也会有些坑的,美团填坑记或者这位老兄。使用这个库后,我们的APP不再只会仅有一个dex文件,可能会产生多个dex文件,这样就避免了64K问题。

2.如何引入MultiDex?

2.1.修改gradle脚本来产生多dex。

2.2.修改manifest 使用MulitDexApplication。

步骤1.在gradle脚本里写上:

android{

compileSdkVersion21

buildToolsVersion"21.1.0"

defaultConfig{

...

minSdkVersion14

targetSdkVersion21

...

// Enabling multidex support.

multiDexEnabledtrue

}

...

}

dependencies{

compile'com.android.support:multidex:1.0.0'

}

步骤2. manifest声明修改


package="com.example.android.multidex.myapplication">

...

android:name="android.support.multidex.MultiDexApplication">

...

a . 如果没有自己的Application,则上面的manifest设置已经够了,

b.  如果有自己的Application,继承MulitDexApplication。如果当前代码已经继承自其它Application没办法修改那也行,就重写 Application的attachBaseContext()这个方法。

@Override

protectedvoidattachBaseContext(Contextbase){

super.attachBaseContext(base);

MultiDex.install(this);

}

引入multiDex后会碰到的坑

1.在应用安装到手机上的时候dex文件的安装是复杂的(complex)有可能会因为第二个dex文件太大导致ANR(Application not Response应用无响应)。请用proguard优化你的代码。

2.使用了mulitDex的App有可能在4.0(api level 14)以前的机器上无法启动,因为Dalvik linearAlloc bug(Issue22586) 。请多多测试自祈多福。用proguard优化你的代码将减少该bug几率。

3.使用了mulitDex的App在runtime期间有可能因为Dalvik linearAlloc limit (Issue78035) Crash。该内存分配限制在 4.0版本被增大,但是5.0以下的机器上的Apps依然会存在这个限制。

4.主dex被dalvik虚拟机执行时候,哪些类必须在主dex文件里面这个问题比较复杂。build tools 可以搞定这个问题。但是如果你代码存在反射和native的调用也不保证100%正确。

INSTALL_FAILED_DEXOPT 解决方案:

apk是一个zip压缩包,dalvik每次加载apk都要从中解压出class.dex文件,加载过程还涉及到dex的classes需要的杂七杂八的依赖库的加载,真耗时间。于是Android决定优化一下这个问题,在app安装到手机之后,系统运行dexopt程序对dex进行优化,将dex的依赖库文件和一些辅助数据打包成odex文件。存放在cache/dalvik_cache目录下。保存格式为apk路径 @ apk名 @ classes.dex。这样以空间换时间大大缩短读取/加载dex文件的过程。

那刚才那个bug是啥问题呢,原来dexopt程序的dalvik分配一块内存来统计你的app的dex里面的classes的信息,由于classes太多方法太多超过这个linearAlloc 的限制 。那减小dex的大小就可以咯。

gradle脚本如下:

android.applicationVariants.all{

variant->

dex.doFirst{

dex->

if(dex.additionalParameters==null){

dex.additionalParameters=[]

}

dex.additionalParameters+='--set-max-idx-number=48000'

}

}

--set-max-idx-number= 用于控制每一个dex的最大方法个数,写小一点可以产生好几个dex。 踩过更多坑的FB的工程师表示这个linearAlloc的限制不仅仅在安装时候的dexopt程序里7,还在你的app的dalvik rumtime里。(很显然啊dvk vm的宿主进程fork自于同一个母体啊)。为了表示对这个坑的不满以及对Google的产品表示遗憾,FB工程师Read The Fucking Source Code找到了一个hack方案。这个linearAlloc的size定义在c层而且是一个全局变量,他们通过对结构体的size的计算成功覆盖了该值的内容,这里要特别感谢C语言的指针和内存的设计。C的世界里,You Are The King of This World。当然实际情况是大部分用户用这把利刃割伤了自己

首次安装运行ANR问题

于是发现 是 install dex + dexopt 时间太长!

梳理流程:

安装完app点击图标之后,系统木有发现对应的process,于是从该apk抽取classes.dex(主dex) 加载,触发 一次dexopt。

App 的laucherActivity准备启动 ,触发Application启动,

Application的 onattach()方法调用,这时候MultiDex.install()调用,classes2.dex 被install,再次触发dexopt。

然后Applicaition onCreate()执行。

然后 launcher Activity真的起来了。

这些必须在5s内完成不然就ANR给你看!

问题到现在变成了:既希望在Application的attachContext()方法里同步加载secondary.dex,又不希望卡住UI线程。如果思路限制在线程异步化上,确实不可能实现。于是发现了微信开发团队的这篇文章。该文章介绍了关于这一问题 FB/QQ/微信的解决方案。FB的解决思路特别赞,让Launcher Activity在另外一个进程启动!当然这个Launcher Activity就是用来load dex 的 ,load完成就启动Main Activity。

微信这篇文章给出了一个非常重要的观点:安装完成之后第一次启动时,是secondary.dex的dexopt花费了更多的时间。认识到这点非常重要,使得问题又转化为:在不阻塞UI线程的前提下,完成dexopt,以后都不需要再次dexopt,所以可以在UI线程install dex 了!文章最后给了一个对FB方案的改进版。

仔细读完感觉完全可行。

1.对现有代码改动量最小。

2.该方案不关注Application被哪个组件启动。Activity ,Service ,Receiver ,ContentProvider 都满足。(有个问题要说明:如细心网友指出的那样,新安装还未启动但是收到Receiver的场景下,会导致Load界面出现。这个场景实际出现几率比较少,且仅出现一次。可以接受。)

3.该方案不限制 Application ,Activity ,Service ,Receiver ,ContentProvider 继续新增业务。

主要的原理:application启动了LoadDexActivity之后,自身不再是前台进程所以怎么hold 线程都不会ANR

参考链接:http://blog.zongwu233.com/the-touble-of-multidex/?from=groupmessage&isappinstalled=0

你可能感兴趣的:(Android MultiDex的用法记录)