Dalvik虛擬機和JVM的對比

　　Dalvik虛擬機與Java虛擬機有着不少類似的特性，都支持GC，JIT，JNI等等。其主要區別在於文件格式以及指令集不一樣，下面對二者的特性進行比較與討論。

Difference1:文件格式

　　Dalvik的虛擬機類文件採用dex格式，而JVM的類文件是class格式。不一樣之處在於，咱們熟悉的class字節碼文件中只包含一個類，而dex文件中能夠包含多個類。其好處在於多個類中重複的常數和字符串只會保存一份，必定程度上節省了空間，更適於在手機上運行。

Difference2：指令集

　　Dalvik的指令集基於寄存器，而JVM的指令集基於堆棧。不一樣之處在於，基於寄存器的指令在寄存器中尋址，速度更快但指令長度長；基於堆棧的指令集更短，但佔用CPU時間較多。其對比相似於CISC與RISC的對比。從移植性而言，顯然基於堆棧的指令集可移植性更好，它不針對目標機器的寄存器作任何優化。而基於寄存機的指令集能夠再程序運行以前針對目標機器的寄存器對程序進行優化，這種優化是在編譯過程當中的優化，並不是相似於JIT在運行過程當中的動態優化，但最終目標都是將程序轉化成本地機器語言。

 

　　下面，針對Dalvik虛擬機的內存管理，JIT，垃圾收集、JIT、JNI以及進程和線程管理進行討論。

內存管理

　　Dalvik虛擬機的內存大致上能夠分爲三個部分：Java Object Heap、Bitmap Memory和Native Heap。

Java Object Heap用來存放Java對象，不一樣手機廠商對其大小有不一樣的設置，能夠經過ActivityManager的getMemoryClass獲取其最大值，該值是Android應用所能使用的最大內存。

Bitmap Memory用於存放和處理圖片。在Android3.0以前，Bitmap Memory是Native Heap的一部分，其大小計入Java Object Heap，即bitmap和其餘java對象所佔用的內存不能超過上面JOH的最大值。在Android3.0以後，Bitmap Memory直接在JOH中分配，便於GC。

Native Heap是本地機器語言申請分配的內存。

垃圾回收

　　在Android2.3以前的版本中，Dalvik虛擬機的垃圾回收策略以下：

• 垃圾收集線程在執行的時候，其它的線程都中止，從而一次收集徹底部的垃圾，這樣致使的結果就是一次垃圾收集形成的程序停止時間一般都大於100ms。
• 在Android2.3以後，垃圾收集線程與其它線程是併發執行，一次可能只收集一部分垃圾，使得一次垃圾收集形成的程序停止時間大大下降，一般都小於5ms。

JIT

　　JIT是在程序運行的過程當中進行編譯，將反覆調用的代碼轉化爲本地機器碼保存起來，這個過程是在運行時動態執行的，相對於程序編譯時的優化而言，JIT會佔用程序運行時間。Android2.2以後纔開始支持JNI。

本地調用

　　Java程序運行在虛擬機上，須要將程序翻譯成目標機器的指令來執行，有些功能須要調用目標機器操做系統接口來完成。Java的本地調用能夠幫助咱們在Java代碼和C\C++代碼中互相調用函數。Android提供了NDK來幫助咱們實現JNI。

線程管理

　　Android的進程主要有兩個特色：

• 每個Android APP進程都有一個Dalvik虛擬機實例，這保證了多個app在運行時互不影響。
• 每個Android應用程序進程都是由一種Zygote的進程fork出來的。而Zygote進程是由初始化進程創造出來的。Zygote進程在啓動的時候，會建立一個虛擬機實例，而且在這個虛擬機實例將全部的Java核心庫都加載起來。每當Zygote進程須要建立一個Android應用程序進程的時候，它就經過複製自身來實現，也就是經過fork系統調用來實現。這些被fork出來的Android應用程序進程，一方面是複製了Zygote進程中的虛擬機實例，另外一方面是與Zygote進程共享了同一套Java核心庫。這樣不只Android應用程序進程的建立過程很快，並且因爲全部的Android應用程序進程都共享同一套Java核心庫而節省了內存空間。