未经博主同意，不得转载该篇文章
虚拟机概要
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由于是采用JIT及时编译，因此App在第一次被打开的时候会进行dexopt操作而导致启动较慢。
函数执行流程
PackageManagerService是用来管理应用安装，卸载，优化等工作的系统服务。和PMS的各种操作最终会通过Java层的Installer—>InstallerConnection—>Socket通信到native的installd.c服务（这个套路在黑域中也有用到）。
InstallerConnection.connect()：
InstallerConnection.dexopt()：
最终会调用到dalvik/dexopt/OptMain.cpp
Dex文件的解析
虚拟机需要访问到可读的Dex数据来进行类加载。因此我们需要将dex文件解析成DexFile的内存中的数据结构。其解析过程实则是将DexFile数据结构中的各个成员变量与Dex文件的各个数据部分相关联。
DexFile的结构体：
需要注意的是这一步是在Dex文件优化之后，所以从这里开始提到的Dex文件都是Odex文件。具体的解析过程不叙述。接下来的过程就是要从DexFile中加载指定的类，并将其装入虚拟机的运行时环境中。
运行时数据装载
到这里，我们需要抽象出另一个数据结构——ClassObject。我们到这里可以梳理一下流程：
至于ClassObject的数据结构，特别的长，有兴趣的同学可以自己去源码看看。位置在 dalvik\vm\native\oo\Object.h中。
重点！类加载Java到Native，揭秘unexpectedDEX异常
到这里，我们可以来一次从Java层的类加载到Native层的类加载调用流程整个分析了。如果不熟悉Android Java层类加载机制的可以看这篇博客：Android动态类记载
首先，众所周知，DexClassLoder和PathClassLoder是我们见的比较多的类。区别就在于前者可以加载任意路径下的.jar或者.apk，而后者只能加载默认路径下的dex文件，即/data/dalvik-cache。然后两者都继承自BaseDexClassLoader。那这个区别的原因是什么呢？其实很简单：
不用解释都知道了，后者的构造函数不能设置Odex文件的路径，因此一般用作系统类（其实最终是BootClassLoader加载的）和应用类。前者可以动态的设置Odex路径，所以经常在插件化中被使用。
两者其实就是一个空壳，真正的加载函数都是调用自BaseDexClassLoader的父类ClassLoader的loadClass函数：
可以看到，先调用了findLoadedClass()方法：
先判断虚拟机是否已经加载了这个class，如果加载了就会直接返回。这也是为什么dex插桩流派的热修复必须要应用重启才能修复，因为一旦虚拟机加载了某个类，就不会重新再加载。
再看到后面，先调用了parent的loadClass()函数，如果为空才会调用自己的findClass()函数。对，没错！优雅的双亲委派机制（责任链）以及模版方法的设计模式。Android建议我们不要重写loadClass()方法，去重写findClass()方法，就是为了遵循这个机制和生态。因此我们继续跟踪BaseDexClassLoader的findClass()方法：
看到会调用DexPathList的findClass()方法，而这个DexList其实内部维护着一个DexFile的集合。继续跟踪：
可以看到，就是简单的遍历DexFile集合，然后去轮询Class。其实熟悉热修复的同学看到这里可以说是很轻松的，因为Q空的插桩，微信的全量替换等之热修复技术都是在这块做文章。所以继续追踪DexFile中去，这个其实就是前文提到的了：
额，其实没什么内容，但是敏感的察觉到，我们要进入到逼气十足的Native层了！defineClassNative(name, loader, cookie);。如果你的手上有Dalvik的源码，可以和我一起深入进去。这个函数在vm\native\dalivk_system_DexFile.cpp中的Dalvik_dalvik_system_DexFile_defineClass函数里。酷酷的。。：
这里只截取了部分，其实很简单先调用dvmGetRawDexFileDex或者dvmGetJarFileDex（如果是jar包）方法去给指向DexFile的指针赋值（其实DexFile是DvmDex的一个成员变量），然后将这个指针传递进dvmDefineClass()函数，而这个函数最终调用了findClassNoInit()函数：
findClassNoInit()方法是重头戏，里面先判断是否已经加载，如果没有加载会继续进行加载，通过dexFindClass()方法，返回一个DexClassDef数据结构，这个数据结构是为了方便快速定位类在Dex中的位置，然后最终通过loadClassFromDex()方法给ClassObject指针赋值：
而loadClassFromDex()方法的源码看起来比较乏味，直接总结一下：
- 为ClassObject申请内存
- 设置字段信息
- 为超类建立索引
- 加载类接口
- 加载类字段
- 加载类方法
自此，我们仅仅完成了类加载的加载阶段。类加载实际上还有很多步骤。后面会对ClassObject进行进一步的加工，后面紧接着调用了dvmLinkClass()方法进行Prepare and resolve，主要将符号引用转换成为直接引用，在其中会进一步调用dvmResolveClass()方法，而这个方法实际上是在解析当前被加载类的父类以及接口：
这里只截取了解析父类的部分，接口部分类似。可以看到，加载完了之后，就会将这个符号引用转换为直接引用，并对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。表明这个变量在后续代码中很重要。继续下去：
很好，终于看到了
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()函数找到了设置的逻辑：
而这个函数的目的就是验证并优化Dex文件中的所有类，也正是在这里的验证过程，可能会给类打上CLASS_ISPREVERIFIED的Flag。
针对以上分析的三个点，我们可以在热修复中做出不同的技术方案：
- 我的前东家手Q的QFix：通过native修改fromUnverifiedConstant变量
- QQ空间：通过给每一个类引入一个单独Dex中的类来避免CLASS_ISPREVERIFIED被设置
- 微信Tinker：通过全量Dex替换来避免pDvmDex不同
结束语
最近刚离职回学校，买了好几本新书准备啃一啃，充实一下自己的技术栈。近几天在研究Dalvik的源码和机制，发现很多以前看似虚无缥缈的东西，其实都在源码可以一探究竟，这种感觉真是太棒了。
