1.Dalvik虚拟机和java虚拟机的异同点
最显著曲边是他们分别具有不同的类文件格式以及指令集
a. Dalvik虚拟机执行的是dex(Dalvik Executable)格式的类文件，一个dex文件可包含若干个类，dex将各个类中重复的字符串和其他常数只保存一次，从而节省空间，适用于内存和处理器速度优先的手机系统；而Java虚拟机使用的是.class格式类文件，一个class文件只包含一个类；
b. Dalvik虚拟机使用的指令是基于寄存器；Java虚拟机使用的指令集是基于堆栈的；各有优劣
2.Dalvik虚拟机自身优化措施
a. 将多个类文件合成到一个dex文件中，节省空间
b. 使用只读内存映射方式加载dex文件，以便可以多进程共享dex文件，节省程序加载时间；
c. 提前调整好字节序和字对齐方式，使得它们更适合本机机器，一遍提高指令执行速度；
d. 尽量提前执行字节码校验，提高程序的加载速度；
e. 需要重写字节码的优化要提前进行
3.内存管理（重点）
Dalvik虚拟机的内存大体上可以分为Java Object Heap、Bitmap Memory和Native Heap三种。
Java Object Heap是用来分配Java对象的，也就是我们在代码new出来的对象都是位于Java Object Heap上的。Dalvik虚拟机在启动的时候，可以通过-Xms和-Xmx选项来指定Java Object Heap的最小值和最大值。为了避免Dalvik虚拟机在运行的过程中对Java Object Heap的大小进行调整而影响性能，我们可以通过-Xms和-Xmx选项来将它的最小值和最大值设置为相等。
Java Object Heap的最小和最大默认值为2M和16M，但是手机在出厂时，厂商会根据手机的配置情况来对其进行调整，例如，G1、Droid、Nexus One和Xoom的Java Object Heap的最大值分别为16M、24M、32M 和48M。我们可以通过ActivityManager类的成员函数getMemoryClass来获得Dalvik虚拟机的Java Object Heap的最大值。
ActivityManager类的成员函数getMemoryClass的实现如下所示：
public class ActivityManager {
......
/**
* Return the approximate per-application memory class of the current
* device. This gives you an idea of how hard a memory limit you should
* impose on your application to let the overall system work best. The
* returned value is in megabytes; the baseline Android memory class is
* 16 (which happens to be the Java heap limit of those devices); some
* device with more memory may return 24 or even higher numbers.
*/
public int getMemoryClass() {
return staticGetMemoryClass();
}
/** @hide */
static public int staticGetMemoryClass() {
// Really brain dead right now -- just take this from the configured
// vm heap size, and assume it is in megabytes and thus ends with "m".
String vmHeapSize = SystemProperties.get("dalvik.vm.heapsize", "16m");
return Integer.parseInt(vmHeapSize.substring(0, vmHeapSize.length()-1));
}
......
}
这个函数定义在文件frameworks/base/core/java/android/app/ActivityManager.java中。
Dalvik虚拟机在启动的时候，就是通过读取系统属性dalvik.vm.heapsize的值来获得Java Object Heap的最大值的，而ActivityManager类的成员函数getMemoryClass最终也通过读取这个系统属性的值来获得Java Object Heap的最大值。
这个Java Object Heap的最大值也就是我们平时所说的Android应用程序进程能够使用的最大内存。这里必须要注意的是，Android应用程序进程能够使用的最大内存指的是能够用来分配Java Object的堆。
Bitmap Memory也称为External Memory，它是用来处理图像的。在HoneyComb之前，Bitmap Memory是在Native Heap中分配的，但是这部分内存同样计入Java Object Heap中，也就是说，Bitmap占用的内存和Java Object占用的内存加起来不能超过Java Object Heap的最大值。这就是为什么我们在调用BitmapFactory相关的接口来处理大图像时，会抛出一个OutOfMemoryError异常的原因：
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
在HoneyComb以及更高的版本中，Bitmap Memory就直接是在Java Object Heap中分配了，这样就可以直接接受GC的管理。
Native Heap就是在Native Code中使用malloc等分配出来的内存，这部分内存是不受Java Object Heap的大小限制的，也就是它可以*使用，当然它是会受到系统的限制。但是有一点需要注意的是，不要因为Native Heap可以*使用就滥用，因为滥用Native Heap会导致系统可用内存急剧减少，从而引发系统采取激进的措施来Kill掉某些进程，用来补充可用内存，这样会影响系统体验。
此外，在HoneyComb以及更高的版本中，我们可以在AndroidManifest.xml的application标签中增加一个值等于“true”的android:largeHeap属性来通知Dalvik虚拟机应用程序需要使用较大的Java Object Heap。事实上，在内存受限的手机上，即使我们将一个应用程序的android:largeHeap属性设置为“true”，也是不能增加它可用的Java Object Heap的大小的，而即便是可以通过这个属性来增大Java Object Heap的大小，一般情况也不应该使用该属性。为了提高系统的整体体验，我们需要做的是致力于降低应用程序的内存需求，而不是增加增加应用程序的Java Object Heap的大小，毕竟系统总共可用的内存是固定的，一个应用程序用得多了，就意味意其它应用程序用得少了。
3.垃圾收集（GC）
Dalvik虚拟机可以自动回收那些不再使用了的Java Object，也就是那些不再被引用了的Java Object。垃圾自动收集机制将开发者从内存问题中解放出来，极大地提高了开发效率，以及提高了程序的可维护性。
我们知道，在C或者C++中，开发者需要手动地管理在堆中分配的内存，但是这往往导致很多问题。例如，内存分配之后忘记释放，造成内存泄漏。又如，非法访问那些已经释放了的内存，引发程序崩溃。如果没有一个好的C或者C++应用程序开发框架，一般的开发者根本无法驾驭内存问题，因为程序大了之后，很容易造成失控。最要命的是，内存被破坏的时候，并不一定就是程序崩溃的时候，它就是一颗不定时炸弹，说不准什么时候会被引爆，因此，查找原因是非常困难的。
从这里我们也可以推断出，Android为什么会选择Java而不是C/C++来作为应用程序开发语言，就是为了能够让开发远离内存问题，而将精力集中在业务上，开发出更多更好的APP来，从而迎头赶超iOS。当然，Android系统内存也存在大量的C/C++代码，这只要考虑性能问题，毕竟C/C++程序的运行性能整体上还是优于运行在虚拟机之上的Java程序的。不过，为了避免出现内存问题，在Android系统内部的C++代码，大量地使用了智能指针来自动管理对象的生命周期。选择Java来作为Android应用程序的开发语言，可以说是技术与商业之间一个折衷，事实证明，这种折衷是成功的。
回到正题，在GingerBread之前，Dalvik虚拟使用的垃圾收集机制有以下特点：
a. Stop-the-world，也就是垃圾收集线程在执行的时候，其它的线程都停止；
Full heap collection，也就是一次收集完全部的垃圾；
一次垃圾收集造成的程序中止时间通常都大于100ms。
b. 在GingerBread以及更高的版本中，Dalvik虚拟使用的垃圾收集机制得到了改进，如下所示：
Cocurrent，也就是大多数情况下，垃圾收集线程与其它线程是并发执行的；
Partial collection，也就是一次可能只收集一部分垃圾；
一次垃圾收集造成的程序中止时间通常都小于5ms。
Dalvik虚拟机执行完成一次垃圾收集之后，我们通常可以看到类似以下的日志输出：
D/dalvikvm(9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
在这一行日志中，GC_CONCURRENT表示GC原因，2049K表示总共回收的内存，3571K/9991K表示Java Object Heap统计，即在9991K的Java Object Heap中，有3571K是正在使用的，4703K/5261K表示External Memory统计，即在5261K的External Memory中，有4703K是正在使用的，2ms+2ms表示垃圾收集造成的程序中止时间
4.即时编译（JIT）
前面提到，JIT是相对AOT而言的，即JIT是在程序运行的过程中进行编译的，而AOT是在程序运行前进行编译的。在程序运行的过程中进行编译既有好处，也有坏处。好处在于可以利用程序的运行时信息来对编译出来的代码进行优化，而坏处在于占用程序的运行时间，也就是说不能花太多时间在代码编译和优化之上。
为了解决时间问题，JIT可能只会选择那些热点代码进行编译或者优化。根据2-8原则，一个程序80%的时间可能都是在重复执行20%的代码。因此，JIT就可以选择这20%经常执行的代码来进行编译和优化。
为了充分地利用好运行时信息来优化代码，JIT采用一种激进的方法。JIT在编译代码的时候，会对程序的运行情况进行假设，并且按照这种假设来对代码进行优化。随着程序的代码，如果前面的假设一直保持成立，那么JIT就什么也不用做，因此就可以提高程序的运行性能。一旦前面的假设不再成立了，那么JIT就需要对前面编译优化的代码进行调整，以便适应新的情况。这种调整成本可能是很昂贵的，但是只要假设不成立的情况很少或者几乎不会发生，那么获得的好处还是大于坏处的。由于JIT在编译和优化代码的时候，对程序的运行情况进行了假设，因此，它所采取的激进优化措施又称为赌博，即Gambling。
Dalvik虚拟机从Android 2.2版本开始，才支持JIT，而且是可选的。在编译Dalvik虚拟机的时候，可以通过WITH_JIT宏来将JIT也编译进去，而在启动Dalvik虚拟机的时候，可以通过-Xint:jit选项来开启JIT功能。
5.Java本地调用(JNI)
无论如何，虚拟机最终都是运行在目标机器之上的，也就是说，它需要将自己的指令翻译成目标机器指令来执行，并且有些功能，需要通过调用目标机器运行的操作系统接口来完成。这样就需要有一个机制，使得函数调用可以从Java层穿越到Native层，也就是C/C++层。这种机制就称为Java本地调用，即JNI。当然，我们在执行Native代码的时候，有时候也是需要调用到Java函数的，这同样是可以通过JNI机制来实现。也就是说，JNI机制既支持在Java函数中调用C/C++函数，也支持在C/C++函数中调用Java函数。
事实上，Dalvik虚拟机提供的Java运行时库，大部分都是通过调用目标机器操作系统接口来实现的，也就是通过调用Linux系统接口来实现的。例如，当我们调用android.os.Process类的成员函数start来创建一个进程的时候，最终会调用到linux系统提供的fork系统调用来创建一个进程。
同时，为了方便开发者使用C/C++语言来开发应用程序，Android官方提供了NDK。通过NDK，我们就可以使用JNI机制来在Java函数中调用到C/C++函数。不过Android官方是不提倡使用NDK来开发应用程序的，这从它对NDK的支持远远不如SDK的支持就可以看得出来。
6. 进程和线程管理
别是考虑到多核的情况，因此，就完全没有必要在虚拟机中提供一个进程和线程库。
Dalvik虚拟机运行在Linux操作系统之上。
关于Android应用程序进程，它有两个很大的特点，下面我们就简要介绍一下。
第一个特点是每一个Android应用程序进程都有一个Dalvik虚拟机实例。这样做的好处是Android应用程序进程之间不会相互影响，也就是说，一个Android应用程序进程的意外中止，不会影响到其它的Android应用程序进程的正常运行。
第二个特点是每一个Android应用程序进程都是由一种称为Zygote的进程fork出来的。Zygote进程是由init进程启动起来的，也就是在系统启动的时候启动的。Zygote进程在启动的时候，会创建一个虚拟机实例，并且在这个虚拟机实例将所有的Java核心库都加载起来。每当Zygote进程需要创建一个Android应用程序进程的时候，它就通过复制自身来实现，也就是通过fork系统调用来实现。这些被fork出来的Android应用程序进程，一方面是复制了Zygote进程中的虚拟机实例，另一方面是与Zygote进程共享了同一套Java核心库。这样不仅Android应用程序进程的创建过程很快，而且由于所有的Android应用程序进程都共享同一套Java核心库而节省了内存空间。