?

一、什么是Dalvik虛擬機(jī)

Dalvik是Google公司自己設(shè)計(jì)用于Android平臺(tái)的Java虛擬機(jī)，它是Android平臺(tái)的重要組成部分，支持dex格式（Dalvik Executable）的Java應(yīng)用程序的運(yùn)行。dex格式是專門為Dalvik設(shè)計(jì)的一種壓縮格式，適合內(nèi)存和處理器速度有限的系統(tǒng)。Google對(duì)其進(jìn)行了特定的優(yōu)化，使得Dalvik具有高效、簡(jiǎn)潔、節(jié)省資源的特點(diǎn)。從Android系統(tǒng)架構(gòu)圖知，Dalvik虛擬機(jī)運(yùn)行在Android的運(yùn)行時(shí)庫(kù)層。

Dalvik作為面向Linux、為嵌入式操作系統(tǒng)設(shè)計(jì)的虛擬機(jī)，主要負(fù)責(zé)完成對(duì)象生命周期管理、堆棧管理、線程管理、安全和異常管理，以及垃圾回收等。另外，Dalvik早期并沒(méi)有JIT編譯器，直到Android2.2才加入了對(duì)JIT的技術(shù)支持。

?

?

二、Dalvik虛擬機(jī)的特點(diǎn)

體積小，占用內(nèi)存空間小；

專有的DEX可執(zhí)行文件格式，體積更小，執(zhí)行速度更快；

常量池采用32位索引值，尋址類方法名，字段名，常量更快；

基于寄存器架構(gòu)，并擁有一套完整的指令系統(tǒng)；

提供了對(duì)象生命周期管理，堆棧管理，線程管理，安全和異常管理以及垃圾回收等重要功能；

所有的Android程序都運(yùn)行在Android系統(tǒng)進(jìn)程里，每個(gè)進(jìn)程對(duì)應(yīng)著一個(gè)Dalvik虛擬機(jī)實(shí)例。

?

?

三、Dalvik虛擬機(jī)和Java虛擬機(jī)的區(qū)別

Dalvik虛擬機(jī)與傳統(tǒng)的Java虛擬機(jī)有著許多不同點(diǎn)，兩者并不兼容，它們顯著的不同點(diǎn)主要表現(xiàn)在以下幾個(gè)方面：

Java虛擬機(jī)運(yùn)行的是Java字節(jié)碼，Dalvik虛擬機(jī)運(yùn)行的是Dalvik字節(jié)碼。

傳統(tǒng)的Java程序經(jīng)過(guò)編譯，生成Java字節(jié)碼保存在class文件中，Java虛擬機(jī)通過(guò)解碼class文件中的內(nèi)容來(lái)運(yùn)行程序。而Dalvik虛擬機(jī)運(yùn)行的是Dalvik字節(jié)碼，所有的Dalvik字節(jié)碼由Java字節(jié)碼轉(zhuǎn)換而來(lái)，并被打包到一個(gè)DEX（Dalvik Executable）可執(zhí)行文件中。Dalvik虛擬機(jī)通過(guò)解釋DEX文件來(lái)執(zhí)行這些字節(jié)碼。

Dalvik可執(zhí)行文件體積小。Android SDK中有一個(gè)叫dx的工具負(fù)責(zé)將Java字節(jié)碼轉(zhuǎn)換為Dalvik字節(jié)碼。

dx工具對(duì)Java類文件重新排列，消除在類文件中出現(xiàn)的所有冗余信息，避免虛擬機(jī)在初始化時(shí)出現(xiàn)反復(fù)的文件加載與解析過(guò)程。一般情況下，Java類文件中包含多個(gè)不同的方法簽名，如果其他的類文件引用該類文件中的方法，方法簽名也會(huì)被復(fù)制到其類文件中，也就是說(shuō)，多個(gè)不同的類會(huì)同時(shí)包含相同的方法簽名，同樣地，大量的字符串常量在多個(gè)類文件中也被重復(fù)使用。這些冗余信息會(huì)直接增加文件的體積，同時(shí)也會(huì)嚴(yán)重影響虛擬機(jī)解析文件的效率。消除其中的冗余信息，重新組合形成一個(gè)常量池，所有的類文件共享同一個(gè)常量池。由于dx工具對(duì)常量池的壓縮，使得相同的字符串，常量在DEX文件中只出現(xiàn)一次，從而減小了文件的體積。

針對(duì)每個(gè)Class文件，都由如下格式進(jìn)行組成：

dex格式文件使用共享的、特定類型的常量池機(jī)制來(lái)節(jié)省內(nèi)存。常量池存儲(chǔ)類中的所有字面常量，它包括字符串常量、字段常量等值。

簡(jiǎn)單來(lái)講，dex格式文件就是將多個(gè)class文件中公有的部分統(tǒng)一存放，去除冗余信息。

**Java虛擬機(jī)與Dalvik虛擬機(jī)架構(gòu)不同。**這也是Dalvik與JVM之間最大的區(qū)別。

Java虛擬機(jī)基于棧架構(gòu)，程序在運(yùn)行時(shí)虛擬機(jī)需要頻繁的從棧上讀取或?qū)懭霐?shù)據(jù)，這個(gè)過(guò)程需要更多的指令分派與內(nèi)存訪問(wèn)次數(shù)，會(huì)耗費(fèi)不少CPU時(shí)間，對(duì)于像手機(jī)設(shè)備資源有限的設(shè)備來(lái)說(shuō)，這是相當(dāng)大的一筆開(kāi)銷。Dalvik虛擬機(jī)基于寄存器架構(gòu)。數(shù)據(jù)的訪問(wèn)通過(guò)寄存器間直接傳遞，這樣的訪問(wèn)方式比基于棧方式要快很多。

?

四、Dalvik虛擬機(jī)的結(jié)構(gòu)

一個(gè)應(yīng)用首先經(jīng)過(guò)DX工具將class文件轉(zhuǎn)換成Dalvik虛擬機(jī)可以執(zhí)行的dex文件，然后由類加載器加載原生類和Java類，接著由解釋器根據(jù)指令集對(duì)Dalvik字節(jié)碼進(jìn)行解釋、執(zhí)行。最后，根據(jù)dvm_arch參數(shù)選擇編譯的目標(biāo)機(jī)體系結(jié)構(gòu)。

?

五、Android APK 編譯打包流程

1.Java編譯器對(duì)工程本身的java代碼進(jìn)行編譯，這些java代碼有三個(gè)來(lái)源：app的源代碼，由資源文件生成的R文件(aapt工具)，以及有aidl文件生成的java接口文件(aidl工具)。產(chǎn)出為.class文件。

①.用AAPT編譯R.java文件

②編譯AIDL的java文件

③把java文件編譯成class文件

2..class文件和依賴的三方庫(kù)文件通過(guò)dex工具生成Delvik虛擬機(jī)可執(zhí)行的.dex文件，包含了所有的class信息，包括項(xiàng)目自身的class和依賴的class。產(chǎn)出為.dex文件。

3.apkbuilder工具將.dex文件和編譯后的資源文件生成未經(jīng)簽名對(duì)齊的apk文件。這里編譯后的資源文件包括兩部分，一是由aapt編譯產(chǎn)生的編譯后的資源文件，二是依賴的三方庫(kù)里的資源文件。產(chǎn)出為未經(jīng)簽名的.apk文件。

4.分別由Jarsigner和zipalign對(duì)apk文件進(jìn)行簽名和對(duì)齊，生成最終的apk文件。

總結(jié)為：編譯-->DEX-->打包-->簽名和對(duì)齊

?

六、ART虛擬機(jī)與Dalvik虛擬機(jī)的區(qū)別

什么是ART:

ART代表Android Runtime，其處理應(yīng)用程序執(zhí)行的方式完全不同于Dalvik，Dalvik是依靠一個(gè)Just-In-Time (JIT)編譯器去解釋字節(jié)碼。開(kāi)發(fā)者編譯后的應(yīng)用代碼需要通過(guò)一個(gè)解釋器在用戶的設(shè)備上運(yùn)行，這一機(jī)制并不高效，但讓?xiě)?yīng)用能更容易在不同硬件和架構(gòu)上運(yùn) 行。ART則完全改變了這套做法，在應(yīng)用安裝時(shí)就預(yù)編譯字節(jié)碼到機(jī)器語(yǔ)言，這一機(jī)制叫Ahead-Of-Time (AOT）編譯。在移除解釋代碼這一過(guò)程后，應(yīng)用程序執(zhí)行將更有效率，啟動(dòng)更快。

ART優(yōu)點(diǎn)：

系統(tǒng)性能的顯著提升。

應(yīng)用啟動(dòng)更快、運(yùn)行更快、體驗(yàn)更流暢、觸感反饋更及時(shí)。

更長(zhǎng)的電池續(xù)航能力。

支持更低的硬件。

ART缺點(diǎn)：

更大的存儲(chǔ)空間占用，可能會(huì)增加10%-20%。

更長(zhǎng)的應(yīng)用安裝時(shí)間。

ART虛擬機(jī)相對(duì)于Dalvik虛擬機(jī)的提升

預(yù)編譯

在dalvik中,如同其他大多數(shù)JVM一樣,都采用的是JIT來(lái)做及時(shí)翻譯(動(dòng)態(tài)翻譯),將dex或odex中并排的dalvik code(或者叫smali指令集)運(yùn)行態(tài)翻譯成native code去執(zhí)行.JIT的引入使得dalvik提升了3~6倍的性能。

而在ART中,完全拋棄了dalvik的JIT,使用了AOT直接在安裝時(shí)將其完全翻譯成native code.這一技術(shù)的引入,使得虛擬機(jī)執(zhí)行指令的速度又一重大提升

垃圾回收機(jī)制

首先介紹下dalvik的GC的過(guò)程.主要有有四個(gè)過(guò)程:

當(dāng)gc被觸發(fā)時(shí)候,其會(huì)去查找所有活動(dòng)的對(duì)象,這個(gè)時(shí)候整個(gè)程序與虛擬機(jī)內(nèi)部的所有線程就會(huì)掛起,這樣目的是在較少的堆棧里找到所引用的對(duì)象.需要注意的是這個(gè)回收動(dòng)作和應(yīng)用程序非并發(fā)。

gc對(duì)符合條件的對(duì)象進(jìn)行標(biāo)記

gc對(duì)標(biāo)記的對(duì)象進(jìn)行回收

恢復(fù)所有線程的執(zhí)行現(xiàn)場(chǎng)繼續(xù)運(yùn)行

dalvik這么做的好處是,當(dāng)pause了之后,GC勢(shì)必是相當(dāng)快速的.但是如果出現(xiàn)GC頻繁并且內(nèi)存吃緊勢(shì)必會(huì)導(dǎo)致UI卡頓,掉幀.操作不流暢等。

后來(lái)ART改善了這種GC方式 ,?主要的改善點(diǎn)在將其非并發(fā)過(guò)程改變成了部分并發(fā).還有就是對(duì)內(nèi)存的重新分配管理。

當(dāng)ART GC發(fā)生時(shí):

GC將會(huì)鎖住Java堆,掃描并進(jìn)行標(biāo)記

標(biāo)記完畢釋放掉Java堆的鎖,并且掛起所有線程

GC對(duì)標(biāo)記的對(duì)象進(jìn)行回收

恢復(fù)所有線程的執(zhí)行現(xiàn)場(chǎng)繼續(xù)運(yùn)行

重復(fù)2-4直到結(jié)束

可以看出整個(gè)過(guò)程做到了部分并發(fā)使得時(shí)間縮短.據(jù)官方測(cè)試數(shù)據(jù)說(shuō)gc效率提高2倍

提高內(nèi)存使用，減少碎片化

Dalvik內(nèi)存管理特點(diǎn)是:內(nèi)存碎片化嚴(yán)重，當(dāng)然這也是Mark and Sweep算法帶來(lái)的弊端

可以看出每次gc后內(nèi)存千瘡百孔，本來(lái)連續(xù)分配的內(nèi)存塊變得碎片化嚴(yán)重，之后再分配進(jìn)入的對(duì)象再進(jìn)行內(nèi)存尋址變得困難。

ART的解決:在ART中,它將Java分了一塊空間命名為L(zhǎng)arge-Object-Space,這塊內(nèi)存空間的引入用來(lái)專門存放large object。同時(shí)ART又引入了moving collector的技術(shù),即將不連續(xù)的物理內(nèi)存塊進(jìn)行對(duì)齊.對(duì)齊了后內(nèi)存碎片化就得到了很好的解決.Large-Object-Space的引入一是因?yàn)閙oving collector對(duì)大塊內(nèi)存的位移時(shí)間成本太高,而且提高內(nèi)存的利用率 根官方統(tǒng)計(jì)，ART的內(nèi)存利用率提高10倍了左右。

?

七、參考文章

　　https://github.com/LRH1993/android_interview/blob/master/android/basis/dalvik-art.md

?

轉(zhuǎn)載于:https://www.cnblogs.com/Jason-Jan/p/8459105.html

總結(jié)

以上是生活随笔為你收集整理的Android面试收集录13 Android虚拟机及编译过程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。