-
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 加载的。
class Class<T> {
...
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，不过二者都并没有复写findClass方法
public class DexClassLoader extends BaseDexClassLoader {
//dexPath：dex文件以及包含dex的apk文件或jar文件的路径，多个路径用文件分隔符,默认分隔符，“:”
//optimizedDirectory：dex文件进行优化后所生成的dex文件的路径，8.0之后已经被废弃，因此8.0之后DexClassLoader和PathClassLoader一模一样
//librarySearchPath：所使用到的c/c++库存放的路径
//parent：保留java中的classloader的委托机制
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);
}
}
librarySearchPath：加载ndk文件的目录，so的文件目录
可以看到两者唯一的区别在于：创建DexClassLoader需要传递一个optimizedDirectory参数，并且会将其创建为File对象传给super，而PathClassLoader则直接给到null。因此两者都可以加载指定的dex，以及jar、zip、apk中的classes.dex
odex文件的路径就是optimizedDirectory。
PathClassLoader pathClassLoader = new PathClassLoader("/sdcard/xx.dex", getClassLoader());
File dexOutputDir = context.getCodeCacheDir();
DexClassLoader dexClassLoader = new DexClassLoader("/sdcard/xx.dex",dexOutputDir.getAbsolutePath(), null,getClassLoader());
其实,optimizedDirectory参数就是dexopt的产出目录(odex)。那PathClassLoader创建时，这个目录为null，就意味着不进行dexopt？并不是，optimizedDirectory为null时的默认路径为：/data/dalvik-cache。optimizedDirectory必须是私有目录(即以data/data目录开头的)，不能是sd的目录
在API 26源码中，将DexClassLoader的optimizedDirectory标记为了 deprecated 弃用，实现也变为了：
public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) { super(dexPath, null, librarySearchPath, parent); }…和PathClassLoader一摸一样了！
findClass
可以看到在所有父ClassLoader无法加载Class时，则会调用自己的findClass方法。findClass在ClassLoader中的定义为:
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
其实任何ClassLoader子类，都可以重写loadClass与findClass。一般如果你不想使用双亲委托，则重写loadClass修改其实现。而重写findClass则表示在双亲委托下，父ClassLoader都找不到Class的情况下，定义自己如何去查找一个Class。
而我们的PathClassLoader会自己负责加载MainActivity这样的程序中自己编写的类，利用双亲委托父ClassLoader加载Framework中的Activity。说明PathClassLoader并没有重写loadClass，因此我们可以来看看PathClassLoader中的 findClass 是如何实现的。
public BaseDexClassLoader(String dexPath, File optimizedDirectory,String
librarySearchPath, ClassLoader parent) {
super(parent);
this.pathList = new DexPathList(this, dexPath, librarySearchPath,
optimizedDirectory);
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
//查找指定的class
Class c = pathList.findClass(name, suppressedExceptions);
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中查找class。继续查看DexPathList
public DexPathList(ClassLoader definingContext, String dexPath,
String librarySearchPath, File optimizedDirectory) {
//.........
// splitDexPath 实现为返回 List<File>.add(dexPath)
// makeDexElements 会去 List<File>.add(dexPath) 中使用DexFile加载dex文件返回 Element数组
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
suppressedExceptions, definingContext);
//.........
}
public Class findClass(String name, List<Throwable> suppressed) {
//从element中获得代表Dex的 DexFile
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
//查找class
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
热修复
PathClassLoader中存在一个Element数组，Element类中存在一个dexFile成员表示dex文件，即：APK中有X个dex，则Element数组就有X个元素。
在PathClassLoader中的Element数组为：[patch.dex , classes.dex , classes2.dex]。如果存在Key.class位于patch.dex与classes2.dex中都存在一份，当进行类查找时，循环获得dexElements中的DexFile，查找到了Key.class则立即返回，不会再管后续的element中的DexFile是否能加载到Key.class了。
因此实际上，一种热修复实现可以将出现Bug的class单独的制作一份fix.dex文件(补丁包)，然后在程序启动时，从服务器下载fix.dex保存到某个路径，再通过fix.dex的文件路径，用其创建Element对象，然后将这个Element对象插入到我们程序的类加载器PathClassLoader的pathList中的dexElements数组头部。这样在加载出现Bug的class时会优先加载fix.dex中的修复类，从而解决Bug。
注意：热修复的类必须是没有被加载过的。如果类已经被加载了，那热修复就没有什么意义的了，时间已经迟了。
热修复的方式不止这一种，并且如果要完整实现此种热修复可能还需要注意一些其他的问题(如：反射兼容)。
双亲委托机制
某个类加载器在加载类时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务或者没有父类加载器时，才自己去加载。
- 加载.class文件时，以递归的形式逐级向上委托给父加载器parentClassLoader去加载，如果加载过了，就不用再加载一遍。
- 如果父加载器也没有加载过，则继续委托给父加载器去加载，一直到这条链路的顶级，顶级classloader判断如果没加载过，则尝试加载，加载失败，则逐级向下交还调用者来加载。说到底，双亲委派的核心机制就是递归。
public abstract class ClassLoader {
protected ClassLoader(ClassLoader parent) {
this(checkCreateClassLoader(), parent);
}
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
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.
c = findClass(name);
}
}
return c;
}
}
-
双亲委派的作用
- 防止同一个class文件重复加载
- 对于任意一个类确保在虚拟机中的唯一性。由加载它的类加载器和这个类的全类名一同确立其在jvm中的唯一性
- 保证系统类的class文件不被篡改
Class文件加载
类的加载是指将类的class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区的数据结构，并且提供了访问方法区内的数据结构的方法。
- 通过Class.forName方法动态加载
- 通过ClassLoader.loadClass()方法动态加载
类加载分为三个步骤：1.装载(Load) 2.链接(Link) 3.初始化(Init)
-
1.装载（load）查找并加载类的二进制数据（查找并导入Class文件）
- 通过一个类的全限定名来获取其定义的二进制字节流
- 将这个字节流转化为方法区的运行时数据结构
- 在Java堆中生成一个代表这个类的Class对象，作为对方法区中这些数据的访问入口
-
2.链接
-
验证：确保被加载的类的正确性
- 文件格式验证：验证字节流是否符合class文件格式的规范；例如：主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
- 元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范的要求；例如，这个类是否有父类，除了Object之外。
- 字节码验证：通过数据流和控制流分析，确定程序语义是合法的。
-
准备：为类的静态变量分配内存，并将其初始化为默认值
- 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在java堆中。这也是为什么不能在静态方法中访问非静态变量的原因。
- 这里所设置的初始值通常情况下是数据类型默认的零值（如0，0L，null，false等），而不是被在java代码中显式赋予的值。
-
解析：把类中的符号引用转换为直接引用
- 解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类、接口、字段、类方法、接口方法、方法类型。符号引用就是一组符号来描述目标，可以是任何字面量。直接引用就是直接指向目标的内存地址指针。
- 解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类、接口、字段、类方法、接口方法、方法类型。符号引用就是一组符号来描述目标，可以是任何字面量。直接引用就是直接指向目标的内存地址指针。
-
-
3.初始化：执行类的方法，对类的静态变量，静态代码块执行初始化操作(不是必须的)，只有下面这几种方式才会触发类的初始化。文章来源：https://www.toymoban.com/news/detail-674741.html
- 创建类的实例，也就是new一个对象
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射Class.forName(“xxx.xxx”)
- 初始化一个类的子类（会首先初始化子类的父类）
- jvm启动时标明的启动类，即文件名和类名相同的那个类
class.forname和classloader.loadclass 有何不同
Class.forName()加载的类会被初始化，类中的静态成员变量会被初始化，静态代码块会被执行通过ClassLoader.loadClass加载的类不进行解析操作，不进行解析操作就意味着初始化也不会进行，那么其类的静态参数就不会初始化，静态代码块也不会被执行。文章来源地址https://www.toymoban.com/news/detail-674741.html
到了这里，关于Android 热修复核心原理的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
