リンクします。https：//www.zhihu.com/question/20207106/answer/14654536
出典：ほとんど知っている
著者が著作権を保有。商業転載は非商用の転載は、ソースを明記してください、権限の作者に連絡してください。
謝は、申し訳ありませんが、それはこの質問に答えるためにとても時間がかかった、招待しました。
実際には、コアの違いは、のDalvik仮想マシン・アーキテクチャはアーキテクチャのつまり、違い、スタックベースされているSun JDKとは異なり、ベースレジスタであるということです。私は原作者または請求項あれば、情報は、誰にその作者をマークすることは不可能である、いくつかの転載、転送および処理後、インターネット上でこれらのデータから、原作者は不明で、いくつかの段落では、オンラインで見つけ、およびレイアウトを少し並べ替えることができます抽出したいです質問は、私はタイムリーにお知らせください。
情報の一部は、
特別提供元のリンク：
HTTP：// rednaxelafx.iteye.com/bのログ/ 492 667
（1）のDalvik VMと第一の違いは、JVMは、スタックマシン（スタックベース）であるJVMのDalvik VMは、レジスタベースのアーキテクチャ（REGベース）です。利点は、より良い事前に最適化され行うことができますベースのVM（アヘッドのタイム最適化）をreg 。VMに基づいて、付加REGに高速に実行するが、大きなコードサイズを犠牲に。
（2）もう一つの違いは、のDalvikは、すべてのAndroidアプリVMで実行されているとは無関係であることを意味し、複数のインスタンスを実行することができます。この方法の利点は、アプリケーションのクラッシュでは影響しないだろう、だけでVM自体に影響を与えるということです他の人に。Dalvik VMのそれぞれは、以下のLinuxプロセスであるためのDalvikに設計されています。これは、効率的なIPCが必要です。各VMのもう一つの利点は、動的に有効/他のVMに影響を与えることなく、独自のVMが非アクティブすることができますのみを実行している
（3）次に、著作権に関する議論などがあります。（また、記事の下参照）
REGベースのVMので、非常に多くの利点がありますが、なぜ人々の前にJAVAのデザインではなく、それを使用してのベースREGベースのスタックを使用していませんでしたか？VMベースのオリジナルスタックはまた、その利点を持っている、それはREGホストプラットフォームの数ではない別のプラットフォームへの移植に仮定を助長します。それは常に、このようなARM設計などのマルチREGプラットフォームとなっているためのDalvikは、これらを気にしません。またのDalvikはまたしても、このREGまれのx86プラットフォームでは、VMベースのREGも問題ありません、ということを示すのx86に移植されています。
DVMで話すの次のハイライト利点:(私は黒の強調表示するいくつかのテキストを追加しました）
1、コンパイル時に事前にコードを最適化するのではなく、実行時まで待っ
2、仮想マシンが使用するスペースも小さくて、非常に小さく、効率的に実行を満たすように設計複数の仮想マシンインスタンス。
3、定数プールは、インタプリタを簡単にするために、唯一の32ビットのインデックスを使用するように改変されています
主にゼロアドレスの形式でJVMバイトコード、JVMの概念は、スタックベースのアーキテクチャであることを特徴とします。GoogleのAndroidプラットフォーム上のメインの開発言語アプリケーションのDalvik VMは、Javaプログラムを実行するために、そこを通って、Javaのです。正しいセマンティクスを達成するために、多くの設計は、JVMとのDalvik仮想マシンの互換性に取り込まれ、それがレジスタベースのアーキテクチャを使用し、それは主にバイトコードアドレス2/3つのアドレスの混合物の形態です。
スタックとレジスタベースのアーキテクチャに基づいて、誰が速いのですか？今実際のプロセッサ、主にベースのアーキテクチャレジスタは、実際のスタックベースのアーキテクチャよりもプロセッサに近い側から反射レジスタベース。しかし、VMのため、ソースアーキテクチャ評価スタックまたはレジスタが実際のハードウェアのパフォーマンスが異なる特性を有するように、実際のマシンのメモリをシミュレートするために使用されてもよいです。レジスタベースのアーキテクチャは、一般的にので、より効率的に実行スタックベースのアーキテクチャのJVMよりのDalvik VMと考えられる：ゼロアドレス命令は、よりコンパクトであるが、しかし、操作を完了する複数のロード/ストア命令を必要とし、また、より多くの命令ディスパッチを意味する（命令ディスパッチ）数とメモリアクセスの数、各命令は、より多くのスペースを占めますがアクセスメモリは、2または3アドレス命令アドレス重要なボトルネックの実行速度ですが、全体的に、あなたが操作を完了するために、少ない命令を使用することができ、及び命令ディスパッチメモリアクセス時間は少ないです。
私たちは、下のスクリーンショットから対応するJavaコードの同期間とDalvidバイトコードJavaバイトコードとの明確な比較を見ることができます：
いくつかのDalvikを議論するオンライン記事、速い実行速度よりも、主に簡単な言及のDalvik JVMが、やや少ないポータブル。ここでは、探索伸びています。、三つのステップ、命令ディスパッチを備え、VM命令インタプリタで実行されるオペランドにアクセスし、計算を実行します。その後、命令メモリからVM命令を読み込むための責任派遣（取扱説明書は派遣）、及び命令ディスパッチインタプリタコードにジャンプします。同じことを達成するために、上述したように、スタックベースの仮想マシンは、より多くの命令を必要とし、それはより多くの命令ディスパッチとのDalvik VMとして良いとしてJVMの実行パフォーマンス理由の一つであるメモリアクセスの数を意味します。
アクセスオペランドアクセス番号（オペランドアクセス）動作は、読み取りの数を指し、バックソース・オペランドとデスティネーション・オペランドに書き込みます。Dalvik VMは同様の血液ので、仮想オペランドレジスタオペランドを介してアクセスされる、理由のDalvik VM良好な性能でより完全にマッピングされた物理レジスタの利点とのDalvik仮想レジスタ、。オペランドは、JVMオペランドスタックによってアクセスが、命令は使用しないので、任意の一般的な目的は、仮想マシンに割り当てられ、比較的自由な実機レジスタ、ひいては高い移植性であることを登録します。最適化として、オペランドスタックは、データ移動のオーバーヘッドを低減するために、物理レジスタにコンパイラによってマッピングすることができます。命令実行（手順は計算）これは正直ライン上で実行、少し解釈のようです。命令実行
アプリケーションは、コンパイルが完了した後にクラスファイルは冗長な情報の多くになります間で、対応するクラスファイルがたくさんあるでしょう、クラスの多くを定義します。
全体的なファイルサイズを減少させることに加えて、I / O操作は、だけでなく、増加、ように、複数のファイルの中に構造の違いが統合されてDEXバイトコードを、標準のJavaバイトコードとバイトコード（クラス）DEXスピードクラスを検索します。
元のクラスファイルの定数プールのそれぞれについてDEXファイルの定数プールで管理されています。
DEXファイルをさらに最適化することができます。最適化は、次の側面を中心に次のとおりです。
図1に示すように、すべてのフィールドの調整エンディアン（LITTLE_ENDIAN）と位置合わせ構造がドメインではない
2、そのすべてのクラスDEXファイルベリファイ
3、最適化の特定のクラス、オペレーションコードに最適化する方法を
最適化されたファイルのサイズは、それが1-4倍DEXファイルである必要があり、増加します最適化します。ODEXはDEXファイルのさらなる最適化、さらに運転時のパフォーマンスを向上させることです
すべてのAndroidアプリケーションは、仮想マシン・インスタンスのDalvik仮想マシン・インスタンスで実行され、それぞれが別々のプロセス空間です。あなたは、各プロセス間（IPC、達成するためのバインダー機構）を通信することができます。仮想マシン、メモリの割り当てと管理、ミューテックスのスレッド機構とその基礎となるオペレーティング・システムの実装に依存しています。
別のプロセス空間で実行する異なるアプリケーションは、仮想マシンがオフになっているか、中止された他の仮想マシンには影響しません、アプリケーションがセキュリティや独立した動作を最大化することができます。
受精卵インキュベーター仮想マシンインスタンス。ZygoteInit.mainでAndroidRuntime.cpp（）は、分割の実装を完了し、破片サブ初期化プロセスは、Javaアーキテクチャレイヤ続け、この破片プロセスはsystem_serverあります。たびのシステム要件は、Androidアプリケーションの実装のために、受精卵は、アプリケーションを実行するための子プロセスをforkします。この利点は明白です：、システムの起動時に、それは仮想マシンの初期設定を完了します受精卵プロセスが生成され、ロードライブラリ、前負荷およびライブラリを初期化などの操作、およびシステムの新しい仮想マシンインスタンスの必要性とき、接合体は自分自身をコピーすることで、最速のシステムを提供します。また、いくつかの読み取り専用のシステムライブラリ、すべての仮想マシンインスタンスと受精卵は、メモリのオーバーヘッドを節約し、メモリ領域を共有しています。
=============================分割ライン=================== ========
ここで私は単純に、このアーキテクチャの違いとJVMが生成され、DVMの影響を説明し、私の知識をまとめます
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 -ように、異なるアプリケーション間で共有機構、実行時に、同じクラスを共有するが、一般的に、システムリソースの消費の点で、より高い効率を有します。