android person类_Android前沿技术探讨：ClassLoader在热修复中的应用

Android 热修复核心原理，ClassLoader类加载

又在写bug？这句话虽然是句玩笑话，但是也正因为我们是人不是神，但也不能面面俱到，什么都考虑完美，出现bug是不可避免的。那么对于android我们出现了Bug怎么办？

早期遇到Bug我们一般会紧急发布了一个版本。然而这个Bug可能就是简简单单的一行代码，为了这一行代码，进行全量或者增量更新迭代一个版本，未免有点大材小用了。而且新版本的普及需要时间，而且如果这次的新版本又有个小问题，怎么办？

那么为了解决这一个问题，热修复出现了。

热修复，现在大家应该都不陌生。从16年开始开始，热修复技术在 Android 技术社区热了一阵子，这种不用发布新版本就可以修复线上 bug 的技术看起来非常黑科技。

本节课的目的并不在于热修复本身，主要是通过热修复这个案例熟悉其核心：类加载机制。(后续会有更详细课程讲解热修复)

ART 和 Dalvik

DVM也是实现了JVM规范的一个虚拟器，默认使用CMS垃圾回收器，但是与JVM运行 Class 字节码不同，DVM 执行 Dex(Dalvik Executable Format) ——专为 Dalvik 设计的一种压缩格式。Dex 文件是很多 .class 文件处理压缩后的产物，最终可以在 Android 运行时环境执行。

而ART(Android Runtime) 是在 Android 4.4 中引入的一个开发者选项，也是 Android 5.0 及更高版本的默认 Android 运行时。ART 和 Dalvik 都是运行 Dex 字节码的兼容运行时，因此针对 Dalvik 开发的应用也能在 ART 环境中运作。

https://source.android.google.cn/devices/tech/dalvik/gc-debug

dexopt与dexaot

• dexopt

在Dalvik中虚拟机在加载一个dex文件时，对 dex 文件 进行 验证 和 优化的操作，其对 dex 文件的优化结果变成了 odex(Optimized dex) 文件，这个文件和 dex 文件很像，只是使用了一些优化操作码。

• dex2oat

ART 预先编译机制，在安装时对 dex 文件执行dexopt优化之后再将odex进行 AOT 提前编译操作，编译为OAT(实际上是ELF文件)可执行文件(机器码)。(相比做过ODEX优化，未做过优化的DEX转换成OAT要花费更长的时间)

ClassLoader介绍

任何一个 Java 程序都是由一个或多个 class 文件组成，在程序运行时，需要将 class 文件加载到 JVM 中才可以使用，负责加载这些 class 文件的就是 Java 的类加载机制。ClassLoader 的作用简单来说就是加载 class 文件，提供给程序运行时使用。每个 Class 对象的内部都有一个 classLoader 字段来标识自己是由哪个 ClassLoader 加载的。

javaclass Class { ... private transient ClassLoader classLoader; ...}

ClassLoader是一个抽象类，而它的具体实现类主要有：

• BootClassLoader

用于加载Android Framework层class文件。

• PathClassLoader

用于Android应用程序类加载器。可以加载指定的dex，以及jar、zip、apk中的classes.dex

• DexClassLoader

用于加载指定的dex，以及jar、zip、apk中的classes.dex

很多博客里说PathClassLoader只能加载已安装的apk的dex，其实这说的应该是在dalvik虚拟机上。

但现在一般不用关心dalvik了。

 Log.e(TAG, "Activity.class 由：" + Activity.class.getClassLoader() +" 加载"); Log.e(TAG, "MainActivity.class 由：" + getClassLoader() +" 加载"); //输出： Activity.class 由：java.lang.BootClassLoader@d3052a9 加载 MainActivity.class 由：dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.enjoy.enjoyfix-1/base.apk"],nativeLibraryDirectories=[/data/app/com.enjoy.enjoyfix-1/lib/x86, /system/lib, /vendor/lib]]] 加载

它们之间的关系如下：

PathClassLoader与 DexClassLoader的共同父类是 BaseDexClassLoader。

public class DexClassLoader extends BaseDexClassLoader { public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) { super(dexPath, new File(optimizedDirectory), librarySearchPath, parent); }}public class PathClassLoader extends BaseDexClassLoader { public PathClassLoader(String dexPath, ClassLoader parent) { super(dexPath, null, null, parent); } public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent){ super(dexPath, null, librarySearchPath, parent); }}

可以看到两者唯一的区别在于：创建 DexClassLoader需要传递一个 optimizedDirectory参数，并且会将其创建为 File对象传给 super，而 PathClassLoader则直接给到null。因此两者都可以加载指定的dex，以及jar、zip、apk中的classes.dex

PathClassLoader pathClassLoader = new PathClassLoader("/sdcard/xx.dex