Android 虛擬機學習總結Dalvik虛擬機介紹

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

2、Dalvik虛擬機使用的指令是基於寄存器的，而Java虛擬機使用的指令集是基於堆棧的。基於堆棧的指令很緊湊，例如，Java虛擬機使用的指令只占一個字節，因而稱為字節碼。基於寄存器的指令由於需要指定源地址和目標地址，因此需要占用更多的指令空間，例如，Dalvik虛擬機的某些指令需要占用兩個字節。基於堆棧和基於寄存器的指令集各有優劣，一般而言，執行同樣的功能，前者需要更多的指令（主要是load和store指令），而後者需要更多的指令空間。需要更多指令意味著要多占用CPU時間，而需要更多指令空間意味著數據緩沖（d-cache）更易失效。

 

3、此外，還有一種觀點認為，基於堆棧的指令更具可移植性，因為它不對目標機器的寄存器進行任何假設。然而，基於寄存器的指令由於對目標機器的寄存器進行了假設，因此，它更有利於進行AOT（ahead-of-time）優化。 所謂AOT，就是在解釋語言程序運行之前，就先將它編譯成本地機器語言程序。AOT本質上是一種靜態編譯，它是是相對於JIT而言的，也就是說，前者是在程序運行前進行編譯，而後者是在程序運行時進行編譯。運行時編譯意味著可以利用運行時信息來得到比較靜態編譯更優化的代碼，同時也意味不能進行某些高級優化，因為優化過程太耗時了。另一方面，運行前編譯由於不占用程序運行時間，因此，它就可以不計時間成本來優化代碼。無論AOT，還是JIT，最終的目標都是將解釋語言編譯為本地機器語言，而本地機器語言都是基於寄存器來執行的，因此，在某種程度來講，基於寄存器的指令更有利於進行AOT編譯以及優化。

4、不管結論如何，Dalvik虛擬機都在盡最大的努力來優化自身，這些措施包括：

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

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

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

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

（5） 需要重寫字節碼的優化要提前進行。

 

5、內存管理

 

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的最大值也就是我們平時所說的Android應用程序進程能夠使用的最大內存。這裡必須要注意的是，Android應用程序進程能夠使用的最大內存指的是能夠用來分配Java Object的堆。

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

 

Native Heap就是在Native Code中使用malloc等分配出來的內存，這部分內存是不受Java Object Heap的大小限制的，也就是它可以自由使用，當然它是會受到系統的限制。但是有一點需要注意的是，不要因為Native Heap可以自由使用就濫用，因為濫用Native Heap會導致系統可用內存急劇減少，從而引發系統采取激進的措施來Kill掉某些進程，用來補充可用內存，這樣會影響系統體驗。

6、垃圾收集

Dalvik虛擬機可以自動回收那些不再使用了的Java Object，也就是那些不再被引用了的Java Object。垃圾自動收集機制將開發者從內存問題中解放出來，極大地提高了開發效率，以及提高了程序的可維護性。

 

在GingerBread以及更高的版本中，Dalvik虛擬使用的垃圾收集機制得到了改進，如下所示：

（1） Cocurrent，也就是大多數情況下，垃圾收集線程與其它線程是並發執行的；

（2）Partial collection，也就是一次可能只收集一部分垃圾；

（3）一次垃圾收集造成的程序中止時間通常都小於5ms。

 

 

7、進程和線程管理

一般來說，虛擬機的進程和線程都是與目標機器本地操作系統的進程和線程一一對應的，這樣做的好處是可以使本地操作系統來調度進程和線程。進程和線程調度是操作系統的核心模塊，它的實現是非常復雜的，特別是考慮到多核的情況，因此，就完全沒有必要在虛擬機中提供一個進程和線程庫。

 

Dalvik虛擬機運行在Linux操作系統之上。我們知道，Linux操作系統並沒有純粹的線程概念，只要兩個進程共享同一個地址空間，那麼就可以認為它們同一個進程的兩個線程。Linux操作系統提供了兩個fork和clone兩個調用，其中，前者就是用來創建進程的，而後者就是用來創建線程的。

 

關於Android應用程序進程，它有兩個很大的特點，下面我們就簡要介紹一下。

 

第一個特點是每一個Android應用程序進程都有一個Dalvik虛擬機實例。這樣做的好處是Android應用程序進程之間不會相互影響，也就是說，一個Android應用程序進程的意外中止，不會影響到其它的Android應用程序進程的正常運行。

 

第二個特點是每一個Android應用程序進程都是由一種稱為Zygote的進程fork出來的。Zygote進程是由init進程啟動起來的，也就是在系統啟動的時候啟動的。Zygote進程在啟動的時候，會創建一個虛擬機實例，並且在這個虛擬機實例將所有的Java核心庫都加載起來。每當Zygote進程需要創建一個Android應用程序進程的時候，它就通過復制自身來實現，也就是通過fork系統調用來實現。這些被fork出來的Android應用程序進程，一方面是復制了Zygote進程中的虛擬機實例，另一方面是與Zygote進程共享了同一套Java核心庫。這樣不僅Android應用程序進程的創建過程很快，而且由於所有的Android應用程序進程都共享同一套Java核心庫而節省了內存空間。

 

摘至：http://blog.csdn.net/luoshengyang/article/details/8852432