GoogleはAndroidのJIT(just-in-time)コンパイラを，インストレーション中にバイトコートをネイティブなマシンコードに変換するAOT(ahead-in-time)コンパイラに置き換える。
GoogleはGoogle I/O 2014で，"Lリリース" というコードネームの，Androidオペレーティングシステムの次期バージョンを発表した。システムアーキテクチャ上の最も大きな変更は，従来のDalvik仮想マシンとJITコンパイラが，ART(Android RunTime)というシンプルな名称の新ランタイムとAOTに置き換えられることだ。
AOTとJITのコンパイル動作には，異なる動作状況において，それぞれ異なるメリットとデメリットがある。GoogleのART実装では，JITコンパイルの持つハードウェア対応のフレキシビリティを維持しながら，JITのメモリ容量と実行速度のトレードオフを補正する。これはAndroidの，多様なハードウェアプラットフォームという特徴を踏まえた戦略だ。他のプラットフォームは，それぞれのハードウェアやソフトウェアの環境に応じて，これとは異なる選択をしている。
- iOSは基本的に静的なコンパイルを行う。アプリケーションのアップロードに先立って，最初のビルドプロセスで，最適化されたコードを開発者のマシンで生成する方法だ。
- Windows Phoneでは，アプリケーションがデバイスにインストールされる前にストア上でマシン依存のコードを生成するという，クラウドコンパイル手法を採用している。
いずれの戦略も，強くコントロールされたAppleのハードウェアエコシステムと，Microsoftの極めて不均質な実行環境にそれぞれ最適化されたものだ。
Androidの新しいランタイムでは，アプリケーションのインストール時に，デバイス上でOSがバイトコードをネイティブなマシンコードにコンパイルする。生成されたネイティブコードは保存され，以降の実行で使用される。ネイティブコードの状態は，永続的なストレージ上でもデバイスのRAM上でもサイズが大きい。その一方でDalvikや従来のJITコンパイラのように，コンパイル処理をアプリケーション実行ごとに繰り返す必要はなくなる。
ARTにはJITコンパイルの重要なメリットがひとつ残っている - アプリケーションを携帯電話やタブレットなどのデバイスにインストールするとき，OSにはハードウェア仕様が正確に分かっているので，ネイティブなマシンコードを生成することができるのだ。ハードウェアが変更されないのは確実なので，生成コードをそのプロセッサに合わせて最適化することが可能だ。静的なコンパイラが，特定のプロセッサに最適化されていないコードを生成したり，異なるプロセッサごとに複数のバージョンのコードを生成したりするのとは対照的だ。
JITが部分的な最適化のみを行うのに対して，AOTコンパイラではコード全体を見渡した最適化が可能になることから，Dalvikと比較してARTでは，全体として最大で200%パフォーマンスが向上すると主張している。AnandTechへの記事でAndre Frumusanu氏は，"例外チェックなどのオーバーヘッドがほぼ解消され，メソッドやインターフェースのコールが大きく高速化された"点を指摘する。さらに，
ARTがELF実行コードをコンパイルするため，カーネルがコードページのページ処理を扱えるようになります。これによって，メモリ管理の向上とメモリ使用量の低減が期待できます。
現在は開発プレビューが公開中で，最終リリースは今年秋となる予定だ。それまでは，最終的な改善内容やトレードオフが実施される可能性がある。コンパイル処理が根本的に進歩した訳ではなく，新たなテーマも設定されてはいないが，Googleは今後も，機能の変更によって生じるAndroid特有のハードウェア群のため，最適なコンパイル技法を探し続けていくことになるだろう。