Runtime dalam pengembangan mobile: apa itu, sistem runtime, dan cara kerjanya

Apa itu Runtime dalam pengembangan mobile?

Runtime (lingkungan eksekusi) adalah infrastruktur yang memastikan eksekusi program setelah program diluncurkan. Dalam konteks pengembangan mobile, runtime mencakup pemuat kelas, pengalokasi memori, garbage collector, pendistribusi metode, dan penangan pengecualian. Tanpa lapisan perantara ini, sistem operasi tidak dapat mengeksekusi bytecode Dalvik atau pesan Objective-C.

Platform seluler menggunakan implementasi runtime yang berbeda. Android menggunakan ART (Android Runtime) dengan kompilasi hibrida AOT/JIT. iOS menggunakan Objective-C Runtime — sistem dinamis yang didasarkan pada message passing dan pengenal SEL. Kedua pendekatan memecahkan satu masalah: mengeksekusi kode pengembang pada perangkat tertentu dengan performa maksimal.

Menurut Google I/O 2024, Android Runtime memproses lebih dari 10 miliar metode per hari pada perangkat di seluruh dunia. Performa runtime secara langsung memengaruhi kecepatan peluncuran aplikasi, kelancaran animasi, dan konsumsi baterai. Setiap pemanggilan metode, setiap alokasi memori, dan setiap siklus garbage collection melewati lapisan runtime.

Sistem runtime: terdiri dari komponen apa

Sistem runtime mencakup lima komponen kunci: pemuat kelas, pengelola memori, interpreter atau kompiler, pendistribusi metode, dan sistem keamanan. Setiap komponen menjalankan fungsi yang ditentukan secara ketat dalam proses eksekusi kode.

Pemuat kelas dan verifikasi

Ketika pengguna meluncurkan aplikasi, ClassLoader memuat file DEX (Android) atau biner Mach-O (iOS) ke dalam memori kerja. Di Android, tahap ini mencakup verifikasi bytecode: runtime memeriksa bahwa kode tidak mengandung instruksi yang tidak aman, tidak melewati batas array, dan menghormati tipe. Verifikasi adalah langkah keamanan kritis yang mencegah eksekusi kode berbahaya.

Pengelola memori dan Garbage Collector

Memory Manager mengalokasikan dan membebaskan memori untuk objek. Di Android, ART menggunakan garbage collector bersamaan dengan pengumpulan generasional: objek muda diperiksa lebih sering, objek tua — lebih jarang. Objective-C Runtime menerapkan Automatic Reference Counting (ARC), di mana kompiler memasukkan pemanggilan retain/release secara otomatis.

Pendistribusi metode dan tabel virtual

Method dispatcher menentukan implementasi metode mana yang akan dipanggil. Dalam bahasa statis (Kotlin, Swift), distribusi dilakukan melalui vtable — tabel metode virtual. Dalam bahasa dinamis (Objective-C), pesan melewati objc_msgSend, yang mencari implementasi di kelas dan superclass-nya. Hasilnya disimpan dalam method cache untuk mempercepat pemanggilan berulang.

Bagaimana ART bekerja di Android

Android Runtime (ART) adalah mesin virtual yang mengeksekusi bytecode DEX aplikasi Android. ART menggantikan Dalvik di Android 5.0 Lollipop, menawarkan kompilasi AOT: aplikasi dikompilasi ke kode mesin satu kali selama instalasi. Ini menghilangkan biaya overhead kompilasi JIT pada setiap peluncuran.

Mulai Android 7.0 Nougat, ART menggunakan pendekatan hibrida. Selama instalasi, kompilasi JIT dilakukan hanya untuk metode yang sering digunakan (hot methods), sementara kode lainnya diinterpretasikan. Proses latar belakang (profile-guided optimization) menganalisis metode mana yang paling sering dipanggil dan mengompilasinya AOT saat perangkat tidak aktif. Ini mengurangi waktu instalasi dan sekaligus memberikan performa tinggi.

ART juga menyertakan AOT compiler (dex2oat), yang mengubah file DEX menjadi biner ELF dengan kode mesin ARM64. Kompilasi dilakukan dengan tiga tingkat optimasi: quicken (cepat), optimize (sedang), dan everything (lengkap). Secara default, Android menerapkan optimize, yang menyeimbangkan antara kecepatan kompilasi dan performa kode.

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // Pemanggilan metode yang dikompilasi oleh ART
        processData()
        val end = System.nanoTime()
        println("Waktu eksekusi: ${end - start} ns")
    }
}

Dalam contoh di atas, System.nanoTime() adalah metode native yang pemanggilannya didistribusikan melalui ART runtime ke kernel Linux. ART mengubah bytecode Kotlin menjadi instruksi ARM64 yang dieksekusi oleh prosesor perangkat. Proses ini terjadi tanpa terlihat oleh pengembang, tetapi optimasinya adalah tugas utama tim Android Platform.

Profile-Guided Optimization (PGO)

Optimasi berbasis profil adalah mekanisme ART yang mengumpulkan profil penggunaan metode. File profiles/.primary.prof berisi daftar metode hot yang dikompilasi AOT. Menurut Android Performance Team, PGO mempercepat peluncuran aplikasi sebesar 15–30% setelah beberapa hari penggunaan, ketika profil telah terkumpul.

Pengembang dapat mengaktifkan baseline profiles di proyek Gradle-nya. Ini adalah anotasi manual yang memberi tahu ART metode mana yang harus dikompilasi AOT segera setelah instalasi. Baseline profiles memperpendek peluncuran pertama sebesar 40% tanpa menunggu profiling latar belakang.

Bagaimana Objective-C Runtime bekerja di iOS

Objective-C Runtime adalah pustaka dinamis yang memastikan eksekusi kode Objective-C di iOS dan macOS. Intinya adalah fungsi objc_msgSend, yang mengimplementasikan message passing: alih-alih pemanggilan metode langsung, objek mengirim pesan dengan selector, dan runtime menentukan implementasi mana yang harus dieksekusi.

Setiap objek Objective-C berisi pointer isa ke kelas, dan kelas memiliki dispatch table (tabel distribusi) yang memetakan selector (SEL) ke implementasi (IMP). Ketika sebuah metode dipanggil, objc_msgSend melewati rantai: kelas → superclass → NSObject, sampai menemukan IMP. Jika implementasi tidak ditemukan, runtime memanggil forwarding mechanism, yang dapat mencegat pesan atau membuat pengecualian.

Objective-C Runtime juga mendukung method swizzling — penggantian IMP untuk selector yang ada selama eksekusi. Ini adalah mekanisme kuat yang digunakan dalam pustaka AOP dan alat pemantauan, tetapi membutuhkan kehati-hatian karena dampaknya pada seluruh aplikasi.

@interface RuntimeDemo : NSObject
- (void)printClassInfo;
@end

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — fungsi runtime
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("Jumlah metode: %d", count);
}
@end

Kode menunjukkan akses langsung ke Objective-C Runtime API: objc_getClass mendapatkan objek kelas berdasarkan nama, class_copyMethodList mengekstrak daftar semua metode. Ini adalah reflection yang bekerja — akses ke metadata kelas selama eksekusi. Pendekatan semacam itu digunakan di XCTest untuk registrasi tes secara dinamis.

Pointer isa dan tagged pointers

isa pointer adalah pointer ke kelas objek, yang disimpan di 8 byte pertama setiap objek. Sejak iOS 12, Apple memperkenalkan isa-swizzling untuk optimasi: bit-bit bawah isa mengodekan informasi tambahan tentang status objek. Tagged pointers adalah optimasi lain, di mana nilai hingga 60 bit (NSNumber, NSDate) disimpan langsung di pointer, tanpa mengalokasikan objek di heap. Ini mengurangi beban pengelola memori sebesar 30%.

Kompilasi JIT dan AOT: perbandingan pendekatan

JIT (Just-In-Time) dan AOT (Ahead-Of-Time) adalah dua pendekatan untuk mengompilasi bytecode ke kode mesin. JIT mengompilasi kode selama eksekusi aplikasi, menganalisis area panas dan mengoptimalkannya dengan cepat. AOT mengompilasi semua kode sebelumnya — saat instalasi aplikasi atau di sisi pengembang.

Pendekatan hibrida ART (Android 7+) dianggap optimal: aplikasi menggunakan interpreter untuk metode yang jarang dipanggil, JIT untuk metode hot, dan AOT untuk metode dari profile-guided optimization. iOS, sebaliknya, menggunakan AOT ketat melalui LLVM: Swift dan Objective-C dikompilasi ke kode mesin pada tahap build di Xcode.

Menurut Apple Developer Documentation, 2024, Swift runtime menambahkan sekitar 15 MB ke ukuran aplikasi. Flutter menggunakan Dart VM miliknya sendiri, di mana kompilasi JIT bekerja dalam mode debug untuk hot reload, dan AOT — dalam mode release untuk performa maksimal. React Native menggunakan Hermes — mesin JavaScript dengan kompilasi AOT yang mengurangi waktu peluncuran sebesar 50%.

ARM64 Runtime dan kode mesin

ARM64 Runtime adalah tingkat di mana kode mesin berinteraksi dengan prosesor perangkat. Sebagian besar perangkat seluler modern bekerja pada prosesor ARM64 (aarch64). Runtime menerjemahkan bytecode atau panggilan native menjadi instruksi ARM64 yang dieksekusi CPU.

Register ARM64 utama yang digunakan runtime: x0–x7 (parameter fungsi), x8 (hasil tidak langsung), x30 (alamat kembali), sp (stack pointer), fp (frame pointer). ART menghasilkan kode yang mematuhi ARM64 Procedure Call Standard: semua pemanggilan metode melalui protokol yang ditentukan oleh arsitektur prosesor.

Memahami ARM64 ABI penting saat optimasi performa: inline-caching, prediksi cabang, dan penyelarasan kode di memori secara langsung memengaruhi kecepatan kerja runtime. Alat profiling (Android Studio Profiler, Instruments) menunjukkan bagian kode mana yang menghabiskan waktu paling banyak di runtime — justru optimasi bagian-bagian itu yang memberikan peningkatan terbesar.

// Contoh assembly ARM64 yang dihasilkan ART
// Pemanggilan metode dengan dua parameter

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // pemanggilan melalui runtime
str    x0, [sp, #8]      // menyimpan hasil

Dalam contoh ini, instruksi ARM64 mov memindahkan argumen ke register x0–x2, bl memanggil titik masuk metode, dan str menyimpan nilai kembali. Runtime menghasilkan instruksi semacam itu untuk setiap pemanggilan metode, mengoptimalkan urutan melalui devirtualization dan inlining.

Pengaruh runtime terhadap performa

Runtime overhead adalah biaya yang tak terhindarkan dari distribusi dinamis. Setiap pemanggilan metode melalui runtime memerlukan: pencarian implementasi di dispatch table, pemeriksaan tipe, pemanggilan IMP, dan pengembalian hasil. Pengukuran menunjukkan bahwa runtime menambahkan 10–50 ns per pemanggilan di Objective-C dan 5–20 ns di ART.

Untuk mengurangi overhead, pengembang menggunakan monomorphic inlining (ART) dan method caching (Objective-C). Kotlin/Native dan Swift dikompilasi langsung ke ARM64, sepenuhnya menghilangkan lapisan runtime, tetapi kehilangan kemampuan dinamis — reflection, swizzling, pemuatan kelas dinamis.