Android Dalvik虛擬機概述

Dalvik虛擬機概述

Dalvik是Google公司自己設計用於Android平台的Java虛擬機。Dalvik虛擬機是Google等廠商合作開發的Android移動設備平台的核心組成部分之一。它可以支持已轉換為 .dex（即Dalvik Executable）格式的Java應用程序的運行，.dex格式是專為Dalvik設計的一種壓縮格式，適合內存和處理器速度有限的系統。Dalvik 經過優化，允許在有限的內存中同時運行多個虛擬機的實例，並且每一個Dalvik 應用作為一個獨立的Linux 進程執行。獨立的進程可以防止在虛擬機崩潰的時候所有程序都被關閉。

面試紀要：如果有人面試問泥，應用進程就是linux一個進程，還是說一個liunx進程可以有多個dvk實例？

答案

每一個Android應用程序都在它自己的進程中運行，都擁有一個獨立的Dalvik虛擬機實例。而每一個DVM都是在Linux 中的一個進程，所以說可以認為是同一個概念。

發展

Dalvik的誕生也導致人們開始憂慮Java平台的第一次大規模的分道揚镳或許已經是進行時了——有人已經把Davlik和微軟的JVM以及Sun 對微軟的訴訟聯系起來，等著看Google身上是否也會發生類似事情；另外一些人則指出，Google並沒有宣稱Dalvik是一個Java實現，而微軟卻是這樣做的。Sun也對可能帶來的陣營分裂表達了憂慮情緒，並提出和Google合作來保證Dalvik和JVM之間的兼容性——Google對此的解釋是，Dalvik是對解決目前Java ME平台上分裂的一次嘗試，也是為了提供一個擁有較少限制許可證的平台。甚至還有人懷疑這是否是Sun和Google兩大陣營對Java之未來的一次大規模較量。Ian Skerret認為，

Dalvik的誕生是對Sun嘗試控制和保護來自Java ME收入來源的一次反應，以及對建立OpenJDK統轄理事會遲遲未果的回答。

這也導致Dalibor Topic懷疑Google是否要重履Sun走過的路：

當然，一個很有意思的問題是，為什麼沒人有勇氣拿Google關於OpenJDK的問題反過來問Google呢？

雖然Android號稱開源，但它仍是專有產品。Android做過兼容性保證，是在秘密會議室中簽署和保管的。

Android不具備任何治理模型，也沒有證據指出將來會出現治理模型。Android沒有規范，並且它的許可證禁止任何替代實現的開發，因為這並非Google在SDK許可證中授權許可的使用權。Android完全在Google的掌控之下，一旦有競爭性應用在財政上損害了Google的利益，Google是保有一刀抹殺這些應用的權利的。從設計伊始，Android就受到限制，只能在Google的財務利益允許的條件內開放。專有的Java也不是什麼好貨色，舊瓶裝新酒而已。這就好像我們在見證JCP的重生一樣，人們排著隊把開源社區的“街頭信譽”在一個單一的、

專有的實現的基礎上借給另外一個封閉的廠商壟斷集團。只不過這次的大頭改姓Google，而不是Sun了。(不過大家在叫喚著開源的時候,卻似乎全都忘記了開發這一系列軟件本身需要巨大的投入,因此利益在前,這其實也無可厚非.)

Stefano Mazzocchi發布了一篇分析報告，深切入裡地探討了圍繞Java ME和Dalvik的許可證問題，他得出結論說，Dalvik的市場定位良好，足以給移動電話市場帶來沖擊。盡管Google一直都很小心避免引起訴訟的幾個關鍵點，但Mazzocchi相信Sun還是會起草知識產權案的狀告書（IBM也有可能）。他還指出，由於在JCP之外操作，Google可以非常快地對Android進行更改，而且可以避開Sun對任何JCP更動的否決權——這樣他們也可以為諸如USB和藍牙這樣的組件加入接口，而這些組件在基礎Java ME實現中是不可用的。

最後，通過在Apache許可證下授權許可Dalvik的源碼，移動電話運營商更有可能采用Dalvik，因為運營商可以在不花費許可費用的情況下使用和修改它。

此外，Java也已經不再是人們在Dalvik上開發所選擇的唯一語言了——已經有人在Dalvik上運行Scala取得了成功，並且Hecl也已經被成功移植了。另外更有人對運行Groovy做了一次嘗試，不過目前為止還不怎麼成功。Mono項目的創始人Miguel de Icaza也對在Dalvik源碼公開之後將Mono整合到Dalvik上表示了興趣，

而且也已經有人猜測如何用多種方式來實現整合了，包括與隨Android SDK提供的Java到Dalvik重編譯器類似的CIL（Common Intermediate Language，通用中間語言）到Dalvik重編譯器。

簡介

（dx是一套工具，可以將 Java .class 轉換成 .dex 格式. 一個dex檔通常會有多個.class。由於dex有時必須進行最佳化，會使檔案大小增加1-4倍，以ODEX結尾。）

Dalvik和標准Java虛擬機(JVM)首要差別

Dalvik 基於寄存器，而 JVM 基於棧。

基於寄存器的虛擬機對於編譯後變大的程序來說，在它們執行的時候，花費的時間更短。（Also of register-based VMs allow faster execution times at the expense of programs which are larger after compilation.）

Dalvik和Java運行環境的區別

1：Dalvik主要是完成對象生命周期管理，堆棧管理，線程管理，安全和異常管理，以及垃圾回收等等重要功能。

2：Dalvik負責進程隔離和線程管理，每一個Android應用在底層都會對應一個獨立的Dalvik虛擬機實例，其代碼在虛擬機的解釋下得以執行。

3：不同於Java虛擬機運行java字節碼，Dalvik虛擬機運行的是其專有的文件格式Dex

4:dex文件格式可以減少整體文件尺寸，提高I/o操作的類查找速度。

5:odex是為了在運行過程中進一步提高性能，對dex文件的進一步優化。

6：所有的Android應用的線程都對應一個Linux線程，虛擬機因而可以更多的依賴操作系統的線程調度和管理機制

7：有一個特殊的虛擬機進程Zygote，他是虛擬機實例的孵化器。它在系統啟動的時候就會產生，它會完成虛擬機的初始化，庫的加載，預制類庫和初始化的操作。如果系統需要一個新的虛擬機實例，它會迅速復制自身，以最快的數據提供給系統。對於一些只讀的系統庫，所有虛擬機實例都和Zygote共享一塊內存區域。

8：Dalvik是由Dan Bornstein編寫的，名字來源於他的祖先曾經居住過名叫Dalvík的小漁村，村子位於冰島Eyjafjörður

架構

不同於其他堆棧結構的Java虛擬機，dalvik采用的是基於寄存器的架構。

dx工具將部分（但不是全部）Java的.class文件轉換成.dex格式。多個類被包含在一個.dex文件中。為了節省空間，各個類文件中重復的字符串和其他常數只在.dex輸出中存放一次。Java字節碼被轉換成Dalvik虛擬機所使用的替代指令集。一個未壓縮的.dex文件通常比來自相同.class文件的已壓縮.jar文檔小。

當被安裝到移動設備時，Dalvik可執行文件可能會被修改。為了進一步優化，虛擬機可能會調整文件內部分數據的端序、內聯一些函數和簡單的結構體、並短路掉一些不必要的操作等。
　　自Android 2.2開始，Dalvik支持JIT（just-in-time，即時編譯技術）。
　　優化後的Dalvik較其他標准虛擬機存在一些不同特性
　　·占用更少空間
　　·為簡化翻譯，常量池只使用32位索引
　　·標准Java字節碼實行8位堆棧指令。Dalvik使用16位指令集直接作用於局部變量。局部變量通常來自4位的“虛擬寄存器”區。這樣減少了Dalvik的指令計數，提高了翻譯速度。
　　當Android啟動時，Dalvik VM 監視所有的程序（APK），並且創建依存關系樹，為每個程序優化代碼並存儲在Dalvik緩存中。Dalvik第一次加載後會生成Cache文件，以提供下次快速加載，所以第一次會很慢。
　　Dalvik解釋器采用預先算好的Goto地址，每個指令對內存的訪問都在64字節邊界上對其。這樣可以節省一個指令後進行查表的時間。為了強化功能, Dalvik還提供了快速翻譯器（Fast Interpreter）。

性能

基於堆棧的機器與基於寄存器的機器誰更有優勢一直是個爭論不休的話題。

一般來說,基於堆棧的機器必須使用指令才能從堆棧上的加載和操作數據,因此,相對基於寄存器的機器，它們需要更多的指令才能實現相同的性能。但是基於寄存器機器上的指令必須經過編碼,因此,它們的指令往往更大。這種差異主要是VM機對的操作碼調度造成的，它們往往比其他的因素昂貴，比如說及時匯編。

然而,2010年，在Oracle公司(Java技術的擁有者)嵌入式設備上的標准非圖形化性能測試表明，Android 2.2(最初的版本包括一個即時編譯器)比Java SE嵌入式設備(兩者都基於 Java SE 6)慢2-3倍。

類庫

Dalvik虛擬機既不支持Java SE 也不支持Java ME類庫(如：Java類,AWT和Swing都不支持)。 相反,它使用自己建立的類庫（Apache Harmony Java的一個子集）。