转载自:https://m.oschina.net/blog/308583

当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象

1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT

2. 方法数量过多,编译时出错,提示:

Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536

出现这种问题的原因是

1. Android2.3及以前版本用来执行dexopt(用于优化dex文件)的内存只分配了5M

2. 一个dex文件最多只支持65536个方法。

针对上述问题,也出现了诸多解决方案,使用的最多的是插件化,即将一些独立的功能做成一个单独的apk,当打开的时候使用DexClassLoader动态加载,然后使用反射机制来调用插件中的类和方法。这固然是一种解决问题的方案:但这种方案存在着以下两个问题:

1. 插件化只适合一些比较独立的模块;

2. 必须通过反射机制去调用插件的类和方法,因此,必须搭配一套插件框架来配合使用;

由于上述问题的存在,通过不断研究,便有了dex分包的解决方案。简单来说,其原理是将编译好的class文件拆分打包成两个dex,绕过dex方法数量的限制以及安装时的检查,在运行时再动态加载第二个dex文件中。faceBook曾经遇到相似的问题,具体可参考:

https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920

文中有这么一段话:

However, there was no way we could break our app up this way--too many of our classes are accessed directly by the Android framework. Instead, we needed to inject our secondary dex files directly into the system class loader。

文中说得比较简单,我们来完善一下该方案:除了第一个dex文件(即正常apk包唯一包含的Dex文件),其它dex文件都以资源的方式放在安装包中,并在Application的onCreate回调中被注入到系统的ClassLoader。因此,对于那些在注入之前已经引用到的类(以及它们所在的jar),必须放入第一个Dex文件中。

下面通过一个简单的demo来讲述dex分包方案,该方案分为两步执行:

整个demo的目录结构是这样,我打算将SecondActivity,MyContainer以及DropDownView放入第二个dex包中,其它保留在第一个dex包。

一、编译时分包

整个编译流程如下:

除了框出来的两Target,其它都是编译的标准流程。而这两个Target正是我们的分包操作。首先来看看spliteClasses target。

由于我们这里仅仅是一个demo,因此放到第二个包中的文件很少,就是上面提到的三个文件。分好包之后就要开始生成dex文件,首先打包第一个dex文件:

由这里将${classes}(该文件夹下都是要打包到第一个dex的文件)打包生成第一个dex。接着生成第二个dex,并将其打包到资资源文件中:

可以看到,此时是将${secclasses}中的文件打包生成dex,并将其加入ap文件(打包的资源文件)中。到此,分包完毕,接下来,便来分析一下如何动态将第二个dex包注入系统的ClassLoader。

二、将dex分包注入ClassLoader

这里谈到注入,就要谈到Android的ClassLoader体系。

由上图可以看出,在叶子节点上,我们能使用到的是DexClassLoader和PathClassLoader,通过查阅开发文档,我们发现他们有如下使用场景:

1. 关于PathClassLoader,文档中写到: Android uses this class for its system class loader and for its application class loader(s),

由此可知,Android应用就是用它来加载;

2. DexClass可以加载apk,jar,及dex文件,但PathClassLoader只能加载已安装到系统中(即/data/app目录下)的apk文件。

知道了两者的使用场景,下面来分析下具体的加载原理,由上图可以看到,两个叶子节点的类都继承BaseDexClassLoader中,而具体的类加载逻辑也在此类中:

BaseDexClassLoader:

[java] view plaincopy

  1. @Override

  2. protected Class<?> findClass(String name) throws ClassNotFoundException {

  3. List<Throwable> suppressedExceptions = new ArrayList<Throwable>();

  4. Class c = pathList.findClass(name, suppressedExceptions);

  5. if (c == null) {

  6. ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);

  7. for (Throwable t : suppressedExceptions) {

  8. cnfe.addSuppressed(t);

  9. }

  10. throw cnfe;

  11. }

  12. return c;

  13. }

由上述函数可知,当我们需要加载一个class时,实际是从pathList中去需要的,查阅源码,发现pathList是DexPathList类的一个实例。ok,接着去分析DexPathList类中的findClass函数,

DexPathList:

[java] view plaincopy

  1. public Class findClass(String name, List<Throwable> suppressed) {

  2. for (Element element : dexElements) {

  3. DexFile dex = element.dexFile;

  4. if (dex != null) {

  5. Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);

  6. if (clazz != null) {

  7. return clazz;

  8. }

  9. }

  10. }

  11. if (dexElementsSuppressedExceptions != null) {

  12. suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));

  13. }

  14. return null;

  15. }

上述函数的大致逻辑为:遍历一个装在dex文件(每个dex文件实际上是一个DexFile对象)的数组(Element数组,Element是一个内部类),然后依次去加载所需要的class文件,直到找到为止。

看到这里,注入的解决方案也就浮出水面,假如我们将第二个dex文件放入Element数组中,那么在加载第二个dex包中的类时,应该可以直接找到。

带着这个假设,来完善demo。

在我们自定义的BaseApplication的onCreate中,我们执行注入操作:

[java] view plaincopy

  1. public String inject(String libPath) {

  2. boolean hasBaseDexClassLoader = true;

  3. try {

  4. Class.forName("dalvik.system.BaseDexClassLoader");

  5. } catch (ClassNotFoundException e) {

  6. hasBaseDexClassLoader = false;

  7. }

  8. if (hasBaseDexClassLoader) {

  9. PathClassLoader pathClassLoader = (PathClassLoader)sApplication.getClassLoader();

  10. DexClassLoader dexClassLoader = new DexClassLoader(libPath, sApplication.getDir("dex", 0).getAbsolutePath(), libPath, sApplication.getClassLoader());

  11. try {

  12. Object dexElements = combineArray(getDexElements(getPathList(pathClassLoader)), getDexElements(getPathList(dexClassLoader)));

  13. Object pathList = getPathList(pathClassLoader);

  14. setField(pathList, pathList.getClass(), "dexElements", dexElements);

  15. return "SUCCESS";

  16. } catch (Throwable e) {

  17. e.printStackTrace();

  18. return android.util.Log.getStackTraceString(e);

  19. }

  20. }

  21. return "SUCCESS";

  22. }

这是注入的关键函数,分析一下这个函数:

参数libPath是第二个dex包的文件信息(包含完整路径,我们当初将其打包到了assets目录下),然后将其使用DexClassLoader来加载(这里为什么必须使用DexClassLoader加载,回顾以上的使用场景),然后通过反射获取PathClassLoader中的DexPathList中的Element数组(已加载了第一个dex包,由系统加载),以及DexClassLoader中的DexPathList中的Element数组(刚将第二个dex包加载进去),将两个Element数组合并之后,再将其赋值给PathClassLoader的Element数组,到此,注入完毕。

现在试着启动app,并在TestUrlActivity(在第一个dex包中)中去启动SecondActivity(在第二个dex包中),启动成功。这种方案是可行。

但是使用dex分包方案仍然有几个注意点:

1. 由于第二个dex包是在Application的onCreate中动态注入的,如果dex包过大,会使app的启动速度变慢,因此,在dex分包过程中一定要注意,第二个dex包不宜过大。

2. 由于上述第一点的限制,假如我们的app越来越臃肿和庞大,往往会采取dex分包方案和插件化方案配合使用,将一些非核心独立功能做成插件加载,核心功能再分包加载。

[转]Android dex分包方案的更多相关文章

  1. Android dex分包方案

    当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方法数量过多,编译时 ...

  2. Android dex分包方案和热补丁原理

    一.分包的原因: 当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方 ...

  3. dex分包方案

    当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方法数量过多,编译时 ...

  4. android 基于分包方案的修复

    # 本demo实现原理来自 https://github.com/dodola/HotFix https://zhuanlan.zhihu.com/p/20308548 # Anti类功能,及其原理 ...

  5. Android Dex分包之旅

    http://yydcdut.com/2016/03/20/split-dex/ http://blog.zongwu233.com/the-touble-of-multidex http://tec ...

  6. android分包方案

    当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方法数量过多,编译时 ...

  7. dex分包变形记

    腾讯Bugly特约作者:李金涛 一.背景 就在项目灰度测试前不久,爆出了在 Android 3.0以下手机上安装时出现 INSTALL _ FAILED_DEXOPT,导致安装失败.这一问题意味着项目 ...

  8. Android分包方案multidex

    对于功能越来越复杂的app的两大问题 问题一:当项目越来越大,方法数超过65536,编译时会出错(为什么是65536,参考下面关于dexopt对方法id检索存储介绍),这个所说的方法数包含用到的框架, ...

  9. Android 热修复方案Tinker

    转自:http://blog.csdn.net/l2show/article/details/53925543 Android 热修复方案Tinker(一) Application改造 Android ...

随机推荐

  1. 更新日志 - fir.im 回归,上线 Android Studio 插件

    上周 fir.im 经历了一场前所未有的挑战,因为自查应用网站暂停,在事情发生4天内我们完成了自查,fir.im 正式回归.煎熬的 98 个小时,感谢开发者与用户对我们的信任和支持. 使用注意: 禁止 ...

  2. HTML+CSS纯干货就业前基础到精通系统学习2016/9/3

    1:HTML纯干货学习后的达到的效果 (1):会使用HTML的基本结构,创建网页 (2):会使用文本字体相关标签,实现文字修饰和布局 (3):会使用图像.超链接相关标签,实现图文并茂的页面 (4):会 ...

  3. Leetcode 121 Best Time to Buy and Sell Stock 动态规划

    由于题意太长,请自己翻译,很容易懂的. 做法:从前向后遍历数组,记录当前出现过的最低价格,作为买入价格,并计算以当天价格出售的收益,作为可能的最大收益,整个遍历过程中,出现过的最大收益就是所求.动态规 ...

  4. RUF MVC5 Repositories Framework Generator代码生成工具介绍和使用

    RUF MVC5 Repositories Framework Generator代码生成工具介绍和使用 功能介绍 这个项目经过了大半年的持续更新到目前的阶段基本稳定 所有源代码都是开源的,在gith ...

  5. 关于mysql备份说明

    #mysqlpump压缩备份vs数据库 三个并发线程备份,消耗时间:222smysqlpump -uzjy -p -h192.168.123.70 --single-transaction --def ...

  6. XsdGen:通过自定义Attribute与反射自动生成XSD

    前言 系统之间的数据交互往往需要事先定义一些契约,在WCF中我们需要先编写XSD文件,然后通过自动代码生成工具自动生成C#对象.对于刚刚接触契约的人来说,掌握XMLSpy之类的软件之后确实比手写XML ...

  7. TStringList中AddObject使用

    结构体定义 PYpType=^TYpType; TYpType=record    yfcode:string;    ypcode:string;    YpUnitPrice:Currency;  ...

  8. PHP ERROR : Call to undefined function curl_init()

    在使用PHP 的Curl方法时出现了以下错误 可能的解决办法: 在php.ini 中确保 启用了php_curl.dll组件 确保PHP版本 (PHP 4 >= 4.0.2, PHP 5, PH ...

  9. 通过Web.config实现301重定向

    通过Web.config实现301重定向 IIS7以上可以通过修改Web.config实现IIS设置 现在我们通过Web.config实现301重定向 <system.webServer> ...

  10. C# HttpWebRequest 绝技 根据URL地址获取网页信息

    如果要使用中间的方法的话,可以访问我的帮助类完全免费开源:C# HttpHelper,帮助类,真正的Httprequest请求时无视编码,无视证书,无视Cookie,网页抓取 1.第一招,根据URL地 ...