- Dalvik pracoval s využitím JIT kompilace a překládal kód za běhu aplikace.
- ART optimalizuje systém pomocí kompilace AOT, která se provádí během instalace.
- Obě prostředí používají formát souborů DEX, což zajišťuje kompatibilitu mezi verzemi.
- Přechod na ART umožnil snížení spotřeby baterie a zlepšení plynulosti systému.
Pokud jste se někdy zamýšleli nad tím, co se doopravdy děje „pod kapotou“ vašeho telefonu, když otevřete aplikaci, odpověď se skrývá v běhovém prostředí. V ekosystému Androidu jsme přešli od architektury založené na virtuálním stroji Dalvik k mnohem robustnějšímu systému zvanému Android Runtime, lépe známému jako ART. ART je v podstatě zodpovědný za překlad kódu, který programátoři píší, do instrukcí, kterým hardware vašeho zařízení rozumí, aniž by došlo k jeho pádu.
Abychom tomu porozuměli, je důležité vědět, že Android neběží nativně v Javě; místo toho používá vlastní adaptaci . Všechno začíná zdrojovým kódem, který je transformován do bajtkódu a končí ve specifickém formátu zvaném DEX. V závislosti na tom, zda máte starší nebo novější verzi Androidu, se cesta, kterou se tento kód spustí, drasticky mění, což ovlivňuje každodenní věci, jako je výdrž baterie a rychlost načítání aplikací.
Odkaz Dalviku: Éra Just-In-Time
Dalvik byl základním pilířem Androidu od samého začátku. Jeho cíl byl jasný: umožnit aplikacím napsaným v Javě běh na zařízeních s velmi omezenými zdroji . Na rozdíl od standardního virtuálního stroje Java byl Dalvik optimalizován pro menší využití paměti a současné spouštění více instancí, přičemž správu vláken delegoval na linuxové jádro.
Klíčovou funkcí Dalviku byla kompilace Just-In-Time (JIT) . To znamenalo, že kód byl přeložen do strojového jazyka přesně v okamžiku, kdy uživatel interagoval s aplikací. Aby se předešlo opakování tohoto zdlouhavého úkolu pokaždé, Dalvik vytvořil soubory s názvem ODEX (Optimized DEX) , které ukládaly již přeložené části do mezipaměti. Problém byl v tom, že tento neustálý proces kompilace spotřebovával cykly CPU, a proto spotřebovával více energie.
Android Runtime (ART): Skok k předstihu
Počínaje Androidem 5.0 Lollipop převzal ART kompletní kontrolu. Velký rozdíl spočívá v tom, že ART implementuje kompilaci Ahead-Of-Time (AOT) . Místo čekání na otevření aplikace se ART postará o těžkou práci během instalace. Používá nástroj s názvem dex2oat k převodu souborů DEX do spustitelných souborů ELF (Executable and Linkable Format), které jsou nativní pro Linux.
Díky tomuto přístupu nemusí systém po klepnutí na ikonu aplikace nic kompilovat; jednoduše přečte soubor ELF a spustí ho. To znamená, že procesor pracuje méně, baterie vydrží déle a aplikace fungují mnohem plynulejší. Existuje však malý kompromis: instalace aplikací trvá o něco déle a zabírají více úložného prostoru než u Dalviku.
Technické srovnání a klíčová vylepšení
Přestože jsou obě prostředí kompatibilní a běží stejný bajtkód DEX, společnost ART zavedla vylepšení, která systém neuvěřitelně zrychlují. Jedním z nejvýznamnějších je garbage collector (GC) . V Dalviku dříve garbage collector způsoboval otravné pauzy neboli „koktaní“ v rozhraní (nechvalně známé lag). Společnost ART tento systém přepracovala s primárně souběžným systémem , takže pauzy jsou nezávislé na množství použité paměti.
- Pokročilé ladění: ART umožňuje vývojářům vidět, které zámky drží vlákna, a sledovat instance tříd s mnohem větší přesností.
- Přesné diagnózy: Nyní, když dojde k pádu aplikace, jsou chybové zprávy mnohem podrobnější, zejména v případech Výjimka NullPointerException.
- Správa paměti: Na rozdíl od Dalviku, který používal nestránkovatelnou mezipaměť, ART používá paměť RAM, která stránkování je možné, optimalizace využití hardwaru.
Proces balení: Od kódu po APK
Aby kterékoli z těchto prostředí fungovalo, musí kód projít montážní linkou. Nejprve kompilátor Javy vytvoří soubory .class, které pak nástroj dex převede do jednoho souboru classes.dex. Tento soubor je jádrem APK a je to, co ART nebo Dalvik zpracuje.
Nástroje jako aapt se používají k balení zdrojů a zipalign optimalizuje zarovnání dat, čímž zajišťuje, aby procesor přistupoval k paměti co nejefektivněji. Jakmile se APK dostane do zařízení, stane se zázrak: pokud existuje ART, vygeneruje se soubor ELF ; pokud existuje Dalvik, soubor ODEX se začne generovat za chodu.
Zajímavosti o ROM a procesu dedexování
Ve světě vlastních ROM se běžně používají termíny odex a deodex . Protože soubor ODEX je závislý na hardwaru a přesném systému, ve kterém byl vytvořen, nelze jej snadno přenést z jednoho telefonu do druhého. Pro úpravu aplikace bez pádu systému provádějí vývojáři proces deodexování , který zahrnuje integraci optimalizovaného souboru do souboru APK pro usnadnění manipulace s ním.
Ekosystém Androidu se vyvinul z flexibilního, ale energeticky náročného virtuálního stroje do optimalizovaného běhového prostředí, které upřednostňuje uživatelský zážitek. Zatímco se Dalvik zaměřil na všestrannost překladu kódu v reálném čase, ART maximalizoval využití hardwaru prostřednictvím předkompilace , čímž zajistil stabilnější, rychlejší a energeticky úspornější software.