ARTはインストールプロセスですか？またはOS？または仮想マシン？
Androidランタイムを理解しようとすると、 ウィキペディアページ に出くわしました。そこに表示されているグラフィックは混乱を招きます。dexが完全にELFに変換されている場合、その理由は何ですか。 ARTはもう必要ですか？
ARTのオンデバイスを使用してアプリケーションをコンパイルしたら
dex2oatユーティリティ、コンパイルされたELF実行可能ファイルからのみ実行されます。その結果、ARTは、Dalvikの解釈とトレースベースのJITコンパイルに関連するさまざまなアプリケーション実行のオーバーヘッドを排除します。
ARTは.dexをELFに変換し、コードはネイティブで実行する必要があることを理解しています。 ELFでは、仮想マシンはまだ関与していますか？ ARTでは、Androidアプリケーションスタックは次のようになります-
Android Apps
-----
ART (executing ELF)
-----
Linux
私はこれを正しく理解していますか？ ARTをELFed Androidアプリにサービスを提供するOSと見なす必要がありますか？
OATファイルはELFファイルですが、エントリポイントを含むすべてが含まれている通常の実行可能ELFではありません。実際には、コンパイルされたメソッドの実行可能コードを含むバイナリblobの始まりと終わりにある少数のシンボルがあります。ここで、どのメソッドを呼び出す必要があるか、またはいつ呼び出すかはすべてランタイムによって決定されます。
すべての仕組み-クラスがロードされます。そのクラスであるJavaオブジェクトを表すC++オブジェクトがあります。次に、そのクラスのインスタンスが作成されます。これは別のC++オブジェクトです。そのオブジェクトのメソッドが呼び出されるよりも。オブジェクトのクラスを見つけて、メソッドのエントリポイント（コンパイルされたコード）を見つけます。そのコードは他のメソッドを呼び出します。そのため、ランタイムコードに戻り、別のオブジェクトとそのクラスを見つけて、新しいメソッドを再度呼び出します。直接の呼び出しはありません。メソッド間（私が知っている）。
このすべてのリンクと解決は、実際には各アプリケーションの起動時に行われます。 Bootclasspathのものは一度初期化されてから、プロセスがフォークされるため、子はbootclasspathを再初期化する必要がありません（実際にはboot.artのため、それよりも少し複雑です）。
したがって、ARTは依然としてJVMであり、OATファイルはプリコンパイルされたコードの中間表現にすぎません。それらがELFファイルであるという事実はあまり役に立ちません-他の何かかもしれません。
追伸実際にOATファイルには、作成に使用されたすべてのDEXファイルも含まれています。クラスとメソッドを構築するために必要です。アプリケーションが実際にDEX命令を直接実行するときに、アプリケーションをインタプリタモードで実行することもできます。
ARTはAndroidランタイムであり、Dalvikバイトコードをネイティブマシンコードにコンパイルする（静的）AOTコンパイラに加えて、ランタイムサービスのすべてが含まれています。 Androidプログラムのニーズ：メモリアロケーター、ガベージコレクター、リフレクションシステム、コアクラスとインターフェイスなど。