dexoptとdex2oatの違いは？
GoogleはDalvikからART（Android Runtime）に移行しています。
パフォーマンスを改善する方法を理解しようとしていました。
私が見つけた最良の説明は以下の画像です：
変更された主なコンポーネントの1つは、dexoptからdex2oat。
私はこれらについてあまり考えていないので、誰が違いを説明でき、これがパフォーマンスを改善する方法を説明できますか？
dexoptは、dexファイルに対していくつかの最適化を行います。仮想呼び出し命令を、呼び出されるメソッドのvtableインデックスを含む最適化されたバージョンに置き換えるなどのことを実行するため、実行中にメソッドルックアップを実行する必要がありません。
Dexoptの結果はodex（最適化されたdex）ファイルです。これは、最適化された仮想呼び出しのような最適化されたオペコードを使用することを除いて、元のdexファイルと非常に似ています。
dex2oatは、dexファイルを取得してコンパイルします。結果は基本的にelfファイルで、ネイティブに実行されます。そのため、仮想マシンで解釈されるバイトコードを使用する代わりに、プロセッサでネイティブに実行できるネイティブコードを使用できるようになりました。これはAOT（ahead-of-time）コンパイルと呼ばれます。
通常、両方のツールは デバイスへのインストール時 で実行されます。
考慮すべきもう1つの要因は、dalvikがJIT（ジャストインタイム）コンパイラを使用したことです。つまり、バイトコードをネイティブコードにコンパイルすることもできました。主な違いは、ARTはすべてを事前にコンパイルするのに対して、dalvikはヒューリスティックを使用してバイトコードのサブセットのみをコンパイルし、最も頻繁に実行されるコードを検出し、実行中にコンパイルすることです。
Androidランタイム（ART）は、Androidモバイルオペレーティングシステムで使用されるアプリケーションランタイム環境です。ARTは、Androidが最初に使用したプロセス仮想マシンであるDalvikを置き換えます。アプリケーションのバイトコードのネイティブ命令への変換を実行し、デバイスのランタイム環境によって後で実行されます。
Android 2.2 "Froyo"はジャストインタイム（JIT）コンパイルを使用して、アプリケーションが起動されるたびにバイトコードをコンパイルするため、Dalvikとは異なり、ARTは事前（ AOT）アプリケーションのインストール時に実行するコンパイル。アプリケーションの操作全体で実行する必要があるコンパイルの全体量を削減することにより、モバイルデバイスのプロセッサ使用量が削減され、バッテリランタイムが改善されます。 ARTは、パフォーマンス、ガベージコレクション、アプリケーションのデバッグとプロファイリングの改善をもたらします。
下位互換性を維持するために、ARTはAPKファイルの一部として標準の.dexファイルを通じて提供されるDalvikと同じ入力バイトコードを使用し、.odexファイルは実行可能およびリンク可能形式（ELF）実行可能ファイルに置き換えられますARTのデバイス上のdex2oatユーティリティを使用してアプリケーションをコンパイルすると、コンパイルされたELF実行可能ファイルからのみ実行されます。このアプローチにより、JITコンパイルに伴うさまざまなオーバーヘッドがなくなりますが、アプリケーションのインストール時にコンパイルに追加の時間が必要になり、アプリケーションはコンパイルされたコードを格納するためにわずかに大きなスペースを占有します。