android虛擬機詳解

android5.0之前使用的虛擬機是Dalvik虛擬機，這個虛擬機在JVM的基礎上做了一定的優化。android5.0之後，android采用了新的虛擬機ART，本文主要對Dalvik、JVM、ART之間進行對比。

一.Dalvik虛擬機

1.概念

Dalvik虛擬機是Android程序的虛擬機，是Android中Java程序的運行基礎。其指令集基於寄存器架構，執行其特有的文件格式——dex字節碼來完成對象生命周期管理、堆棧管理、線程管理、安全異常管理、垃圾回收等重要功能。它的核心內容是實現庫（libdvm.so），大體由C語言實現。依賴於Linux內核的一部分功能——線程機制、內存管理機制，能高效使用內存，並在低速CPU上表現出的高性能。每一個Android應用在底層都會對應一個獨立的Dalvik虛擬機實例，其代碼在虛擬機的解釋下得以執行。

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

2.與JVM對比

1. Dalvik虛擬機與Java虛擬機的最顯著區別是它們分別具有不同的類文件格式以及指令集。Dalvik虛擬機使用的是dex（Dalvik Executable）格式的類文件，而Java虛擬機使用的是class格式的類文件。一個dex文件可以包含若干個類，而一個class文件只包括一個類。由於一個dex文件可以包含若干個類，因此它就可以將各個類中重復的字符串和其它常數只保存一次，從而節省了空間，這樣就適合在內存和處理器速度有限的手機系統中使用。一般來說，包含有相同類的未壓縮dex文件稍小於一個已經壓縮的jar文件。

2. Dalvik虛擬機使用的指令是基於寄存器的，而Java虛擬機使用的指令集是基於堆棧的。事實上，基於寄存器和基於堆棧的指令集之爭，就如精簡指令集（RISC）和復雜指令集（CISC）之爭，誰優誰劣，至今是沒有定論的。

3. 將多個類文件收集到同一個dex文件中，以便節省空間；

4. 使用只讀的內存映射方式加載dex文件，以便可以多進程共享dex文件，節省程序加載時間；

5. 提前調整好字節序（byte order）和字對齊（word alignment）方式，使得它們更適合於本地機器，以便提高指令執行速度；

6. 盡量提前進行字節碼驗證（bytecode verification），提高程序的加載速度；

7. 需要重寫字節碼的優化要提前進行。

8. 內存管理不同

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的最大值。

這個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異常的原因：

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

URL：http://www.bianceng.cn/OS/extra/201608/50370.htm

此外，在HoneyComb以及更高的版本中，我們可以在AndroidManifest.xml的application標簽中增加一個值等於“true”的android:largeHeap屬性來通知Dalvik虛擬機應用程序需要使用較大的Java Object Heap。事實上，在內存受限的手機上，即使我們將一個應用程序的android:largeHeap屬性設置為“true”，也是不能增加它可用的Java Object Heap的大小的，而即便是可以通過這個屬性來增大Java Object Heap的大小，一般情況也不應該使用該屬性。為了提高系統的整體體驗，我們需要做的是致力於降低應用程序的內存需求，而不是增加增加應用程序的Java Object Heap的大小，畢竟系統總共可用的內存是固定的，一個應用程序用得多了，就意味意其它應用程序用得少了。

9. JNI與NDK

JNI是java調用C/C++層，JVM和dalvik都有這個能力。不同的在於，為了方便開發者使用C/C++語言來開發應用程序，Android官方提供了NDK。通過NDK，我們就可以使用JNI機制來在Java函數中調用到C/C++函數。不過Android官方是不提倡使用NDK來開發應用程序的，這從它對NDK的支持遠遠不如SDK的支持就可以看得出來。

二.ART虛擬機

1.概念

2.與Dalvik對比

dalvik是執行的時候編譯+運行，安裝比較快，開啟應用比較慢，應用占用空間小ART是安裝的時候就編譯好了，執行的時候直接就可以運行的，安裝慢，開啟應用快，占用空間大用個比喻來說就是，騎自行車dalvik 是已經折疊起來的自行車，每次騎都要先組裝自行車才能騎。ART是已經組裝好的自行車，每次騎直接上車就能走人。

要弄清ART和Dalvik的區別 ，首先要清楚apk文件的構成，apk包中除了一堆資源，還有一個重要文件classes.dex，此文件由java字節碼優化打包而成，在Dalvik中，每次打開應用的時候，Dalvik會讀取這個classes.dex並解釋執行（實際情形，還可能先被轉換成odex文件，在此忽略）；而在ART環境下，當你安裝apk的時候，這個classes.dex文件就會被轉換成本地機器碼——後綴為oat的文件，以後打開應用時直接讀取oat文件執行即可。

舉一個不是很恰當的例子：目前國際通行的論文語言都是英文（相當於java字節碼），而你作為一個中國人只會中文（相當於arm架構的Android手機），而另一個日本人只會日語（相當於x86架構的Android手機），現在給你一堆英文資料，Dalvik的做法就是將這些資料整理歸檔，等你需要查找資料時再從書架上找出需要的部分，然後翻譯為中文閱讀；而ART的做法就是先將所有資料全部翻譯為中文單獨保存，等你需要時直接找中文資料就可以了。

所以，ART的優點就是大大提高了執行效率，但是缺點也很明顯，一是安裝耗時更長，一是占用更多磁盤空間。

ART擁有改進的GC(垃圾回收)機制：GC時更少的暫停時間、GC時並行處理、某些時候Collector所需時間更短、減少內存不足時觸發GC的次數、減少後台內存占用。

首先介紹下dalvik的gc的過程.主要有有四個過程:

1)當gc被觸發時候,其會去查找所有活動的對象,這個時候整個程序與虛擬機內部的所有線程就會掛起,這樣目的是在較少的堆棧裡找到所引用的對象.需要注意的是這個回收動作是和應用程序同時執行(非並發).

2)gc對符合條件的對象進行標記

3)gc對標記的對象進行回收

4)恢復所有線程的執行現場繼續運行

dalvik這麼做的好處是,當pause了之後,gc勢必是相當快速的.但是如果出現gc頻繁並且內存吃緊勢必會導致ui卡頓,掉幀.操作不流暢等.

後來art改善了這種gc方式(也是想對ui流暢度做貢獻,當然關於ui流暢,5.0以上了新的並行ui線程),主要的改善點在將其非並發過程改變成了部分並發.還有就是對內存的重新分配管理

當art gc發生時:

1)gc將會鎖住java堆,掃描並進行標記

2)標記完畢釋放掉java堆的鎖,並且掛起所有線程

3)gc對標記的對象進行回收

4)恢復所有線程的執行現場繼續運行

5)重復2-4直到結束

可以看出整個過程做到了部分並發使得時間縮短.據官方測試數據說gc效率提高2倍。

三.更多資料

1.Dalvik虛擬機簡要介紹和學習計劃：

http://blog.csdn.net/luoshengyang/article/details/8852432