ART: ce este, mediul de execuție și cum funcționează

Ce este ART?

Android Runtime (ART) — mediul de execuție al aplicațiilor care compilează bytecodul DEX în cod mașină nativ înainte de lansare. Spre deosebire de Dalvik, care folosea compilarea Just-In-Time în timpul execuției, ART efectuează compilarea Ahead-Of-Time (AOT) la instalarea APK. Această schimbare fundamentală de arhitectură a dus la o accelerare semnificativă a aplicațiilor și la reducerea consumului de energie.

ART a apărut pentru prima dată ca opțiune experimentală în Android 4.4 KitKat. Dezvoltatorii puteau să o activeze în setările pentru dezvoltatori și să își testeze aplicațiile. În Android 5.0 Lollipop, ART a devenit mediul de execuție implicit, iar Dalvik a fost complet eliminat din platformă. Până la lansarea Android 7.0 Nougat, ART a primit modul hibrid de compilare.

Istoricul dezvoltării

Decizia de a înlocui Dalvik cu ART nu a fost bruscă. Lucrările la noul mediu au început în 2012, când Google a conștientizat limitările abordării JIT. Obiectivele principale: accelerarea lansării aplicațiilor, reducerea încărcării procesorului și diminuarea consumului de energie. Dezvoltarea a fost condusă de echipa Android Runtime Group, care lucrase anterior la optimizările Dalvik.

Modificări arhitecturale

ART folosește aceeași arhitectură pe registre ca și Dalvik, dar cu un compilator complet reproiectat. În loc de interpretor și compilator JIT, ART include compilatorul AOT dex2oat, care transformă fișierele DEX în binare ELF la instalare. Ca rezultat, aplicația pe ART pornește imediat cu performanță nativă, fără faza de încălzire.

Arhitectura ART: de la Dalvik la noul mediu

ART a păstrat principiile cheie ale Dalvik: izolarea aplicațiilor prin procese separate, arhitectura pe registre și suportul pentru formatul DEX. Cu toate acestea, implementarea internă a fost complet rescrisă. În locul interpretorului Dalvik, ART include trei moduri de execuție: interpretor, compilator JIT și compilator AOT dex2oat. Alegerea modului depinde de etapa ciclului de viață al aplicației.

Componenta cheie a ART — dex2oat (dalvik executable to optimized android translator). Această unealtă pornește la instalarea aplicației (începând cu Android 7.0 — și la optimizarea în fundal). dex2oat citește fișierele DEX din APK, optimizează bytecodul și generează fișierul OAT — un binar ELF cu cod nativ. Fișierele OAT sunt stocate în directorul /data/dalvik-cache/.

# Verificarea fișierelor OAT pe dispozitiv
adb shell ls -la /data/dalvik-cache/arm64/

# Recompilarea forțată a aplicației
adb shell cmd package compile -m speed com.example.app

Componentele ART

Sistemul ART constă din mai multe module interconectate. Compilatorul dex2oat se ocupă de generarea codului nativ. Colectorul de gunoi (GC) gestionează eliberarea memoriei. Interpretorul execută codul rar apelat fără compilare. Profilerul urmărește metodele hot pentru compilarea hibridă. Fiecare modul poate funcționa independent, ceea ce face ART flexibil și scalabil.

Compilarea hibridă: JIT + AOT + profilare

Începând cu Android 7.0 Nougat, ART folosește abordarea hibridă de compilare, combinând avantajele JIT și AOT. La instalarea aplicației, ART nu mai efectuează compilarea AOT completă — în schimb, aplicația pornește în modul interpretat cu compilarea JIT a metodelor hot. Aceasta reduce timpul de instalare și spațiul ocupat.

În paralel, funcționează profilerul de fundal (background profiler). Acesta colectează statistici de execuție: care metode sunt apelate cel mai des, care ramuri de cod se execută, care clase sunt încărcate. După acumularea unei cantități suficiente de date (de obicei după 2–3 lansări ale aplicației), ART pornește dex2oat în fundal și compilează doar metodele hot profilate în cod nativ.

Moduri de compilare

ART suportă mai multe moduri de compilare gestionate prin system_server. Modul "speed" compilează toate metodele în AOT (performanță maximă, instalare lungă). Modul "speed-profile" compilează doar metodele hot profilate (echilibru între viteză și dimensiune). Modul "verify" doar verifică bytecodul fără compilare (spațiu minim, interpretare). Implicit este folosit speed-profile — optim pentru majoritatea aplicațiilor.

Profilerul ART

Profilerul colectează datele de execuție în fișiere .prof speciale. Fiecare aplicație își păstrează profilul în /data/misc/profiles/. La atingerea pragului (de obicei 1000 de eșantioane), profilerul lansează dex2oat pentru compilarea metodelor hot identificate. Profilele se păstrează între actualizările aplicației, ceea ce accelerează reoptimizarea după actualizările OTA ale sistemului.

Colectarea gunoiului în ART

Colectarea gunoiului în ART este radical îmbunătățită comparativ cu Dalvik. În loc de Concurrent Mark and Sweep (CMS) cu un singur fir, ART folosește un colector generațional cu mai multe optimizări: moving collector (compactarea heap-ului), large object space (stocarea separată a obiectelor mari) și concurrent compaction (compactarea paralelă).

Pauza tipică de GC în ART este de 2–3 ms față de 5–10 ms în Dalvik. Acest lucru a devenit posibil datorită mai multor mecanisme. În primul rând, ART folosește read-barrier în loc de stop-the-world pentru fazele concurente. În al doilea rând, colectorul generațional procesează doar generația tânără de obiecte în majoritatea ciclurilor, fără a afecta întregul heap. În al treilea rând, large object space (LOS) este alocat separat și nu participă la ciclurile obișnuite de GC.

// Activarea logurilor GC pentru depanare
System.logV("ART", "GC trigger: allocation failed");

// Apelul forțat al GC (nerecomandat în producție)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Scurgeri de memorie în epoca ART

În ciuda GC-ului îmbunătățit, scurgerile de memorie rămân o problemă actuală. O cauză specifică ART — încărcarea bibliotecilor native prin JNI fără eliberarea corectă. Dacă codul nativ alocă memorie prin malloc dar nu apelează free, ART nu poate elibera această memorie — se află în afara heap-ului gestionat. Instrumentul AddressSanitizer din Android NDK ajută la depistarea unor astfel de scurgeri.

ART vs Dalvik: analiză comparativă

ART și Dalvik — două implementări fundamental diferite ale aceleiași sarcini: executarea aplicațiilor Android. Diferențele afectează toate nivelurile: de la compilare la gestionarea memoriei. Mai jos este prezentată o comparație pe parametrii cheie de performanță și compatibilitate.

Principalul avantaj al ART — eliminarea încălzirii JIT. Pe Dalvik, aplicația putea încetini primele 3–10 secunde, în timp ce JIT compila metodele hot. Pe ART, toate metodele sunt deja compilate în cod nativ (sau vor fi compilate în fundal). Acest lucru este vizibil mai ales în jocuri și aplicații cu UI greu: diferența de fps poate atinge 15–20% în favoarea ART.

Compatibilitate

Toate aplicațiile scrise pentru Dalvik funcționează pe ART fără modificări. Google garantează compatibilitatea inversă completă la nivel de bytecod DEX. Excepție — codul care folosește API intern specific Dalvik prin reflecție: membrii clasei dalvik.system.DexFile marcați cu @hide în Android SDK. Un astfel de cod trebuie actualizat pentru a folosi API-uri publice.

Suportul Java 8 și desugarizarea

ART a devenit primul mediu de execuție Android cu suport nativ pentru caracteristicile Java 8. Începând cu Android 7.0, ART include desugarizarea — procesul de transformare a constructelor Java 8 (lambde, method references, Stream API) în cod Java 7 echivalent. Aceasta permite utilizarea sintaxei moderne fără pierderea compatibilității cu dispozitivele vechi.

Desugarizarea este efectuată de compilatorul D8 și funcționează astfel. Codul sursă cu o lambdă este transformat într-o metodă sintetică în aceeași clasă, iar lambda este înlocuită cu un apel invoke-custom. Mediul ART suportă instrucțiunea invoke-custom, adăugată special pentru Java 8. Pe dispozitivele cu Android 6.0 și mai vechi, lambdele sunt desugarizate în clase anonime.

// Lambda Java 8 — desugarizarea în ART
button.setOnClickListener(v -> handleClick(v));

// După desugarizare (echivalent în Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Limitări ale desugarizării

Nu toate caracteristicile Java 8 sunt suportate de desugarizare. API-ul java.time (date și timp) este accesibil doar prin desugar_jdk_libs — o bibliotecă suplimentară adăugată în build.gradle. Stream API necesită de asemenea desugar_jdk_libs. java.util.function și Optional funcționează fără dependențe suplimentare. Suportul complet Java 8 este disponibil pe dispozitivele cu Android 8.0 și mai noi fără desugarizare.

Optimizarea aplicațiilor pentru ART

Deși ART este compatibil invers, unele practici de optimizare îmbunătățesc performanța tocmai pe acest mediu. Recomandarea principală — minimizarea reflecției. ART compilează metodele vizibile la etapa de compilare într-un apel direct de cod mașină. Reflecția forțează ART să genereze stub-uri suplimentare, ceea ce încetinește execuția cu 10–15%.

Începând cu Android 9.0, în ART a apărut suportul pentru App Startup Optimization. Dezvoltatorul poate marca clasele de inițializare în manifest prin <initialization>, iar ART le va preîncărca la pornirea aplicației. Aceasta reduce timpul de lansare cu 5–15% pentru aplicațiile cu un număr mare de pluginuri sau biblioteci.

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

Verificarea performanței

Pentru măsurarea performanței pe ART, folosiți systrace și perfetto. Systrace arată timpul de compilare dex2oat, frecvența GC și viteza de randare a cadrelor. Perfetto oferă informații mai detaliate: distribuția firelor de execuție, timpul tranzițiilor JNI, încărcarea bibliotecilor native. Lansare: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.