java虛擬機安卓
『壹』 java虛擬機和安卓虛擬機有什麼區別
在Android的體系框架中有一部分叫做Android Runtime,即Android運行時環境，這個環境包括了兩個部分，一個是Android的核心類庫，還有一個就是Dalvik虛擬機了。
Android之所以開發Dalvik虛擬機而不使用JAVA自帶的JVM是出於以下兩點考慮(個人認為，不代表廣泛意義)：
1.版權問題，如果使用JVM就涉及到了版權問題，所以google需要在JVM的基礎上做一些改進，創造自己的虛擬機。
2.性能問題。當然jvm虛擬機對Java開發來說性能已經足夠了，但是相對移動平台的特性，比如低內存，低電量等，就顯得有些牽強了，所以為了優化虛擬機的工作效率，google開發了android自己的虛擬機。
下面說下2者的區別：
1、jvm是吧.java文本編譯成.class位元組碼文件，在執行java程序的時候，類載入器把需要的類全部載入到內存當中去。davik虛擬機把.java文件編譯成.class文件，又把.class文件轉換成.dex文件，dalvik來執行.dex文件。實際上.dex文件就是把多個class文件中的常量、方法等放到一起。
2、在架構上jvm是基於棧的架構，所以每次訪問數據cpu都要到內存中取到數據。而dalvik是基於寄存器的架構。寄存器是在cpu上的一塊存儲空間，cpu如果直接從寄存器上讀取數據的話就會快很多。
『貳』 安卓系統是運行在java虛擬機上的這句話 什麼意思
安卓底層是C寫的，即linux內核，應用層是java語言寫的，而我們都知道，java程序是運行在虛擬機上的，安卓程序也是java程序，它也是運行在虛擬機上，這個虛擬機就是安卓的應用層驅動程序
『叄』 關於安卓的java虛擬機是什麼概念！！！百度寫的太專業了！！！求解
恩，安卓的性能是在提升，但有上限，再怎麼提升，軟體也是運行在虛擬機上，代碼也要經過位元組碼裝載，進行校驗，才能轉換成機器碼執行（這三個步驟都消耗時間、CPU和內存資源），即使開了JIT，也只是部分編譯成機器碼存起來。並且內存的垃圾回收機制，雖然對開發者來說省了事，但卻維持這種回收機制也要耗資源。當然，也有優點，使用虛擬機，這對於跨平台來說，確實是很有益的。
『肆』 Android java虛擬機和sun java虛擬機區別
(1) Dalvik VM和JVM 的第一個區別是 Dalvik VM是基於寄存器的架構（reg based），而JVM是棧機（stack based）。reg based VM的好處是可以做到更好的提前優化（ahead-of-time optimization）。 另外reg based的VM執行起來更快，但是代價是更大的代碼長度。
(2) 另外一個區別是Dalvik可以允許多個instance 運行，也就是說每一個Android 的App是獨立跑在一個VM中.這樣做的好處是一個App crash只會影響到自身的VM，不會影響到其他。 Dalvik的設計是每一個Dalvik的VM都是Linux下面的一個進程。那麼這就需要高效的IPC。另外每一個VM是單獨運行的好處還有可以動態active/deactive自己的VM而不會影響到其他VM
(3) 接下來就是關於版權之類爭論。（可以參看下面文章）
既然reg based VM有那麼多好處，為什麼之前設計JAVA的人沒有採用reg based而是採用stack based的呢？ 原來stack based的VM也有其優點，就是它不對host平台的reg數量做假設，有利於移植到不同的平台。而Dalvik則不關心這些，因為它本來就是為ARM這樣的多reg平台設計的。另外Dalvik被移植到x86也說明，即使是x86這種reg很少的平台，reg based的VM也是沒有問題的。
下面著重說下DVM的優勢：（部分文字我加黑以突出）
1、在編譯時提前優化代碼而不是等到運行時
2、 虛擬機很小，使用的空間也小；被設計來滿足可高效運行多種虛擬機實例。
3、常量池已被修改為只使用32位的索引，以 簡化解釋器
JVM 的位元組碼主要是零地址形式的，概念上說JVM是基於棧的架構。Google Android平台上的應用程序的主要開發語言是Java，通過其中的Dalvik VM來運行Java程序。為了能正確實現語義，Dalvik VM的許多設計都考慮到與JVM的兼容性；但它卻採用了基於寄存器的架構，其位元組碼主要是二地址/三地址的混合形式。
基於棧與基於寄存器的 架構，誰更快？現在實際的處理器，大多都是基於寄存器的架構，從側面反映出基於寄存器比基於棧的架構更與實際的處理器接近。但對於VM來說，源架構的求值 棧或者寄存器都可能是用實際機器的內存來模擬的，所以性能特性與實際硬體又有不同。一般認為基於寄存器架構的Dalvik VM比基於棧架構JVM執行效率更高，原因是：雖然零地址指令更緊湊，但完成操作需要更多的load/store指令，也意味著更多的指令分派 （instruction dispatch）次數與內存訪問次數；訪問內存是執行速度的一個重要瓶頸，二地址或三地址指令雖然每條指令占的空間較多，但總體來說可以用更少的指令完 成操作，指令分派與內存訪問次數都較少。
我們從下面的截圖可以明了的看到與同一段Java代碼對應的Java bytecode 與Dalvid bytecode的比較：
JVM其核心目的，是為了構建一個真正跨OS平台，跨指令集的程序運行環境（VM）。DVM的目的是為了將android OS的本地資源和環境，以一種統一的界面提供給應用程序開發。嚴格來說，DVM不是真正的VM，它只是開發的時候提供了VM的環境，並不是在運行的時候提供真正的VM容器。這也是為什麼JVM必須設計成stack-based的原因。
JVM：所有的jar程序，其運行環境完全是由JVM來提供，包括運行時，各類資源的調度，而JVM的架構，其設計為一個JVM裡面可以運行多個java程序，JVM就像一個真正的「機器」，可以跑著多個程序。如果去看看一些企業級的JVM（例如tom cat，WAS），從OS的進程管理中，一般你只能看見一個JVM的進程（當然，你也可以起多個JVM，但JVM架構就是OS-JVM-APP的3層運行時模式），而看不見JVM裡面運行的程序，而一個JVM里，可以跑多個java app。簡單得說，JVM完全屏蔽了應用程序和OS之間的聯系，而改用JVM充當了中間層，這也是一個真正跨平台運行時VM必須要做到的。只要是相同的JDK，JVM為所有在其中運行的程序，提供了完全一致的運行環境，而不論你是什麼樣的底層OS和硬體條件。因此這也是我在其他一篇答案中提到，JVM的特點是取底層OS和硬體環境的交集，從而保障這種一致性。而所有應用程序和底層資源的互動，一定是依賴JVM的傳遞和轉換來實現。JVM真正實現了一個OS對應用程序運行時管理的所有功能。從開發環境角度和運行時角度，都是完全一致的真正VM
DVM：而DVM的特點在於使用了Zygote，Zygote有幾個非常有意思的特點。
一是Zygote採用預載入，由其首先判定安裝的APK的需要以及相互依存樹，以及OS及硬體環境的特點，在每次啟動的時候進行預載入（現在你明白為什麼android的app在應用管理里你能輕易查到它都調用了那些關鍵性的本地資源的原因了吧？），這就意味著，你安裝的應用越多，Zygote的載入就越慢，一般來說你的手機啟動就會越慢。另外來說，在不同的硬體環境里（例如有無GPS晶元）Zygote初始化的實例是不同的。也就是說，zygote並不提供一個統一的運行環境，具有更好的彈性，這種機制意味著DVM可以取底層資源的合集來提供上層應用使用，差別只是在程序安裝或者啟動的過程中，DVM可以提示程序需求資源，本地環境可能未能滿足而導致無法運行。DVM的Zygote並不是提供一個運行時容器，它提供的只是一個用於共享的進程，所有的應用程序運行，都是獨立的，OS級別的進程，直接受到OS層面的資源控制以及調度的影響，只是他們共享Zygote說預載入的類而已。這也就是我為什麼說，DVM就像是給每個應用程序在底層加了個套子，而不是提供了一個真正的運行時的VM。也就是說，DVM在開發環境中說提供的VM平台，和運行時的環境是很有可能不一致的。開發環境中提供的VM平台，是一個各種運行時可能環境的合集。
從這點上來說，一般我們認為，JVM中的JAVA程序的崩潰，最多導致JVM的崩潰，而不會導致OS崩潰，但是apk的崩潰，可以直接導致OS崩潰，android手機會因為應用程序死機，大家應該是很常見了。但是大家一般是不會看到java程序導致死機吧？因為運行時中間隔著一個JVM。（當然，其實還是有些小門道可以用java程序讓OS崩潰，因為這個，我和某些JAVA大拿打賭贏過飯局，呵呵，不過這是其他話題，不在這里展開了）
除此之外，在JVM的機制中，不同的程序，打包以後，他們都是在運行層級真正獨立的程序（指程序應用他們相互之間的關系，而不是和JVM的關系），即便他們在包里使用了同樣的類，運行時都是單獨載入，單獨運行的（及載入多遍）。
DVM這種預載入-共享的機制，使得不同應用之間，在運行時，是共享相同的類的，一般來說，在系統資源消耗方面，擁有更高的效率。
最後，補充一點，byte code並不意味著就是解釋執行，也能是載入編譯，安裝編譯，預編譯等等。實際上，不同的byte code的程序，不同的技術，不同的具體語言，其真正執行的情況是挺復雜，難以一概而論的，好多都是混合技術的案例，從我對odex的技術來看，就是個典型案例。
『伍』 android的java虛擬機有哪些
之前用過BlueStacks ，現在用 海馬玩模擬器