1.JVM与DVM
1.概念
JVM的作用是把平台无关的.class里面的字节码翻译成平台相关的机器码，来实现跨平台。DVM就是安卓中使用的虚拟机。
Dalvik允许多个实例，每一个实例作为一个独立的linux进程执行，可以防止一个程序的崩溃导致所有程序都崩溃。
2.区别
- jvm通过解码class文件来运行程序；dvm则是dex文件。
dex文件是由多个class文件打包而成，一个dex文件方法数不能超过65535。
JVM: .java -> javac -> .class -> jar -> .jar , 架构: 堆和栈的架构.
DVM: .java -> javac -> .class -> dx.bat -> .dex , 架构: 寄存器(cpu上的一块高速缓存)。
Dalvik字节码中，变量会被复制给65536个可用寄存器中的任何一个，直接访问这些寄存器，而不是方位堆栈中的元素；
JVM字节码中，变量会被压入堆栈中进行运算；基于寄存器的方式在编译的时候花费的时间更短。这也是下面要说的。
- dvm基于寄存器架构（句柄引用），jvm基于栈架构（指针引用）
dvm基于寄存器，所以它的指令是二地址和三地址混合，指令中指明了操作数的地址；jvm基于栈，它的指令是零地址，指令的操作数对象默认是操作数栈中的几个位置。但基于寄存器的指令由于需要指定源地址和目标地址，因此需要占用更多的指令空间
dvm速度快！指令数小！寄存器存取速度比栈快的多，dvm可以根据硬件实现最大的优化，比较适合移动设备。JAVA虚拟机基于栈结构，程序在运行时虚拟机需要频繁的从栈上读取写入数据，这个过程需要更多的指令分派与内存访问次数，会耗费很多CPU时间。
这样带来的结果就是dvm的指令数相对于jvm的指令数会小很多，jvm需要多条指令而dvm可能只需要一条指令。jvm基于栈带来的好处是可以做的足够简单，真正的跨平台，保证在低硬件条件下能够正常运行。而dvm操作平台一般指明是ARM系统，所以采取的策略有所不同。需要注意的是dvm基于寄存器，但是这也是个映射关系，如果硬件没有足够的寄存器，dvm将多出来的寄存器映射到内存中。
- Dalvik可执行文件体积更小。
SDK中有个dx工具负责将JAVA字节码转换为Dalvik字节码，将所有java文件中的常量池合并为一个常量池，使得相同的字符串和常量只在DEX文件中出现一次。
运行时，共享相同的类，这样系统消耗会小很多，JVM机制中，打包后，他们都是完全独立的程序，类都是单独加载，单独运行；
3.jvm(参考)
当启动一个java程序，一个虚拟机实例也就诞生了。当该程序关闭退出，这个虚拟机实例也就随之消亡。
java内部有两种线程：守护线程和非守护线程。非守护线程就是我们所说的main方法；守护线程通常是由虚拟机自己使用，如执行垃圾回收任务的线程。Java程序也可以把它创建的任何线程标记为守护线程。只要还有非守护进行在，这个java程序也在继续进行。
每个Java虚拟机都有一个类装载子系统，它根据给定的全限定名来装入类型（类或接口）。同样，每个Java虚拟机都有一个执行引擎，它负责执行那些包含在被装载类的方法中的指令。
每个Java虚拟机实例都有一个方法区以及一个堆，它们是由该虚拟机实例中所有的线程共享的。当虚拟机装载一个class文件时，它会从这个class文件包含的二进制数据中解析类型信息。然后把这些类型信息放到方法区中。当程序运行时，虚拟机会把所有该程序在运行时创建的对象都放到堆中。
当每一个新线程被创建时，它都将得到它自己的PC寄存器（程序计数器）以及一个Java栈。如果线程正在执行的是一个Java方法（非本地方法），那么PC寄存器的值将总是指向下一条将被执行的指令，java栈存储该线程中Java方法调用的状态——包括它的局部变量，被调用时传进来的参数、返回值，以及运算的中间结果等等。而本地方法调用的状态，则是以某种依赖于具体实现的方法存储在本地方法栈中，也可能是在寄存器或者其他某些与特定实现相关的内存区中。
Java虚拟机没有寄存器，其指令集使用Java栈来存储中间数据。Java栈是由许多栈帧（stack frame）组成的，一个栈帧包含一个Java方法调用的状态。当线程调用一个Java方法时，虚拟机压入一个新的栈帧到该线程的Java栈中，当该方法返回时，这个栈帧被从Java栈中弹出并抛弃。
虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用常量的一个有序集合，包括直接常量和对其他类型、字段和方法的符号引用。池中的数据项就像数组一样是通过索引访问的。因为常量池存储了相应类型所用到的所有类型、字段和方法的符号引用，所以它在Java程序的动态连接中起着核心的作用。
创建对象就是通过常量池中对应类的引用找到方法区中对应类。
4.Dalvik
Dalvik将堆分成了Active堆和Zygote堆，Zygote堆是Zygote进程在启动的时候预加载的类、资源和对象，除此之外的所有对象都是存储在Active堆中的。
Dalvik的gygote堆存放的预加载的类都是Android核心类和java运行时库，这部分内容很少被修改，大多数情况父进程和子进程共享这块内存区域。通常垃圾回收重点对Active堆进行回收操作，Dalvik为了对堆进行更好的管理创建了一个Card Table、两个Heap Bitmap和一个Mark Stack数据结构。
许多GC实现都是在对象开头的地方留一小块空间给GC标记用。Dalvik VM则不同，在进行GC的时候会单独申请一块空间，以位图的形式来保存整个堆上的对象的标记，在GC结束后就释放该空间。
Dalvik使用即时编译(JIT)，即是在程序运行过程中进行编译。JIT会在运行时分析应用程序的代码，识别哪些方法可以归类为热方法，这些方法会被JIT编译器编译成对应的汇编代码，然后存储到代码缓存中，以后调用这些方法时就不用解释执行了，可以直接使用代码缓存中已编译好的汇编代码。
javac把程序源码编译成JAVA字节码，JVM通过逐条解释字节码将其翻译成对应的机器指令，逐条读入，逐条解释翻译，执行速度必然比C/C++编译后的可执行二进制字节码程序慢，为了提高执行速度，就引入了JIT技术。
2.ART
与Dalvik不同，ART使用预编译（AOT,Ahead-Of-Time）。也就是在APK运行之前，就对其包含的Dex字节码进行翻译，得到对应的本地机器指令，于是就可以在运行时直接执行了。
ART应用安装的时候把dex中的字节码将被编译成本地机器码，之后每次打开应用，执行的都是本地机器码。去除了运行时的解释执行，效率更高，启动更快。
在Android系统启动过程中创建的Zygote进程利用ART运行时导出的Java虚拟机接口创建ART虚拟机。APK在安装的时候，打包在里面的classes.dex文件会被工具dex2oat翻译成本地机器指令，最终得到一个ELF格式的oat文件。APK运行时，上述生成的oat文件会被加载到内存中，并且ART虚拟机可以通过里面的oatdata和oatexec段找到任意一个类的方法对应的本地机器指令来执行。 oat文件中的oatdata包含用来生成本地机器指令的dex文件，内容oat文件中的oatexec包含有生成的本地机器指令。
可以分配内存的Space有三个：Zygote Space、Allocation Space和Large Object Space。实际上应用运行的时候能够分配内存也就Allocation 和 Large Object Space两个。
ART优点：
①系统性能显著提升，每次启动执行的时候，都可以直接运行，因此运行效率会提高。
②应用启动更快、运行更快、体验更流畅、触感反馈更及时
③续航能力提升，因为应用程序每次运行时不用重复编译了，从而减少了 CPU 的使用频率，降低了能耗。
④支持更低的硬件
ART缺点
①更大的存储空间占用，可能增加10%-20%（字节码变为机器码之后，可能会增加10%-20%）
②更长的应用安装时间，应用在第一次安装的时候，字节码就会预编译（AOT）成机器码，这样的话，虽然设备和应用的首次启动（安装慢了）会变慢
4.android7.0\7.1
android7.0\7.1的ART引入了全新的Hybrid模式(Interpreter + JIT + AOT)
- 与前面不同，app在安装时不进行编译，所以安装速度会更快。
- 在运行App时， 先走解释器， 然后热点函数会被识别，并被JIT进行编译， 存储在jit code cache， 并产生profile文件(记录热点函数信息)。
- 等手机进入充电和空闲状态下， 系统会每隔一段时间扫描App目录下profile文件，并执行AOT编译(Google官方称之为profile-guided compilation)。
- 不论是jit编译的binary code, 还是AOT编译的binary code, 它们之间的性能差别不大， 因为它们使用同一个optimizing compiler进行编译。
这样的优点是：App安装速度快，占用存储少(只编译热点函数)。
缺点是：前几次运行会较慢， 只有用户操作得次数越多，jit 和AOT编译后， 性能才会跟上来。
后记
垃圾回收机制也是很重要的一环，但这个能说的太多了。
参考：
