簡單理解Android Dalvik、ART及APK編譯過程

在學習Android之前,都學習了Java,對于Java虛擬機都或多或少的進行了了解。那么Android中的虛擬機是個什么樣子,一個APK的編譯過程又是什么,就讓我們來看看。

一、什么是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虛擬機的提升

參考: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倍了左右。

參考文章:

理解Android虛擬機體系結構
深入理解Android(二):Java虛擬機Dalvik
Android編譯流程和Gradle使用
art和dalvik的區別?
深入理解Android工程的編譯過程

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,345評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,494評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,283評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,953評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,714評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,186評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,255評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,410評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,940評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,776評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,976評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,518評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,210評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,642評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,878評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,654評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,958評論 2 373

推薦閱讀更多精彩內容