ART: co to je, runtime prostředí a jak funguje

Co je ART?

Android Runtime (ART) — runtime prostředí aplikací, které kompiluje DEX bajtkód do nativního strojového kódu před spuštěním. Na rozdíl od Dalvik, který používal Just-In-Time kompilaci během běhu, ART provádí Ahead-Of-Time (AOT) kompilaci při instalaci APK. Tato zásadní změna architektury vedla k výraznému zrychlení aplikací a snížení spotřeby energie.

ART se poprvé objevilo jako experimentální volba v Android 4.4 KitKat. Vývojáři jej mohli zapnout v nastavení pro vývojáře a testovat své aplikace. V Android 5.0 Lollipop se ART stalo výchozím runtime prostředím a Dalvik bylo z platformy zcela odstraněno. Do vydání Android 7.0 Nougat získalo ART hybridní režim kompilace.

Historie vývoje

Rozhodnutí nahradit Dalvik ART nebylo náhlé. Práce na novém prostředí začala v roce 2012, když si Google uvědomil omezení JIT přístupu. Hlavní cíle: zrychlení spouštění aplikací, snížení zatížení procesoru a snížení spotřeby energie. Vývoj vedl tým Android Runtime Group, který dříve pracoval na optimalizacích Dalvik.

Architektonické změny

ART používá stejnou registrovou architekturu jako Dalvik, ale s kompletně přepracovaným kompilátorem. Místo interpretru a JIT kompilátoru obsahuje ART AOT kompilátor dex2oat, který převádí DEX soubory na ELF binárky při instalaci. Výsledkem je, že aplikace na ART startuje okamžitě s nativním výkonem, bez fáze zahřívání.

Architektura ART: od Dalvik k novému prostředí

ART zachovalo klíčové principy Dalvik: izolaci aplikací prostřednictvím oddělených procesů, registrovou architekturu a podporu formátu DEX. Vnitřní implementace však byla kompletně přepsána. Místo interpretru Dalvik obsahuje ART tři režimy provádění: interpretr, JIT kompilátor a AOT kompilátor dex2oat. Volba režimu závisí na fázi životního cyklu aplikace.

Klíčová komponenta ART — dex2oat (dalvik executable to optimized android translator). Tento nástroj se spouští při instalaci aplikace (od Android 7.0 — také při optimalizaci na pozadí). dex2oat čte DEX soubory z APK, optimalizuje bajtkód a generuje OAT soubor — ELF binárku s nativním kódem. OAT soubory jsou uloženy v adresáři /data/dalvik-cache/.

# Kontrola OAT souborů na zařízení
adb shell ls -la /data/dalvik-cache/arm64/

# Vynucená rekompilace aplikace
adb shell cmd package compile -m speed com.example.app

Komponenty ART

Systém ART se skládá z několika vzájemně propojených modulů. Kompilátor dex2oat je zodpovědný za generování nativního kódu. Kolektor paměti (GC) spravuje uvolňování paměti. Interpretr provádí zřídka volaný kód bez kompilace. Profiler sleduje hot metody pro hybridní kompilaci. Každý modul může pracovat nezávisle, což činí ART flexibilním a škálovatelným.

Hybridní kompilace: JIT + AOT + profilování

Od Android 7.0 Nougat používá ART hybridní přístup ke kompilaci, kombinující výhody JIT a AOT. Při instalaci aplikace již ART neprovádí úplnou AOT kompilaci — místo toho aplikace běží v interpretovaném režimu s JIT kompilací hot metod. To zkracuje dobu instalace a zabrané místo.

Paralelně pracuje profiler na pozadí (background profiler). Sbírá statistiky provádění: které metody jsou volány nejčastěji, které větve kódu se provádějí, které třídy se načítají. Po nashromáždění dostatečného množství dat (obvykle po 2–3 spuštěních aplikace) ART spouští dex2oat na pozadí a kompiluje pouze profilované hot metody do nativního kódu.

Režimy kompilace

ART podporuje několik režimů kompilace spravovaných přes system_server. Režim "speed" kompiluje všechny metody do AOT (maximální výkon, dlouhá instalace). Režim "speed-profile" kompiluje pouze profilované hot metody (rovnováha rychlosti a velikosti). Režim "verify" pouze ověřuje bajtkód bez kompilace (minimální místo, interpretace). Ve výchozím nastavení se používá speed-profile — optimální pro většinu aplikací.

Profiler ART

Profiler shromažďuje data o provádění do speciálních .prof souborů. Každá aplikace ukládá svůj profil do /data/misc/profiles/. Po dosažení prahu (obvykle 1000 vzorků) profiler spouští dex2oat pro kompilaci identifikovaných hot metod. Profily jsou zachovány mezi aktualizacemi aplikace, což urychluje opětovnou optimalizaci po OTA aktualizacích systému.

Správa paměti v ART

Správa paměti v ART byla radikálně vylepšena ve srovnání s Dalvik. Místo jednovláknového Concurrent Mark and Sweep (CMS) používá ART generační kolektor s několika optimalizacemi: moving collector (kompaktace haldy), large object space (oddělené ukládání velkých objektů) a concurrent compaction (paralelní kompaktace).

Typická pauza GC v ART je 2–3 ms oproti 5–10 ms v Dalvik. To bylo umožněno díky několika mechanismům. Zaprvé, ART používá read-barrier místo stop-the-world pro souběžné fáze. Zadruhé, generační kolektor zpracovává ve většině cyklů pouze mladou generaci objektů, aniž by ovlivnil celou haldu. Zatřetí, large object space (LOS) je alokován samostatně a neúčastní se běžných GC cyklů.

// Povolení GC logů pro ladění
System.logV("ART", "GC trigger: allocation failed");

// Vynucené volání GC (nedoporučuje se v produkci)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Úniky paměti v éře ART

Navzdory vylepšenému GC zůstávají úniky paměti aktuálním problémem. Příčina specifická pro ART — načítání nativních knihoven přes JNI bez správného uvolnění. Pokud nativní kód alokuje paměť přes malloc, ale nezavolá free, ART nemůže tuto paměť uvolnit — nachází se mimo spravovanou haldu. Nástroj AddressSanitizer v Android NDK pomáhá odhalovat takové úniky.

ART vs Dalvik: srovnávací analýza

ART a Dalvik — dvě zásadně odlišné implementace stejného úkolu: spouštění Android aplikací. Rozdíly ovlivňují všechny úrovně: od kompilace po správu paměti. Níže je uvedeno srovnání klíčových parametrů výkonu a kompatibility.

Hlavní výhoda ART — odstranění zahřívání JIT. Na Dalvik mohla aplikace zpomalovat prvních 3–10 sekund, zatímco JIT kompiloval hot metody. Na ART jsou všechny metody již zkompilovány do nativního kódu (nebo budou zkompilovány na pozadí). To je patrné zejména ve hrách a aplikacích s těžkým UI: rozdíl ve fps může dosahovat 15–20% ve prospěch ART.

Kompatibilita

Všechny aplikace napsané pro Dalvik fungují na ART beze změn. Google garantuje plnou zpětnou kompatibilitu na úrovni DEX bajtkódu. Výjimkou je kód používající Dalvik-specific interní API přes reflexi: členy třídy dalvik.system.DexFile označené @hide v Android SDK. Takový kód by měl být aktualizován pro použití veřejných API.

Podpora Java 8 a desugaring

ART se stalo prvním runtime prostředím Android s nativní podporou funkcí Java 8. Od Android 7.0 obsahuje ART desugaring — proces převodu konstrukcí Java 8 (lambdy, method references, Stream API) na ekvivalentní kód Java 7. To umožňuje používat moderní syntaxi bez ztráty kompatibility se staršími zařízeními.

Desugaring provádí kompilátor D8 a funguje následovně. Zdrojový kód s lambdou je převeden na syntetickou metodu v rámci stejné třídy a lambda je nahrazena voláním invoke-custom. Runtime ART podporuje instrukci invoke-custom, přidanou speciálně pro Java 8. Na zařízeních s Android 6.0 a nižším jsou lambdy desugarovány na anonymní třídy.

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

// Po desugaringu (ekvivalent v Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Omezení desugaringu

Ne všechny funkce Java 8 jsou desugaringem podporovány. java.time API (datum a čas) je přístupné pouze přes desugar_jdk_libs — doplňkovou knihovnu přidanou v build.gradle. Stream API také vyžaduje desugar_jdk_libs. java.util.function a Optional fungují bez dalších závislostí. Plná podpora Java 8 je k dispozici na zařízeních s Android 8.0 a vyšším bez desugaringu.

Optimalizace aplikací pro ART

Přestože je ART zpětně kompatibilní, některé optimalizační postupy zlepšují výkon právě v tomto prostředí. Hlavní doporučení — minimalizovat reflexi. ART kompiluje metody viditelné ve fázi kompilace na přímé volání strojového kódu. Reflexe nutí ART generovat další stuby, což zpomaluje provádění o 10–15%.

Od Android 9.0 se v ART objevila podpora App Startup Optimization. Vývojář může označit inicializační třídy v manifestu pomocí <initialization> a ART je přednačte při spuštění aplikace. To zkracuje dobu spouštění o 5–15% pro aplikace s velkým množstvím pluginů nebo knihoven.

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

Měření výkonu

Pro měření výkonu na ART používejte systrace a perfetto. Systrace ukazuje dobu kompilace dex2oat, frekvenci GC a rychlost vykreslování snímků. Perfetto poskytuje podrobnější informace: rozložení vláken, dobu JNI přechodů, načítání nativních knihoven. Spuštění: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.