Android面試收集錄13 Android虛擬機器及編譯過程

標籤：span   提高   strong   run   片段化   arch   記憶體回收   複製   常量   

 

一、什麼是Dalvik虛擬機器

Dalvik是Google公司自己設計用於Android平台的Java虛擬機器，它是Android平台的重要組成部分，支援dex格式（Dalvik Executable）的Java應用程式的運行。dex格式是專門為Dalvik設計的一種壓縮格式，適合記憶體和處理器速度有限的系統。Google對其進行了特定的最佳化，使得Dalvik具有高效、簡潔、節省資源的特點。從Android系統架構圖知，Dalvik虛擬機器運行在Android的執行階段程式庫層。

Dalvik作為面向Linux、為嵌入式作業系統設計的虛擬機器，主要負責完成對象生命週期管理、堆棧管理、線程管理、安全和異常管理，以及記憶體回收等。另外，Dalvik早期並沒有JIT編譯器，直到Android2.2才加入了對JIT的支援人員。

 

 

二、Dalvik虛擬機器的特點

體積小，佔用記憶體空間小；

專有的DEX可執行檔格式，體積更小，執行速度更快；

常量池採用32位索引值，定址類方法名，欄位名，常量更快；

基於寄存器架構，並擁有一套完整的指令系統；

提供了對象生命週期管理，堆棧管理，線程管理，安全和異常管理以及記憶體回收等重要功能；

所有的Android程式都運行在Android系統進程裡，每個進程對應著一個Dalvik虛擬機器執行個體。

 

 

三、Dalvik虛擬機器和Java虛擬機器的區別

Dalvik虛擬機器與傳統的Java虛擬機器有著許多不同點，兩者並不相容，它們顯著的不同點主要表現在以下幾個方面：

Java虛擬機器啟動並執行是Java位元組碼，Dalvik虛擬機器啟動並執行是Dalvik位元組碼。

傳統的Java程式經過編譯，產生Java位元組碼儲存在class檔案中，Java虛擬機器通過解碼class檔案中的內容來運行程式。而Dalvik虛擬機器啟動並執行是Dalvik位元組碼，所有的Dalvik位元組碼由Java位元組碼轉換而來，並被打包到一個DEX（Dalvik Executable）可執行檔中。Dalvik虛擬機器通過解釋DEX檔案來執行這些位元組碼。

Dalvik可執行檔體積小。Android SDK中有一個叫dx的工具負責將Java位元組碼轉換為Dalvik位元組碼。

dx工具對Java類檔案重新排列，消除在類檔案中出現的所有冗餘資訊，避免虛擬機器在初始化時出現反覆的檔案載入與解析過程。一般情況下，Java類檔案中包含多個不同的方法簽名，如果其他的類檔案引用該類檔案中的方法，方法簽名也會被複製到其類檔案中，也就是說，多個不同的類會同時包含相同的方法簽名，同樣地，大量的字串常量在多個類檔案中也被重複使用。這些冗餘資訊會直接增加檔案的體積，同時也會嚴重影響虛擬機器解析檔案的效率。消除其中的冗餘資訊，重新組合形成一個常量池，所有的類檔案分享權限設定同一個常量池。由於dx工具對常量池的壓縮，使得相同的字串，常量在DEX檔案中只出現一次，從而減小了檔案的體積。

針對每個Class檔案，都由如下格式進行組成：

dex格式檔案使用共用的、特定類型的常量池機制來節省記憶體。常量池儲存類中的所有字面常量，它包括字串常量、欄位常量等值。

簡單來講，dex格式檔案就是將多個class檔案中公有的部分統一存放，去除冗餘資訊。

**Java虛擬機器與Dalvik虛擬機器架構不同。**這也是Dalvik與JVM之間最大的區別。

Java虛擬機器基於棧架構，程式在運行時虛擬機器需要頻繁的從棧上讀取或寫入資料，這個過程需要更多的指令指派與記憶體訪問次數，會耗費不少CPU時間，對於像手機裝置資源有限的裝置來說，這是相當大的一筆開銷。Dalvik虛擬機器基於寄存器架構。資料的訪問通過寄存器間直接傳遞，這樣的訪問方式比基於棧方式要快很多。

 

四、Dalvik虛擬機器的結構

一個應用首先經過DX工具將class檔案轉換成Dalvik虛擬機器可以執行的dex檔案，然後由類載入器載入原生類和Java類，接著由解譯器根據指令集對Dalvik位元組碼進行解釋、執行。最後，根據dvm_arch參數選擇編譯的目標機體繫結構。

 

五、Android APK 編譯打包流程

1.Java編譯器對工程本身的java代碼進行編譯，這些java代碼有三個來源：app的原始碼，由資源檔產生的R檔案(aapt工具)，以及有aidl檔案產生的java介面檔案(aidl工具)。產出為.class檔案。

①.用AAPT編譯R.java檔案

②編譯AIDL的java檔案

③把java檔案編譯成class檔案

2..class檔案和依賴的三方庫檔案通過dex工具產生Delvik虛擬機器可執行檔.dex檔案，包含了所有的class資訊，包括項目自身的class和依賴的class。產出為.dex檔案。

3.apkbuilder工具將.dex檔案和編譯後的資源檔產生未經簽名對齊的apk檔案。這裡編譯後的資源檔包括兩部分，一是由aapt編譯產生的編譯後的資源檔，二是依賴的三方庫裡的資源檔。產出為未經簽名的.apk檔案。

4.分別由Jarsigner和zipalign對apk檔案進行簽名和對齊，產生最終的apk檔案。

總結為：編譯-->DEX-->打包-->簽名和對齊

 

六、ART虛擬機器與Dalvik虛擬機器的區別什麼是ART:

ART代表Android Runtime，其處理應用程式執行的方式完全不同於Dalvik，Dalvik是依靠一個Just-In-Time (JIT)編譯器去解釋位元組碼。開發人員編譯後的應用代碼需要通過一個解譯器在使用者的裝置上運行，這一機制並不高效，但讓應用能更容易在不同硬體和架構上運 行。ART則完全改變了這套做法，在應用安裝時就先行編譯位元組碼到機器語言，這一機制叫Ahead-Of-Time (AOT）編譯。在移除解釋代碼這一過程後，應用程式執行將更有效率，啟動更快。

ART優點：

1. 系統效能的顯著提升。
2. 應用啟動更快、運行更快、體驗更流暢、觸感反饋更及時。
3. 更長的電池續航能力。
4. 支援更低的硬體。

ART缺點：

1. 更大的儲存空間佔用，可能會增加10%-20%。
2. 更長的應用安裝時間。

ART虛擬機器相對於Dalvik虛擬機器的提升

先行編譯

在dalvik中,如同其他大多數JVM一樣,都採用的是JIT來做及時翻譯(動態翻譯),將dex或odex中並排的dalvik code(或者叫smali指令集)運行態翻譯成native code去執行.JIT的引入使得dalvik提升了3~6倍的效能。

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

記憶體回收機制

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

1. 當gc被觸發時候,其會去尋找所有活動的對象,這個時候整個程式與虛擬機器內部的所有線程就會掛起,這樣目的是在較少的堆棧裡找到所引用的對象.需要注意的是這個回收動作和應用程式非並發。
2. gc對合格對象進行標記
3. gc對標記的對象進行回收
4. 恢複所有線程的執行現場繼續運行

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

後來ART改善了這種GC方式 , 主要的改善點在將其非並發過程改變成了部分並發.還有就是對記憶體的重新分配管理。

當ART GC發生時:

1. GC將會鎖住Java堆,掃描並進行標記
2. 標記完畢釋放掉Java堆的鎖,並且掛起所有線程
3. GC對標記的對象進行回收
4. 恢複所有線程的執行現場繼續運行
5. 重複2-4直到結束

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

提高記憶體使用量，減少片段化

Dalvik記憶體管理特點是:記憶體片段化嚴重，當然這也是Mark and Sweep演算法帶來的弊端

可以看出每次gc後記憶體千瘡百孔，本來連續分配的記憶體塊變得片段化嚴重，之後再分配進入的對象再進行記憶體定址變得困難。

ART的解決:在ART中,它將Java分了一塊空間命名為Large-Object-Space,這塊記憶體空間的引入用來專門存放large object。同時ART又引入了moving collector的技術,即將不連續的實體記憶體塊進行對齊.對齊了後記憶體片段化就得到了很好的解決.Large-Object-Space的引入一是因為moving collector對大塊記憶體的位移時間成本太高,而且提高記憶體的利用率 根官方統計，ART的記憶體利用率提高10倍了左右。

 

七、參考文章

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

 

Android面試收集錄13 Android虛擬機器及編譯過程