ART: шта је то, окружење за извршавање и како ради

Шта је ART?

Android Runtime (ART) — окружење за извршавање апликација које компилира DEX бајт-код у изворни машински код пре покретања. За разлику од Dalvik-а, који је користио Just-In-Time компилацију током рада, ART врши Ahead-Of-Time (AOT) компилацију при инсталацији APK-а. Ова фундаментална промена архитектуре довела је до значајног убрзања апликација и смањења потрошње енергије.

ART се први пут појавио као експериментална опција у Android 4.4 KitKat. Програмери су могли да је укључе у подешавањима за програмере и тестирају своје апликације. У Android 5.0 Lollipop, ART је постао подразумевано окружење за извршавање, а Dalvik је потпуно уклоњен из платформе. До изласка Android 7.0 Nougat, ART је добио хибридни режим компилације.

Историја развоја

Одлука да се Dalvik замени са ART није била изненадна. Рад на новом окружењу почео је 2012. године, када је Google схватио ограничења JIT приступа. Главни циљеви: убрзање покретања апликација, смањење оптерећења процесора и смањење потрошње енергије. Развојем је руководио тим Android Runtime Group, који је раније радио на оптимизацијама Dalvik-а.

Архитектонске промене

ART користи исту регистарску архитектуру као и Dalvik, али са потпуно прерађеним компилатором. Уместо интерпретатора и JIT-компилатора, ART укључује AOT-компилатор dex2oat, који претвара DEX датотеке у ELF бинарне датотеке при инсталацији. Као резултат, апликација на ART-у се покреће одмах са изворним перформансама, без фазе загревања.

Архитектура ART-а: од Dalvik-а до новог окружења

ART је задржао кључне принципе Dalvik-а: изолацију апликација кроз одвојене процесе, регистарску архитектуру и подршку за DEX формат. Међутим, унутрашња имплементација је потпуно преписана. Уместо интерпретатора Dalvik-а, ART укључује три режима извршавања: интерпретатор, JIT-компилатор и AOT-компилатор dex2oat. Избор режима зависи од фазе животног циклуса апликације.

Кључна компонента ART-а — dex2oat (dalvik executable to optimized android translator). Ова алатка се покреће при инсталацији апликације (од Android 7.0 — такође при позадинској оптимизацији). dex2oat чита DEX датотеке из APK-а, оптимизује бајт-код и генерише OAT датотеку — ELF бинарну датотеку са изворним кодом. OAT датотеке се чувају у директоријуму /data/dalvik-cache/.

# Провера OAT датотека на уређају
adb shell ls -la /data/dalvik-cache/arm64/

# Принудна рекомпилација апликације
adb shell cmd package compile -m speed com.example.app

Компоненте ART-а

Систем ART се састоји од неколико међусобно повезаних модула. Компилатор dex2oat је одговоран за генерисање изворног кода. Сакупљач смећа (GC) управља ослобађањем меморије. Интерпретатор извршава ретко позивани код без компилације. Профилер прати hot-методе за хибридну компилацију. Сваки модул може радити независно, што ART чини флексибилним и скалабилним.

Хибридна компилација: JIT + AOT + профилисање

Од Android 7.0 Nougat, ART користи хибридни приступ компилацији, комбинујући предности JIT-а и AOT-а. При инсталацији апликације, ART више не врши потпуну AOT-компилацију — уместо тога, апликација се покреће у интерпретираном режиму са JIT-компилацијом hot-метода. Ово смањује време инсталације и заузети простор.

Паралелно ради позадински профилер (background profiler). Он прикупља статистику извршавања: који методи се најчешће позивају, које гране кода се извршавају, које класе се учитавају. Након прикупљања довољне количине података (обично након 2–3 покретања апликације), ART покреће dex2oat у позадини и компилира само профилисане hot-методе у изворни код.

Режими компилације

ART подржава неколико режима компилације којима се управља преко system_server-а. Режим "speed" компилира све методе у AOT (максималне перформансе, дуга инсталација). Режим "speed-profile" компилира само профилисане hot-методе (баланс брзине и величине). Режим "verify" само проверава бајт-код без компилације (минималан простор, интерпретација). Подразумевано се користи speed-profile — оптималан за већину апликација.

Профилер ART-а

Профилер прикупља податке о извршавању у посебне .prof датотеке. Свака апликација чува свој профил у /data/misc/profiles/. По достизању прага (обично 1000 узорака), профилер покреће dex2oat за компилацију идентификованих hot-метода. Профили се чувају између ажурирања апликације, што убрзава поновну оптимизацију након OTA ажурирања система.

Сакупљање смећа у ART-у

Сакупљање смећа у ART-у је коренито побољшано у поређењу са Dalvik-ом. Уместо једнонитног Concurrent Mark and Sweep (CMS) ART користи генерацијски сакупљач са неколико оптимизација: moving collector (збијање хеапа), large object space (одвојено складиштење великих објеката) и concurrent compaction (паралелно збијање).

Типична пауза GC у ART-у износи 2–3 ms у односу на 5–10 ms у Dalvik-у. То је постало могуће захваљујући неколико механизама. Прво, ART користи read-barrier уместо stop-the-world за конкурентне фазе. Друго, генерацијски сакупљач обрађује само младу генерацију објеката у већини циклуса, не утичући на цео хеап. Треће, large object space (LOS) се издваја одвојено и не учествује у уобичајеним GC циклусима.

// Укључивање GC логова за отклањање грешака
System.logV("ART", "GC trigger: allocation failed");

// Принудни позив GC (не препоручује се у продукцији)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Цурење меморије у ери ART-а

Упркос побољшаном GC-у, цурење меморије остаје актуелан проблем. Узрок специфичан за ART — учитавање изворних библиотека преко JNI-ја без коректног ослобађања. Ако изворни код издваја меморију преко malloc-а, али не позива free, ART не може да ослободи ту меморију — налази се ван управљаног хеапа. Алатка AddressSanitizer у Android NDK-у помаже у откривању таквих цурења.

ART vs Dalvik: упоредна анализа

ART и Dalvik — две суштински различите имплементације истог задатка: извршавање Android апликација. Разлике утичу на све нивое: од компилације до управљања меморијом. Испод је дато поређење по кључним параметрима перформанси и компатибилности.

Главна предност ART-а — уклањање JIT загревања. На Dalvik-у, апликација је могла да успорава првих 3–10 секунди, док JIT компилира hot-методе. На ART-у су сви методи већ компилирани у изворни код (или ће бити компилирани у позадини). Ово је посебно приметно у играма и апликацијама са тешким UI: разлика у fps-у може достићи 15–20% у корист ART-а.

Компатибилност

Све апликације написане за Dalvik раде на ART-у без измена. Google гарантује потпуну уназад компатибилност на нивоу DEX бајт-кода. Изузетак — код који користи Dalvik-specific интерни API преко рефлексије: чланови класе dalvik.system.DexFile означени са @hide у Android SDK-у. Такав код треба ажурирати да користи јавне API-је.

Подршка за Java 8 и десахаринг

ART је постао прво окружење за извршавање Android-а са изворном подршком за Java 8 функције. Од Android 7.0, ART укључује десахаринг — процес претварања Java 8 конструкција (ламбде, method references, Stream API) у еквивалентни Java 7 код. Ово омогућава коришћење модерне синтаксе без губитка компатибилности са старијим уређајима.

Десахаринг врши компилатор D8 и ради на следећи начин. Изворни код са ламбдом се претвара у синтетички метод унутар исте класе, а ламбда се замењује позивом invoke-custom. ART-ово окружење укључује подршку за инструкцију invoke-custom, додану посебно за Java 8. На уређајима са Android 6.0 и старијим, ламбде се десахарирају у анонимне класе.

// Java 8 ламбда — десахаринг у ART-у
button.setOnClickListener(v -> handleClick(v));

// Након десахаринга (еквивалент у Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Ограничења десахаринга

Нису све Java 8 функције подржане десахарингом. java.time API (датум и време) доступан је само преко desugar_jdk_libs — додатне библиотеке која се додаје у build.gradle. Stream API такође захтева desugar_jdk_libs. java.util.function и Optional раде без додатних зависности. Потпуна подршка за Java 8 доступна је на уређајима са Android 8.0 и новијим без десахаринга.

Оптимизација апликација за ART

Иако је ART уназад компатибилан, неке праксе оптимизације побољшавају перформансе управо на овом окружењу. Главна препорука — минимизирати рефлексију. ART компилира методе видљиве у фази компилације у директан позив машинског кода. Рефлексија приморава ART да генерише додатне stub-ове, што успорава извршавање за 10–15%.

Од Android 9.0 у ART-у се појавила подршка за App Startup Optimization. Програмер може да означи класе иницијализације у манифесту преко <initialization>, а ART ће их претходно учитати при покретању апликације. Ово смањује време покретања за 5–15% за апликације са великим бројем додатака или библиотека.

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

Провера перформанси

За мерење перформанси на ART-у користите systrace и perfetto. Systrace показује време компилације dex2oat-а, учесталост GC-а и брзину исцртавања оквира. Perfetto даје детаљније информације: расподелу нити, време JNI прелаза, учитавање изворних библиотека. Покретање: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.