ART: apa itu, lingkungan eksekusi dan cara kerjanya

Apa itu ART?

Android Runtime (ART) — lingkungan eksekusi aplikasi yang mengkompilasi DEX bytecode menjadi kode mesin native sebelum dijalankan. Tidak seperti Dalvik yang menggunakan kompilasi Just-In-Time selama eksekusi, ART melakukan kompilasi Ahead-Of-Time (AOT) saat instalasi APK. Perubahan arsitektur fundamental ini menghasilkan percepatan signifikan pada aplikasi dan pengurangan konsumsi daya.

ART pertama kali muncul sebagai opsi eksperimental di Android 4.4 KitKat. Pengembang dapat mengaktifkannya di pengaturan pengembang dan menguji aplikasi mereka. Di Android 5.0 Lollipop, ART menjadi lingkungan eksekusi default, dan Dalvik sepenuhnya dihapus dari platform. Menjelang rilis Android 7.0 Nougat, ART menerima mode kompilasi hybrid.

Sejarah pengembangan

Keputusan untuk mengganti Dalvik dengan ART tidak tiba-tiba. Pengerjaan lingkungan baru dimulai pada tahun 2012, ketika Google menyadari keterbatasan pendekatan JIT. Tujuan utama: mempercepat startup aplikasi, mengurangi beban prosesor, dan menurunkan konsumsi daya. Pengembangan dipimpin oleh tim Android Runtime Group, yang sebelumnya bekerja pada optimasi Dalvik.

Perubahan arsitektur

ART menggunakan arsitektur register yang sama dengan Dalvik, tetapi dengan kompiler yang dirancang ulang sepenuhnya. Alih-alih interpreter dan kompiler JIT, ART menyertakan kompiler AOT dex2oat, yang mengubah file DEX menjadi binary ELF saat instalasi. Hasilnya, aplikasi di ART langsung berjalan dengan kinerja native, tanpa fase pemanasan.

Arsitektur ART: dari Dalvik ke lingkungan baru

ART mempertahankan prinsip utama Dalvik: isolasi aplikasi melalui proses terpisah, arsitektur register, dan dukungan format DEX. Namun, implementasi internalnya ditulis ulang sepenuhnya. Alih-alih interpreter Dalvik, ART menyertakan tiga mode eksekusi: interpreter, kompiler JIT, dan kompiler AOT dex2oat. Pemilihan mode tergantung pada tahap siklus hidup aplikasi.

Komponen kunci ART — dex2oat (dalvik executable to optimized android translator). Alat ini dijalankan saat instalasi aplikasi (sejak Android 7.0 — juga saat optimasi latar belakang). dex2oat membaca file DEX dari APK, mengoptimalkan bytecode, dan menghasilkan file OAT — binary ELF dengan kode native. File OAT disimpan di direktori /data/dalvik-cache/.

# Memeriksa file OAT di perangkat
adb shell ls -la /data/dalvik-cache/arm64/

# Kompilasi ulang paksa aplikasi
adb shell cmd package compile -m speed com.example.app

Komponen ART

Sistem ART terdiri dari beberapa modul yang saling terhubung. Kompiler dex2oat bertanggung jawab untuk menghasilkan kode native. Pengumpul sampah (GC) mengelola pembebasan memori. Interpreter mengeksekusi kode yang jarang dipanggil tanpa kompilasi. Profiler melacak metode hot untuk kompilasi hybrid. Setiap modul dapat bekerja secara independen, membuat ART fleksibel dan skalabel.

Kompilasi hybrid: JIT + AOT + profiling

Mulai Android 7.0 Nougat, ART menggunakan pendekatan hybrid untuk kompilasi, menggabungkan kelebihan JIT dan AOT. Saat instalasi aplikasi, ART tidak lagi melakukan kompilasi AOT penuh — sebagai gantinya, aplikasi berjalan dalam mode interpretasi dengan kompilasi JIT metode hot. Ini mengurangi waktu instalasi dan ruang yang digunakan.

Secara paralel, profiler latar belakang (background profiler) bekerja. Ia mengumpulkan statistik eksekusi: metode mana yang paling sering dipanggil, cabang kode mana yang dieksekusi, kelas mana yang dimuat. Setelah mengumpulkan data yang cukup (biasanya setelah 2–3 kali menjalankan aplikasi), ART menjalankan dex2oat di latar belakang dan mengkompilasi hanya metode hot yang diprofilkan ke kode native.

Mode kompilasi

ART mendukung beberapa mode kompilasi yang dikelola melalui system_server. Mode "speed" mengkompilasi semua metode ke AOT (kinerja maksimal, instalasi lama). Mode "speed-profile" hanya mengkompilasi metode hot yang diprofilkan (keseimbangan kecepatan dan ukuran). Mode "verify" hanya memverifikasi bytecode tanpa kompilasi (ruang minimal, interpretasi). Secara default, speed-profile digunakan — optimal untuk sebagian besar aplikasi.

Profiler ART

Profiler mengumpulkan data eksekusi ke dalam file .prof khusus. Setiap aplikasi menyimpan profilnya di /data/misc/profiles/. Saat mencapai ambang batas (biasanya 1000 sampel), profiler menjalankan dex2oat untuk mengkompilasi metode hot yang teridentifikasi. Profil disimpan di antara pembaruan aplikasi, yang mempercepat optimasi ulang setelah pembaruan OTA sistem.

Pengumpulan sampah di ART

Pengumpulan sampah di ART ditingkatkan secara drastis dibandingkan Dalvik. Alih-alih Concurrent Mark and Sweep (CMS) single-threaded, ART menggunakan kolektor generasional dengan beberapa optimasi: moving collector (pemadatan heap), large object space (penyimpanan terpisah untuk objek besar), dan concurrent compaction (pemadatan paralel).

Jeda GC tipikal di ART adalah 2–3 ms dibandingkan 5–10 ms di Dalvik. Ini dimungkinkan berkat beberapa mekanisme. Pertama, ART menggunakan read-barrier alih-alih stop-the-world untuk fase concurrent. Kedua, kolektor generasional hanya memproses generasi muda objek di sebagian besar siklus, tanpa mempengaruhi seluruh heap. Ketiga, large object space (LOS) dialokasikan secara terpisah dan tidak berpartisipasi dalam siklus GC biasa.

// Mengaktifkan log GC untuk debugging
System.logV("ART", "GC trigger: allocation failed");

// Panggilan GC paksa (tidak disarankan di produksi)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Kebocoran memori di era ART

Meskipun GC ditingkatkan, kebocoran memori tetap menjadi masalah yang relevan. Penyebab spesifik ART — memuat pustaka native melalui JNI tanpa pelepasan yang benar. Jika kode native mengalokasikan memori melalui malloc tetapi tidak memanggil free, ART tidak dapat membebaskan memori tersebut — berada di luar heap yang dikelola. Alat AddressSanitizer di Android NDK membantu mendeteksi kebocoran semacam itu.

ART vs Dalvik: analisis perbandingan

ART dan Dalvik — dua implementasi yang fundamentally berbeda dari tugas yang sama: menjalankan aplikasi Android. Perbedaan mempengaruhi semua level: dari kompilasi hingga manajemen memori. Di bawah ini adalah perbandingan berdasarkan parameter kinerja dan kompatibilitas utama.

Keuntungan utama ART — penghapusan pemanasan JIT. Di Dalvik, aplikasi bisa melambat selama 3–10 detik pertama saat JIT mengkompilasi metode hot. Di ART, semua metode sudah dikompilasi ke kode native (atau akan dikompilasi di latar belakang). Ini terutama terlihat di game dan aplikasi dengan UI berat: perbedaan fps bisa mencapai 15–20% untuk keunggulan ART.

Kompatibilitas

Semua aplikasi yang ditulis untuk Dalvik berjalan di ART tanpa perubahan. Google menjamin kompatibilitas mundur penuh di tingkat DEX bytecode. Pengecualian — kode yang menggunakan API internal khusus Dalvik melalui refleksi: anggota kelas dalvik.system.DexFile yang ditandai @hide di Android SDK. Kode semacam itu harus diperbarui untuk menggunakan API publik.

Dukungan Java 8 dan desugaring

ART menjadi lingkungan eksekusi Android pertama dengan dukungan native untuk fitur Java 8. Mulai Android 7.0, ART menyertakan desugaring — proses mengubah konstruksi Java 8 (lambda, method references, Stream API) menjadi kode Java 7 yang setara. Ini memungkinkan penggunaan sintaks modern tanpa kehilangan kompatibilitas dengan perangkat lama.

Desugaring dilakukan oleh kompiler D8 dan bekerja sebagai berikut. Kode sumber dengan lambda diubah menjadi metode sintetis di dalam kelas yang sama, dan lambda diganti dengan panggilan invoke-custom. Runtime ART mendukung instruksi invoke-custom, yang ditambahkan khusus untuk Java 8. Pada perangkat dengan Android 6.0 dan lebih rendah, lambda didesugar menjadi kelas anonim.

// Lambda Java 8 — desugaring di ART
button.setOnClickListener(v -> handleClick(v));

// Setelah desugaring (setara di Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Keterbatasan desugaring

Tidak semua fitur Java 8 didukung oleh desugaring. API java.time (tanggal dan waktu) hanya dapat diakses melalui desugar_jdk_libs — pustaka tambahan yang ditambahkan di build.gradle. Stream API juga memerlukan desugar_jdk_libs. java.util.function dan Optional berfungsi tanpa dependensi tambahan. Dukungan Java 8 penuh tersedia di perangkat dengan Android 8.0 dan lebih tinggi tanpa desugaring.

Optimasi aplikasi untuk ART

Meskipun ART kompatibel mundur, beberapa praktik optimasi meningkatkan kinerja tepat di lingkungan ini. Rekomendasi utama — minimalkan refleksi. ART mengkompilasi metode yang terlihat pada tahap kompilasi menjadi panggilan kode mesin langsung. Refleksi memaksa ART untuk menghasilkan stub tambahan, yang memperlambat eksekusi sebesar 10–15%.

Mulai Android 9.0, ART mendukung App Startup Optimization. Pengembang dapat menandai kelas inisialisasi di manifes melalui <initialization>, dan ART akan memuatnya terlebih dahulu saat aplikasi dimulai. Ini mengurangi waktu startup sebesar 5–15% untuk aplikasi dengan banyak plugin atau pustaka.

<!-- App Startup Optimization di AndroidManifest.xml -->
<application>
    <profileable
        android:shell="true"
        android:enable="true" />
</application>

Pengukuran kinerja

Untuk mengukur kinerja di ART, gunakan systrace dan perfetto. Systrace menunjukkan waktu kompilasi dex2oat, frekuensi GC, dan kecepatan rendering frame. Perfetto memberikan informasi lebih detail: distribusi thread, waktu transisi JNI, pemuatan pustaka native. Jalankan: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.