1、Dalvik虛擬機與Java虛擬機的最顯著差別是它們分別具有不同的類文件格式以及指令集。Dalvik虛擬機使用的是dex（Dalvik Executable）格式的類文件，而Java虛擬機使用的是class格式的類文件。

一個dex文件能夠包括若干個類。而一個class文件僅僅包括一個類。

因為一個dex文件能夠包括若干個類。因此它就能夠將各個類中反復的字符串和其他常數僅僅保存一次。從而節省了空間，這樣就適合在內存和處理器速度有限的手機系統中使用。一般來說。包括有同樣類的未壓縮dex文件稍小于一個已經壓縮的jar文件。

2、Dalvik虛擬機使用的指令是基于寄存器的，而Java虛擬機使用的指令集是基于堆棧的。

基于堆棧的指令非常緊湊，比如。Java虛擬機使用的指令僅僅占一個字節，因而稱為字節碼。基于寄存器的指令因為須要指定源地址和目標地址。因此須要占用很多其它的指令空間，比如，Dalvik虛擬機的某些指令須要占用兩個字節。基于堆棧和基于寄存器的指令集各有優劣。一般而言，運行相同的功能，前者須要很多其它的指令（主要是load和store指令），而后者須要很多其它的指令空間。

須要很多其它指令意味著要多占用CPU時間，而須要很多其它指令空間意味著數據緩沖（d-cache）更易失效。

3、此外，另一種觀點覺得。基于堆棧的指令更具可移植性，由于它不正確目標機器的寄存器進行不論什么如果。

然而，基于寄存器的指令由于對目標機器的寄存器進行了如果。因此。它更有利于進行AOT（ahead-of-time）優化。 所謂AOT，就是在解釋語言程序執行之前。就先將它編譯成本地機器語言程序。AOT本質上是一種靜態編譯，它是是相對于JIT而言的，也就是說。前者是在程序執行前進行編譯。而后者是在程序執行時進行編譯。執行時編譯意味著能夠利用執行時信息來得到比較靜態編譯更優化的代碼，同一時候也意味不能進行某些高級優化。由于優化過程太耗時了。還有一方面，執行前編譯由于不占用程序執行時間，因此。它就能夠不計時間成本來優化代碼。

不管AOT。還是JIT，終于的目標都是將解釋語言編譯為本地機器語言，而本地機器語言都是基于寄存器來執行的。因此，在某種程度來講，基于寄存器的指令更有利于進行AOT編譯以及優化。

4、無論結論怎樣，Dalvik虛擬機都在盡最大的努力來優化自身，這些措施包含：

? ? ? ? （1）. 將多個類文件收集到同一個dex文件里。以便節省空間；

? ? ? ? （2） 使用僅僅讀的內存映射方式載入dex文件，以便能夠多進程共享dex文件。節省程序載入時間。

? ? ? ? （3） 提前調整好字節序（byte order）和字對齊（word alignment）方式，使得它們更適合于本地機器。以便提高指令運行速度。

? ? ? ? （4） 盡量提前進行字節碼驗證（bytecode verification）。提高程序的載入速度。

? ? ? ? （5） 須要重寫字節碼的優化要提前進行。

5、內存管理

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的最大值也就是我們平時所說的Android應用程序進程可以使用的最大內存。這里必需要注意的是。Android應用程序進程可以使用的最大內存指的是可以用來分配Java Object的堆。

在HoneyComb以及更高的版本號中，Bitmap Memory就直接是在Java Object Heap中分配了，這樣就能夠直接接受GC的管理。

? ? ? ? Native Heap就是在Native Code中使用malloc等分配出來的內存。這部分內存是不受Java Object Heap的限制大小的，也就是它能夠自由使用。當然它是會受到系統的限制。可是有一點須要注意的是。不要由于Native Heap能夠自由使用就濫用，由于濫用Native Heap會導致系統可用內存急劇降低，從而引發系統採取激進的措施來Kill掉某些進程，用來補充可用內存。這樣會影響系統體驗。

6、垃圾收集

Dalvik虛擬機能夠自己主動回收那些不再使用了的Java Object，也就是那些不再被引用了的Java Object。垃圾自己主動收集機制將開發人員從內存問題中解放出來。極大地提高了開發效率，以及提高了程序的可維護性。

?在GingerBread以及更高的版本號中，Dalvik虛擬使用的垃圾收集機制得到了改進，例如以下所看到的：

? ? ? ? （1） Cocurrent，也就是大多數情況下，垃圾收集線程與其他線程是并發運行的；

? ? ? ? （2）Partial collection，也就是一次可能僅僅收集一部分垃圾；

? ? ? ? （3）一次垃圾收集造成的程序中止時間通常都小于5ms。

7、進程和線程管理

一般來說，虛擬機的進程和線程都是與目標機器本地操作系統的進程和線程一一相應的，這樣做的優點是能夠使本地操作系統來調度進程和線程。進程和線程調度是操作系統的核心模塊，它的實現是很復雜的，特別是考慮到多核的情況，因此，就全然沒有必要在虛擬機中提供一個進程和線程庫。

?Dalvik虛擬機執行在Linux操作系統之上。

我們知道，Linux操作系統并沒有純粹的線程概念，僅僅要兩個進程共享同一個地址空間，那么就能夠覺得它們同一個進程的兩個線程。Linux操作系統提供了兩個fork和clone兩個調用。當中，前者就是用來創建進程的，而后者就是用來創建線程的。

?關于Android應用程序進程，它有兩個非常大的特點。以下我們就簡要介紹一下。

第一個特點是每個Android應用程序進程都有一個Dalvik虛擬機實例。這樣做的優點是Android應用程序進程之間不會相互影響，也就是說，一個Android應用程序進程的意外中止。不會影響到其他的Android應用程序進程的正常執行。

第二個特點是每個Android應用程序進程都是由一種稱為Zygote的進程fork出來的。Zygote進程是由init進程啟動起來的，也就是在系統啟動的時候啟動的。Zygote進程在啟動的時候。會創建一個虛擬機實例，并且在這個虛擬機實例將全部的Java核心庫都載入起來。每當Zygote進程須要創建一個Android應用程序進程的時候。它就通過復制自身來實現，也就是通過fork系統調用來實現。

這些被fork出來的Android應用程序進程，一方面是復制了Zygote進程中的虛擬機實例，還有一方面是與Zygote進程共享了同一套Java核心庫。這樣不僅Android應用程序進程的創建過程非常快，并且因為全部的Android應用程序進程都共享同一套Java核心庫而節省了內存空間。

摘至：http://blog.csdn.net/luoshengyang/article/details/8852432

總結

以上是生活随笔為你收集整理的Android 虚拟机学习总结Dalvik虚拟机介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。