- Android Art/Dalvik与Java Hotspot的运作方式
- Android Art/Dalvik与Java Hotspot的区别
- Android的类加载流程
- 双亲委托机制，还有它的作用
- 基于类加载机制的HotFix
对于java来说，安装jdk以后，通过java -version 命令，可以看到当前的虚拟机是64位的HotSpot。Android使用的是Dalvik/ART虚拟机。
一、两种虚拟机的运行机制（运作方式）：
Q1：什么是解释执行？ – 边解释边执行
A1：字节码文件经过虚拟机翻译成机器码，给计算机识别的过程。这也是jvm跨平台的基础。
Jvm 执行的是.class文件，基于解释执行。Dalvik执行的是dex字节码，也是解释执行。Android 从2.2版本开始，支持Jit即时编译（Just In Time）
Q2：什么是JIT？
A2：App在运行的时候，每遇到了新类，JIT编译器会对这个类进行编译。并经过优化精简保存做上标记，下次执行到相同逻辑的代码时，就直接复用。这个JIT只针对热点代码，即使用次数多的代码。
总结1 ：Dalvik虚拟机的执行方式：解释执行 + JIT即时编译。
Dalvik的缺点：每次运行app的时候，都要执行一遍dex文件，每次编译都会花时间，虽然加入了JIT，，也不能做到一劳永逸。
基于DalviK的缺点，android 在5.0以后，摒弃了Dalvik虚拟机，使用了更加先进的ART虚拟机。ART的特点：引入了AOT技术。
AOT(Ahead of Time) : 预先编译机制，在安装时，ART使用设备自带的dex2oat工具来编译应用，将dex中的字节码编译为本地机器码。优点：一劳永逸，在安装时把dex文件通过dex2oat工具，编译成了机器码，后续执行不需要在每次翻译。缺点：安装的时间会变长。
在android N (7.0)以后，再次优化。具体的优化流程：
1、安装的时候，不再进行AOT编译，加快安装速度。在运行过程中解释执行 + 热点代码JIT执行，并且会把JIT编译的方法记录到Profile配置文件中。
2、当设备空闲时，编译守护进程会运行，根据之前记录的Profile文件，对常用的代码进行AOT编译。下次运行的时候，就是机器码直接使用了。有点类似于游戏的微端，边玩边下载 --> 边使用边编译成机器码。
二、两种虚拟机的区别。
1、Art执行的是dex文件，hotspot执行的是.class文件。
2、Art与java虚拟机执行的指令集不一样，Art的指令集是基于寄存器的，java虚拟机是基于堆栈的。
java虚拟机的内存结构：
java应用程序基于线程执行，而线程基于虚拟机栈运行。虚拟机栈的结构：
寄存器：是cpu的组成部分，是有限存储容量的部件，可以用来暂存指令、地址、数据等内容。Art/Dalvik 的虚拟机是基于寄存器的。
JVM的的栈上操作，包括数据移动，从局部变量表移动到操作数栈，再从操作数栈出栈给cpu计算，以及结果返回到局部变量表等。
Art/Dalvik 虚拟机基于寄存器，相当于是把局部变量表、操作数栈、动态连接、返回出口等jvm 虚拟机栈的各个模块进行了合并。因此对比起来，这样的好处是，减少了数据在各个模块之间移动的指令数，也减少了数据移动的时间，提高效率。
三、Android的类加载流程
虚拟机创建对象的过程（遇到new指令）：
ClassLoader:负责类加载，通过IO，把实际文件按格式转化为内存中的对象。
ClassLoader：顶层父类
BootClassLoader：主要用来加载android framework的类。（写在ClassLoader里面的类，但不是内部类）
PathClassLoader：用来加载应用程序的类。
ClassLoader加载类的主要代码：
A：findLoadedClass(name) ： 先检查下有没有加载过该类，如果有的话，就直接使用缓存里面的类（这也是HotFix的基础。）
B： if (c == null) -> c = parent.loadClass(name, false) 如果缓存里没有，先用调用parent ClassLoader去找。这里的parent变量，是指 Launcher.AppClassLoader。先去找系统里的类。这个parent是系统在构建类加载器的时候，在构造里面创建的。
//上面这个是jdk的parent,不是android的parent。
parent = getSystemClassLoader()
getSystemClassLoader() - > initSystemClassLoader() -> sun.misc.Launcher.getLauncher().getClassLoader() -> Launcher.AppClassLoader.getAppClassLoader(var1) -> new Launcher.AppClassLoader(var1x, var0)
下面是Android 的parent ClassLoader，加载步骤与Java的几乎相同，区别是parent变量所属对象不一样。
A 流向B。
parent = getSystemClassLoader()； -> SystemClassLoader.loader -> ClassLoader.createSystemClassLoader() -> new PathClassLoader(classPath, librarySearchPath, BootClassLoader.getInstance());
C： if (c ==null) -> c = findClass(name); 最后在用应用程序的classLoader的findClass方法。去寻找对应的类。 传的参数是dex文件的路径 path。
android 或者是java的这种类加载机制，也叫作双亲委托机制。整体流程来说，如上文中的A/B/C三步走，先去找缓存，看这个类有没有被加载过，如果没有再通过parent变量（BootClassLoader）去找系统的类，如果还没有找到，最后再通过自己的pathClassLoader,通过传入的dex的路径path去寻找。
双亲委托机制的好处：1、安全。防止系统核心API被篡改。2、避免重复，当父类已经加载过该类一次后，后续继续加载该类时，就去找缓存里的类，没有必要再重新加载一次。节约时间。这也是HotFix的实现基础和思路。
HotFix:基于上面的类加载机制，当程序中有一个类或者是一个模块出现问题后，把修复好的类，编译成dex文件，通过反射，给到类加载器，（里面有一个元素数组，记载已经加载过的类。）当该类经过加载，有了缓存以后，就不会再去加载有问题的类了，从而解决异常。
