Dalvik类加载机制以及unexpectedDEX异常的避免

未经博主同意，不得转载该篇文章

虚拟机概要

Android在5.0之前使用的是dalvik虚拟机，使用的是纯JIT编译。在android4.4提出了art虚拟机，使用的是AOT编译，并在android5.0完全取代dalvik。但是在android7.0采用了JIT，AOT，解释的混合编译模式。

不论研究什么，都要从最原始的，最基础的东西都是看起。这里只说明dalvik的部分，涉及到dalvik虚拟机的源码。

至于art和dalvik，JIT和AOT的区别，优化，不是本文的重点。传送门：ART 和 Dalvik

类加载整体流程

对dex文件进行验证并优化，并产出Odex文件
对Odex文件进行解析，产出DexFile数据结构，即将文件形式的数据转换成内存中虚拟机可达的数据（如果研究过android的ClassLoader源码，肯定对DexFile不陌生）
对指定的类进行加载，在DexFile中提取对应类的字节码，产出ClassObject数据结构

Dex文件的优化

概要

Dalivk中，dex的优化使用的是dexopt，将dex文件优化为Odex文件，最终提交给下一步的加载过程。而不是像art的dex2aot一样，dex2aot是直接将全部的dex文件编译为native code存储。Odex文件的本质只是在原dex文件的基础上进行优化，并生成.Odex文件进行存储，以提高dalvik虚拟机运行的高效性和安全性。需要注意的是整个dex的优化过程都是在一个新进程中进行的。

重要的优化点如下：

建立dex的类索引表——使虚拟机快速find dex中某个类的地址
寄存器的内存映射——减少odex->DexFile的内存映射操作
添加依赖库信息——添加dex需要使用的本地函数库
dex中字节码的替换——比如类似编译中的内联优化

Dex和Odex文件结构对比图

dalvik_1.png

Dalvik由于是采用JIT及时编译，因此App在第一次被打开的时候会进行dexopt操作而导致启动较慢。

函数执行流程

PackageManagerService是用来管理应用安装，卸载，优化等工作的系统服务。和PMS的各种操作最终会通过Java层的Installer—>InstallerConnection—>Socket通信到native的installd.c服务（这个套路在黑域中也有用到）。

InstallerConnection.connect()：

dalvik_2.png

InstallerConnection.dexopt()：

dalvik_3.png

最终会调用到dalvik/dexopt/OptMain.cpp

dalvik_4.png

Dex文件的解析

虚拟机需要访问到可读的Dex数据来进行类加载。因此我们需要将dex文件解析成DexFile的内存中的数据结构。其解析过程实则是将DexFile数据结构中的各个成员变量与Dex文件的各个数据部分相关联。

DexFile的结构体：

dalvik_5.png

需要注意的是这一步是在Dex文件优化之后，所以从这里开始提到的Dex文件都是Odex文件。具体的解析过程不叙述。接下来的过程就是要从DexFile中加载指定的类，并将其装入虚拟机的运行时环境中。

运行时数据装载

到这里，我们需要抽象出另一个数据结构——ClassObject。我们到这里可以梳理一下流程：

dalvik_6.png

至于ClassObject的数据结构，特别的长，有兴趣的同学可以自己去源码看看。位置在 dalvik\vm\native\oo\Object.h中。

重点！类加载Java到Native，揭秘unexpectedDEX异常

到这里，我们可以来一次从Java层的类加载到Native层的类加载调用流程整个分析了。如果不熟悉Android Java层类加载机制的可以看这篇博客：Android动态类记载

首先，众所周知，DexClassLoder和PathClassLoder是我们见的比较多的类。区别就在于前者可以加载任意路径下的.jar或者.apk，而后者只能加载默认路径下的dex文件，即/data/dalvik-cache。然后两者都继承自BaseDexClassLoader。那这个区别的原因是什么呢？其实很简单：

dalvik_7.png

dalvik_8.png

不用解释都知道了，后者的构造函数不能设置Odex文件的路径，因此一般用作系统类（其实最终是BootClassLoader加载的）和应用类。前者可以动态的设置Odex路径，所以经常在插件化中被使用。

两者其实就是一个空壳，真正的加载函数都是调用自BaseDexClassLoader的父类ClassLoader的loadClass函数：

dalvik_9.png

可以看到，先调用了findLoadedClass()方法：

dalvik_10.png

先判断虚拟机是否已经加载了这个class，如果加载了就会直接返回。这也是为什么dex插桩流派的热修复必须要应用重启才能修复，因为一旦虚拟机加载了某个类，就不会重新再加载。

再看到后面，先调用了parent的loadClass()函数，如果为空才会调用自己的findClass()函数。对，没错！优雅的双亲委派机制（责任链）以及模版方法的设计模式。Android建议我们不要重写loadClass()方法，去重写findClass()方法，就是为了遵循这个机制和生态。因此我们继续跟踪BaseDexClassLoader的findClass()方法：

dalvik_11.png

看到会调用DexPathList的findClass()方法，而这个DexList其实内部维护着一个DexFile的集合。继续跟踪：

dalvik_12.png

可以看到，就是简单的遍历DexFile集合，然后去轮询Class。其实熟悉热修复的同学看到这里可以说是很轻松的，因为Q空的插桩，微信的全量替换等之热修复技术都是在这块做文章。所以继续追踪DexFile中去，这个其实就是前文提到的了：

dalvik_13.png

额，其实没什么内容，但是敏感的察觉到，我们要进入到逼气十足的Native层了！defineClassNative(name, loader, cookie);。如果你的手上有Dalvik的源码，可以和我一起深入进去。这个函数在vm\native\dalivk_system_DexFile.cpp中的Dalvik_dalvik_system_DexFile_defineClass函数里。酷酷的。。：

dalvik_14.png

这里只截取了部分，其实很简单先调用dvmGetRawDexFileDex或者dvmGetJarFileDex（如果是jar包）方法去给指向DexFile的指针赋值（其实DexFile是DvmDex的一个成员变量），然后将这个指针传递进dvmDefineClass()函数，而这个函数最终调用了findClassNoInit()函数：

dalvik_15.png

findClassNoInit()方法是重头戏，里面先判断是否已经加载，如果没有加载会继续进行加载，通过dexFindClass()方法，返回一个DexClassDef数据结构，这个数据结构是为了方便快速定位类在Dex中的位置，然后最终通过loadClassFromDex()方法给ClassObject指针赋值：

dalvik_16.png

而loadClassFromDex()方法的源码看起来比较乏味，直接总结一下：

为ClassObject申请内存
设置字段信息
为超类建立索引
加载类接口
加载类字段
加载类方法

自此，我们仅仅完成了类加载的加载阶段。类加载实际上还有很多步骤。后面会对ClassObject进行进一步的加工，后面紧接着调用了dvmLinkClass()方法进行Prepare and resolve，主要将符号引用转换成为直接引用，在其中会进一步调用dvmResolveClass()方法，而这个方法实际上是在解析当前被加载类的父类以及接口：

dalvik_17.png

这里只截取了解析父类的部分，接口部分类似。可以看到，加载完了之后，就会将这个符号引用转换为直接引用，并对GC可见。而这个dvmResolveClass()方法就是unexpected DEX异常触发的地方，先来看两段dvmResolveClass()方法的注释：

* Because the DexTypeId is associated with the referring class' DEX file,

* we may have to resolve the same class more than once if it's referred

* to from classes in multiple DEX files. This is a necessary property for

* DEX files associated with different class loaders.

大意就是被引用的类可能是别的Dex文件里的，所以我们可能会因为某个类被另一个Dex文件中的类给引用而导致重复解析这个类。表明Dalvik会使用一种机制来避免这种现象，后面会提到。

* "fromUnverifiedConstant" should only be set if this call is the direct

* result of executing a "const-class" or "instance-of" instruction, which

* use class constants not resolved by the bytecode verifier.

大意就是如果我们通过"const-class"（通过类型索引获取一个类的引用赋值给寄存器，比如直接引用XX.class）或 "instance-of"（判断寄存器中对象的引用是否是指定类型）（均为两者Dalvik虚拟机的指令）指令去引用一个类，那么fromUnverifiedConstant变量会被set为True。表明这个变量在后续代码中很重要。继续下去：

dalvik_18.png

很好，终于看到了

dvmThrowIllegalAccessError(
                    "Class ref in pre-verified class resolved to unexpected "
                    "implementation");

并且很清晰的看到了触发unexpectedDEX异常的四个条件：

fromUnverifiedConstant为False
被解析的类，设置了CLASS_ISPREVERIFIED
referrer->pDvmDex != resClassCheck->pDvmDex
被引用类的类加载器不是Null

我们重点看前三个条件：

fromUnverifiedConstant	如果变量是被"const-class" or "instance-of"指令加载进来就是True否则为False
CLASS_ISPREVERIFIED	在Dex优化过程中引用其他Dex文件的类，被加载类不会设置该状态，否则会设置该状态
pDvmDex	如果被解析类和被引用类不在同一个Dex文件中就会触发异常

我们重点看一下CLASS_ISPREVERIFIED被设置的代码。前文有提到Dex文件的优化是在dalvik/dexopt/OptMain.cpp的extractAndProcessZip()作为入口开始的。通过我一步步的跟踪，最终在dalvik\vm\analysis\DexPrepare.cpp中的verifyAndOptimizeClasses()函数找到了设置的逻辑：

dalvik_19.png

而这个函数的目的就是验证并优化Dex文件中的所有类，也正是在这里的验证过程，可能会给类打上CLASS_ISPREVERIFIED的Flag。

针对以上分析的三个点，我们可以在热修复中做出不同的技术方案：

我的前东家手Q的QFix：通过native修改fromUnverifiedConstant变量
QQ空间：通过给每一个类引入一个单独Dex中的类来避免CLASS_ISPREVERIFIED被设置
微信Tinker：通过全量Dex替换来避免pDvmDex不同

结束语

最近刚离职回学校，买了好几本新书准备啃一啃，充实一下自己的技术栈。近几天在研究Dalvik的源码和机制，发现很多以前看似虚无缥缈的东西，其实都在源码可以一探究竟，这种感觉真是太棒了。