因为嵌入式设备内存有限、CPU处理器不行强大、功耗敏感等缘由，Google没有使用规范的JVM虚拟机，而是为Android单独开发了Dalvik虚拟机。
Dalvik虚拟机与JVM虚拟机有很大不相同，它运转的是通过优化和紧缩的DEX字节码，与规范的JAR字节码并不相同，占用空间更小，而且还能够进一步优化，Android SDK中专门供给了dx东西把传统的Java字节码变换为Dalvik虚拟机能够运转的DEX字节码，这个变换进程是在程序编译的时分就完成了，这即是一些原因大家能够用Java来编写能运转于Android Dalvik虚拟机的程序的缘由了。关于这个进程，下面这张示意图比较直观：
为了便于传达，Android SDK将程序编译后的DEX字节码文件、资这篇文章件、lib库、AndroidManifest.xml等文件一同打包紧缩为apk文件（本来即是一个zip紧缩文件），因而，apk的装置与卸载本来即是对这个zip紧缩包里边的文件进行解压分析拷贝和优化的进程。
因为DEX字节码坐落apk紧缩包中，因而，假如程序发动的时分，每次都要从apk文件中解压获取DEX字节码，显着效率不高，因而，Android体系设计了如下战略：
（1） 创立一个"dalvik-cache"文件夹，专门寄存DEX字节码，详细坐落/data/dalvik-cache
（2） 体系首次发动时，扫描一切的预装apk文件，获取程序的DEX字节码，通过优化后，寄存到dalvik-cache目录中
（3） 每次装置新的apk的时分，也相同获取DEX字节码，优化后放入dalvik-cache目录中
（4） 用户点击使用图标后，直接从dalvik-cache目录中疾速加载优化过的DEX字节码，这么程序就能够很快的发动了。
理解了上述原理，这篇文章讨论的疑问也就方便的解决了，Android体系刷机后首次发动时，需要扫描一切预装的apk文件，获取dex字节码，优化而且拷贝到/data/dalvik-cache缓存目录中，因而，首次发动耗时会显着更高。
