前言
在上一篇文章中【JVM入门食用指南-03】JVM垃圾回收器以及性能调优[1]，对垃圾回收器以及JVM性能调优进行了叙述,并对JVM中CMS垃圾回收器进行了重点阐述。通过之前在JVM中的铺垫，本文我们回到Android中，本文我们主要对 Android虚拟机和类加载机制进行叙述，加深对 Android 的理解。
即将学会
- ART 和 Dalvik
- Android 类加载流程
- 热修复实现原理
ART 与 Dalvik
JVM 与 DVM
JVM 是我们的 Java 虚拟机，而我们的Android应用运行在 Dalvik/ART 虚拟机上的。每一个应用对应一个 Dalvik 虚拟机，虽然 Dalvik 虚拟机也算 Java 虚拟机，不过执行的不是.class文件，而是dex文件。
这里对上述名词进行一些叙述
虚拟机分类
基于栈的虚拟机 每一个运行的线程，都有一个独立的栈，栈中记录了方法调用的历史，每一个方法的调用，都对应一个栈帧，并且将栈帧压入栈中，最顶部的栈帧为当前栈帧，既 当前执行的方法，基于栈帧 与 操作数栈进行所有操作。
寄存器 CPU的组成部分，寄存器是有限存储容量的高速存储容器（计算机中各级存储速度 寄存器-> 一级缓存->二级缓存 -> 内存 -> 硬盘），可以用来管理指令、数据的地址。
基于寄存器的虚拟机 （模拟寄存器的操作流程）
基于寄存器的虚拟机中没有操作数栈，不过有很多虚拟寄存器，类似操作数栈，这些寄存器也存放在运行时栈中，本质上就是一个数组，与JVM相似，在Dalvik 虚拟机中每个线程都有自己的PC 和 调用栈，方法调用的活动记录以帧为单位保存在调用栈上。
不同虚拟机流程
我们对比一下 基于栈的流程 和 基于寄存器的流程
JVM流程分析参考之前文章分析,通常需要经过以下操作
- 如将栈顶某类型值存入局部变量某处
- 将局部变量中某处某类型常量压入操作数栈
- 执行相关指令
DVM 中，直接依据指令，将某类型值存入虚拟寄存器中，相关的操作也依据指令在虚拟寄存器中通过CPU处理，将处理结果返回虚拟寄存器（省掉了基于栈的流程中局部变量与操作数栈中数据的流动）
ART 与 Dalvik 区别
ART 和 Dalvik 都是基于寄存器的虚拟机
Dalvik 执行 dex字节码，解释执行，在Android2.2 开始，支持即时编译，既选择程序中经常执行的代码（又称热点代码），进行编译和优化 减少了JVM中解释的流程。
ART虚拟机 （Android4.4） 直接跑机器码，不进行字节码解释。Android的运行时从Dalvik 无影响过渡ART，因为并不用开发者将应用直接编译成目标机器码，APk依旧是一个包含dex字节码的文件。
为什么APK依旧是包含dex字节码的文件，而ART和 Dalvik的执行方式不一样?
这里ART直接跑字节码，而Dalvik进行解释执行，并在2.2引入JIT，但是都是dex文件。
因为APK文件需要在Android系统中运行，需要进行安装，这个时候，经过虚拟机，会对dex进行优化，Dalvik中，会将dex字节码进行优化生成odex文件，而ART 会将 dex字节码翻译为本地机器码（引入了预先编译机制 Ahead of Time），安装时，ART使用设备自带的dex2oat工具对应用进行编译。dex中的字节码被编译成本地机器码，这也是为什么我们安装的时候比较慢。
不过后面从Android O 开始，安装速度变快了，因为这个时候采用混合编译了，JIT、AOT、和字节码解释。 当应用首次安装时，不进行AOT编译，运行过程中采用解释执行，并将程序中经常要执行的代码进行即时编译（JIT），并将JIT编译后的方法记录到Profile配置文件，当设备闲置时，利用编译守护进程，依据Profile文件对常用文件进行AOT编译（生成.art文件），以便下次运行时直接使用。如果下次程序运行，将检测该文件并解析出机器码中文件中的类信息，加载到ClassLoader中。
ClassLoader 及 类加载流程
ClassLoader
每一个Java程序都是有一个或多个class文件组成，在程序运行时，需要将class文件加载到JVM中才可以使用，而加载class文件的是Java的类加载机制，ClassLoader加载class文件提供程序运行时使用，每个Class对象内部都有一个classLoader字段来标识由何种classLoader加载。
ClassLoader 类 以及 类结构
- ClassLoader
- BootClassLoader 用于加载Android Framework 层 Class文件（像String.Class）
- PathClassLoader 继承自ClassLoader 用于Android应用程序加载类
类加载流程
PathClassLoader
下面我们分析一下PathClassLoader类来分析类加载流程
/**
* Loads the class with the specified <a href="#name">binary name</a>. The
* default implementation of this method searches for classes in the
*/
// Android-removed: Remove references to getClassLoadingLock
// Remove perf counters.
//
// <p> Unless overridden, this method synchronizes on the result of
// {@link #getClassLoadingLock <tt>getClassLoadingLock</tt>} method
// during the entire class loading process.
//
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
//找缓存，已经加载过的就不会被加载了
//class文件需要转换为class对象 耗时操作
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
//没有缓存进if
if (c == null) {
try {
//如果该类下的parent对象实例不为空，利用该parent对象加载相关类
//该对象指向 BootClassLoader 如下图所示
if (parent != null) {
c = parent.loadClass(name, false);
} else {
//parent 为空，返回空
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
//如果 parent（BootstrapClass）中加载不到该类
//则 调用自身findClass去加载类(PathClassLoader)
c = findClass(name);
}
}
//有缓存直接返回
return c;
}
/**
* Returns a class loaded by the bootstrap class loader;
* or return null if not found.
*/
private Class<?> findBootstrapClassOrNull(String name)
{
return null;
}我们可以通过上述代码分析 和 PathClassLoader类结构图得到该类的loadClass流程
那么为什么我们ClassLoader中要进行这样的设计呢 ？
首先，这个parent的目的在于实现类加载的双亲委托，首先加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，则成功返回，只有父类加载器无法完成此加载任务时，才自己去完成加载。 而实现这种机制，可以达到以下效果
- 避免重复加载，当parent对应的加载器已经加载了该类的时候，就没有必有当前classloader再加载一次,直接在parent中的缓存找。
- 安全考虑，防止核心API被篡改，像自己定义一个String.java 这个时候classloader会先加载framework中的String.java（加载只要全限定名一样，可以伪造构建和系统类一样的全限定名）
上面我们分析了它的设计思想，回归加载过程中，这里用到了findClass(name) 方法
findClass(name) 又做了什么？
我们可以通过查看其自身和父类寻找findClass方法，通过查看
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
//通过pathList 去找 相关 类，而pathList 是 DexPathList 是 final 的
Class c = pathList.findClass(name, suppressedExceptions);
//知道了 返回 Class相关实例对象，没找到抛异常 关键在上一行代码
if (c == null) {
ClassNotFoundException cnfe = new ClassNotFoundException(
"Didn't find class \"" + name + "\" on path: " + pathList);
for (Throwable t : suppressedExceptions) {
cnfe.addSuppressed(t);
}
throw cnfe;
}
return c;
}
//上述pathList 声明 是不可变的 我们去查看其赋值
private final DexPathList pathList;
//pathList 又是由什么赋值 可以看到相关使用在构造方法中
// 通过查看其构造方法，可知我们需要传入 dexPath 去 实例化 DexPathList
// 因此PathClassLoader才可以加载到程序的所有类
/**
* @hide
*/
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
String librarySearchPath, ClassLoader parent, boolean isTrusted) {
super(parent);
//我们跳去 DexPathList 看看
this.pathList = new DexPathList(this, dexPath, librarySearchPath, null, isTrusted);
if (reporter != null) {
reportClassLoaderChain();
}
}
// 我们看一下DexPathList
DexPathList(ClassLoader definingContext, String dexPath,
String librarySearchPath, File optimizedDirectory, boolean isTrusted) {
//常规 参数判空
if (definingContext == null) {
throw new NullPointerException("definingContext == null");
}
if (dexPath == null) {
throw new NullPointerException("dexPath == null");
}
if (optimizedDirectory != null) {
if (!optimizedDirectory.exists()) {
throw new IllegalArgumentException(
"optimizedDirectory doesn't exist: "
+ optimizedDirectory);
}
if (!(optimizedDirectory.canRead()
&& optimizedDirectory.canWrite())) {
throw new IllegalArgumentException(
"optimizedDirectory not readable/writable: "
+ optimizedDirectory);
}
}
this.definingContext = definingContext;
ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
// save dexPath for BaseDexClassLoader
// 这里使用到了 dexpath
// splitDexPath 将dexpath的多地址分离 , PathClassLoader 可以处理多个dex
// makeDexElements 依据dexpath生成多个dexElement
// 下面我们去看一下splitDexPath 和 makeDexElements
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
suppressedExceptions, definingContext, isTrusted);
this.nativeLibraryDirectories = splitPaths(librarySearchPath, false);
this.systemNativeLibraryDirectories =
splitPaths(System.getProperty("java.library.path"), true);
List<File> allNativeLibraryDirectories = new ArrayList<>(nativeLibraryDirectories);
allNativeLibraryDirectories.addAll(systemNativeLibraryDirectories);
this.nativeLibraryPathElements = makePathElements(allNativeLibraryDirectories);
if (suppressedExceptions.size() > 0) {
this.dexElementsSuppressedExceptions =
suppressedExceptions.toArray(new IOException[suppressedExceptions.size()]);
} else {
dexElementsSuppressedExceptions = null;
}
}
//splitDexPath 方法
private static List<File> splitDexPath(String path) {
return splitPaths(path, false);
}
/**
* Splits the given path strings into file elements using the path
* separator, combining the results and filtering out elements
* that don't exist, aren't readable, or aren't either a regular
* file or a directory (as specified). Either string may be empty
* or {@code null}, in which case it is ignored. If both strings
* are empty or {@code null}, or all elements get pruned out, then
* this returns a zero-element list.
*/
private static List<File> splitPaths(String searchPath, boolean directoriesOnly) {
List<File> result = new ArrayList<>();
if (searchPath != null) {
for (String path : searchPath.split(File.pathSeparator)) {
if (directoriesOnly) {
try {
StructStat sb = Libcore.os.stat(path);
if (!S_ISDIR(sb.st_mode)) {
continue;
}
} catch (ErrnoException ignored) {
continue;
}
}
result.add(new File(path));
}
}
return result;
}
//makePathElements 方法
private static final String zipSeparator = "!/";
private static NativeLibraryElement[] makePathElements(List<File> files) {
// 一个dex 生成一个 elements 对象
NativeLibraryElement[] elements = new NativeLibraryElement[files.size()];
int elementsPos = 0;
for (File file : files) {
String path = file.getPath();
if (path.contains(zipSeparator)) {
String split[] = path.split(zipSeparator, 2);
File zip = new File(split[0]);
String dir = split[1];
elements[elementsPos++] = new NativeLibraryElement(zip, dir);
} else if (file.isDirectory()) {
// We support directories for looking up native libraries.
elements[elementsPos++] = new NativeLibraryElement(file);
}
}
if (elementsPos != elements.length) {
elements = Arrays.copyOf(elements, elementsPos);
}
return elements;
}
这里，我们了解到了pathList这个对象为了findClass做了什么准备，现在，我们回到BaseClassLoader 中的 findClass 方法中，继续看pathList这一行代码，pathList这个实例我们已经知晓了，现在看它调用的findClass方法（和BaseClassLoader中不一样）
//在这里,我们可以看到 该方法使用到了刚才 pathList 中 dexElements数组
// 通过遍历 每一个 Element 遍历所有的dex
// DexFile dex = element.dexFile; 拿到对应的 DexFile
// dex.loadClassBinaryName(name, definingContext, suppressed);
// 再通过每个dex 的 loadClassBinaryName 去将类找出
/**
* Finds the named class in one of the dex files pointed at by
* this instance. This will find the one in the earliest listed
* path element. If the class is found but has not yet been
* defined, then this method will define it in the defining
* context that this instance was constructed with.
*
* @param name of class to find
* @param suppressed exceptions encountered whilst finding the class
* @return the named class or {@code null} if the class is not
* found in any of the dex files
*/
public Class findClass(String name, List<Throwable> suppressed) {
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
大致的类加载流程就如上所示
热修复原理
那么，通过类加载流程，我们这个时候可以在这之上进行一下热修复
当我们程序有Bug时，我们对相关类进行修改，并将修改后的类打包成补丁dex，当客户端下载时，只要让补丁包加载在类加载之前，就可以提前加载到虚拟机中，而有错误的类，因为类加载机制问题，不会重复加载，从而不会加载到错误类，进而实现修复。
热修复原理大致代码流程
//相关正常修复类打补丁包
dx --dex --output=output.dex xxx.jar
dx --dex --output=output.dex 类全限定名
在Application类中 重写 attachBaseContext 并在super后 调用 热修复
并传入Application，补丁dex文件至热修复类
//热修复类中
//1、获得classloader（PathClassLoader）
ClassLoader classLoader = application.getClassLoader();
//2\. 不同的Android 版本 ，热修复有所差异，需要对其适配 （以6.0为例）
//3\. 遍历该类及超类
Class<?> clazz = classLoader.getClass(); clazz != null; clazz = clazz.getSuperclass()
//4.通过反射 获取 pathList 属性成员
Field field = clazz.getDeclaredField("pathList");
//5.获取到pathList对象
Object dexPathList = pathListField.get(classLoader);
///将自己的补丁包转换为Element数组 参考PathClassLoader
// 得到补丁包的Element数组
// 反射拿到 makePathElements 方法
Class<?> clazz = dexPathList.getClass(); clazz != null; clazz = clazz.getSuperclass()
Method method = clazz.getDeclaredMethod("makePathElements", parameterTypes);
//反射执行方法 返回 补丁包对应的 Element数组
Object[] patchElements = (Object[]) method.invoke(dexPathList, files, optimizedDirectory,
suppressedExceptions)
//将原本的 dexElements 与 makePathElements生成的数组合并,并利用反射塞回 dexElements
//拿到 classloader中的dexelements 数组
Class<?> clazz = dexPathList.getClass(); clazz != null; clazz = clazz.getSuperclass()
Field dexElementsField = clazz.getDeclaredField("dexElements");
//old Element[]
Object[] dexElements = (Object[]) dexElementsField.get(dexPathList);
//合并后的数组
Object[] newElements = (Object[]) Array.newInstance(dexElements.getClass().getComponentType(),
dexElements.length + patchElements.length);
// 先拷贝新数组
System.arraycopy(patchElements, 0, newElements, 0, patchElements.length);
System.arraycopy(dexElements, 0, newElements, patchElements.length, dexElements.length);
//修改 classLoader中 pathList的 dexelements
dexElementsField.set(dexPathList, newElements);
上述只是依据类加载原理进而对热修复原理进行阐述的大致流程，实现热修复还需要考虑到一下兼容问题、混淆等内容。