Android 虚拟机与类加载机制

1.虚拟机

JVM与Dalvik

image.png

基于寄存器：基于虚拟寄存器来进行操作，虚拟寄存器相当于操作数栈与局部变量表。
基于栈的：基于栈的虚拟机通过操作数栈进行所有操作。

基于寄存器的虚拟机

image.png

从中能看出，dalvik虚拟机的栈中的栈帧里，是没有局部变量表和操作数栈的，他使用了虚拟寄存器来替代了这俩。

寄存器

image.png

ART与Dalvik

image.png

ART与Dalvik都是基于寄存器的虚拟机
Dalvik是解释执行结合JIT执行
ART是4.4引入，5.0默认的虚拟机，就可以看作是Dalvik的升级版本。他执行的是本地机器码。

ART运行所需的机器码从哪来？

image.png

AOT与JIT是相对的概念，一个是运行时编译，一个是安装的时候预先编译，使用的是dex2oat工具。
所以在5.0 6.0系统时，Android安装apk会很慢，其中就因为有了这个过程。
但是在7.0及其网上，却又没那么慢了，因为后续改了

Android N的运作方式

image.png

为何经过JIT编译之后还要进行AOT过程
因为经过JIT编译好机器码之后，是一些临时的，不是持久的，记录到配置文件的，也不是代码，是一些代码到描述信息。不是可以直接执行到代码，它记录的只是代码到信息。JIT编译后的，只是针对这一次运行才有效，所以后续还要有AOT过程。
Dalvik的odex本质还是dex，而ART的odex，是机器码了

java启动VM的过程
zygote-->fork出一个进程--》里面的java代码启动--》VM

2.类加载机制

image.png

其中，SecureClassLoader一般没用（在 Android里）
InMemoryDexClassLoader 是8.0出来的一个类加载器。

image.png

比如Activity这个类，就是framework层的，是手机里面的类
要注意，AppcompatActivity这个类不是手机里面的，对手机系统来说，他是你在gradle里引用的第三方的类。只不过他是Android官方开发的一个类，它是PathClassLoader加载的。
直接在代码中调用getclassloader（）获取的是上下文的，是整个程序的classloader，是pathclassloader。

需要注意的是，pathclassloader内的parent是BootClassLoader，而不是BaseDexClassLoader，这个parent是他内部这个对象的一个成员量，而不是指这个类的父类

pathclassloader貌似是在ActivityThread类里初始化的

为什么要有双亲委托机制

image.png

classloader中相关属性类的关系

image.png

为何要用dexpathlist来承载，因为传入的地址不见的就一个包含dex的文件（apk等），还可能有多个，所以要用list来承载，然后内部会通过：分隔符分割出list集合，如果目录下有俩，那么list长度就是2，每个对象里还有一个element数组，数组的每个元素都是一个dex

热修复插入补丁后杀掉进程重新启动还会管用吗

不管用了，所以最好在application的最早方法里attachBaseContext去进行热修复
这种热修复的前提，这个类没有被加载过，否则因为双亲委托，就会有缓存，就不会重新加载了。所以要在用这个类之前就修复掉，否则就没办法修复了。

要想插入到这个数组中，要用到什么技术？----反射

热修复流程

image.png

注意，Android Q （10.0）以及之后，应用默认情况下只能看到本应用专有的目录以及特定类型的媒体，如下图

image.png

所以需要放到特定的目录下，或者进行如下配置

image.png

通过类加载方式实现的热修复，没法修复N以及之上系统通过AOT编译为机器码的类，因为art文件在直接都相当于加载近classloader里了，相当于有缓存了，所以通过在application里反射类加载这种方式实现都热修复，是没办法修复这个情况的
Tinker的实现方式是通过自定义一个ClassLoader替换系统创建的PathClassLoader，这样PathClassLoader里的缓存也就没了