Brian Carlstrom, Anwar Ghuloum, Ian Rogersの３氏(いずれもGoogle)がGoogle I/O 2014で，ART(the Android RunTime)の詳細に関するプレゼンテーションを行った。ARTは現行のDalvikに代わる，次期Android リリースのデフォルトプラットフォームだ。(次期Androidリリースのプレビュー版がAndroid Lという名称で，開発者向けに公開されている。一般向けには，今年秋のどこかの時点で提供される予定である。)
Dalvikは2000年の半ば，モバイルデバイスのプロセッサ能力が比較的低く，RAMが限定的だった時代に開発された。そのため，CPUやGPUが改良されてRAM容量が拡大し，画面の解像度が向上した今日のハードウェアでは，そのアドバンテージを十分に活用できていない。最新のARTプラットフォームが，マルチコアアーキテクチャや64ビットインストラクションセットのメリットを活かして設計されているのとは対照的だ。
DalvikはJIT(just-in-time)コンパイラを採用している。JITはコードを部分的に，アプリケーションの実行中に変換するスキームである。JITのメリットは，アプリケーションが実行していない状態で，メモリ使用量を比較的小さくできることだ。その一方で，コード変換がアプリ実行時に並行して行われるため，アプリのパフォーマンスが低下するデメリットがある。新たなARTプラットフォームでは，AOT(ahead-of-time)コンパイルを採用することで，メモリ効率を犠牲にして実行速度を向上する。ARTでは，アプリ実行が開始する前に，アプリのすべてのコードがコンパイルされるようになる。
ガベージコレクションのアルゴリズムも大きく改善されている。Dalvikはガベージコレクションを２つのフェーズで行う。第１のフェーズでは，ヒープを解析するためにすべてのスレッドを停止する。さらに第２のフェーズでも，ヒープをクリーンアップするために，すべてのスレッドを停止している。結果的にDalvikでは，通常のガベージコレクションの停止時間はおよそ10ミリ秒に達する -- アプリケーションのパフォーマンスにジャンクを作るには十分な時間だ。("ジャンク(jank)"というのは，画面上の要素の動作がぎくしゃく(jerky)することを示すことばだ。多くの場合，アプリケーションのパフォーマンスが不足することによって，アニメーション中にフレーム落ちが発生する。このフレーム落ちがjankの大きな原因のひとつになる。)
ARTの改善されたガベージコレクションアルゴリズムでは，スレッドの停止は一度だけになる。これによって，通常の停止時間は10ミリ秒から3ミリ秒にまで削減される。さらにARTでは，メモリアロケーションルーチン(rosallocと呼ばれている)によるロックも，Dalvikのアロケータに比べて少なくなっている。結果として，メモリ管理に起因する実行時のぎこちなさが，これまでよりも大幅に改善されることになる。
64ビットプロセッサをサポートしている点もDalvikとの違いだ。現在，Google Playにポストされているアプリの85%はネイティブ(NDK)コードを含んでいないため，64ビット実行に対応することができる。
多くの場合，64ビットをサポートする最大の理由はRAM容量の拡大にあるのだが，４ギガ以上のメモリを持つモバイルデバイスが存在しないため，Androidではこれは要因にならない。しかし，64ビットモードで動作する場合のARTは，32ビットプロセッサで使用できないインストラクションをいくつか使用する。これらの64ビットインストラクションは，より単純な32ビットコードよりも高速な処理が可能だ。
結論として，ARTで動作するアプリはDalvikで動作するアプリよりも高速に動作する，ということになる。では，どの程度速くなるのだろう？ Google I/Oでのセッションでは，10パーセントから300パーセントまでの数値を目にしたが，大部分のベンチマークでは，通常で30から80パーセントのスピードアップだった。しかし，Big Android BBQのメンバが主催する懇談会では，同じアプリが３つのデバイスで動作するのを見ることができた。これらは他の条件についてはすべて同じで，ひとつのデバイスにはDalvik，２つめには32ビットART，３つめは64ビットARTが動作していた。Dalvikデバイスのパフォーマンスは許容できるレベルではなかった。32ビットARTデバイスでは，アニメーションは改善されたものの，それでも多少"janky"な部分があった。64ビットARTデバイスのアニメーションは滑らかで，すべてのオブジェクトの動きにぎくしゃくした部分はなかった。