Google oznámil, že Android 17 zavede pevné limity využití paměti RAM pro každou nainstalovanou aplikaci. Hranice se bude odvíjet od celkové fyzické paměti konkrétního zařízení. Pokud ji aplikace překročí, systém její proces okamžitě ukončí – bez záznamu o pádu. Mechanismus je od Beta 4 dostupný vývojářům k testování, v ostré verzi se stane výchozím chováním systému.
Hlavní body
- Android 17 nahrazuje dosavadní reaktivní mechanismus Low Memory Killer pevnými paměťovými limity na úrovni jednotlivých aplikací.
- Překročení limitu znamená okamžité ukončení procesu bez zanechání ladících záznamů (crash stacktrace).
- Google doporučuje vývojářům aktivovat optimalizační nástroj R8 – bankovní aplikace Monzo po jeho nasazení snížila výskyt zamrznutí o 35 % a urychlila studený start o 30 %.
- Nová verze ProfilingManager API umožní aplikacím automaticky generovat výpis paměti (Heap Dump) ještě před tím, než nastane kritický stav OOM.
Android 17: Proč dosavadní přístup nestačil
Starší verze Androidu spoléhaly na mechanismus Low Memory Killer. Ten spouštěl úklid paměti až ve chvíli, kdy se celý systém dostal pod tlak – a pak postupně ukončoval procesy podle priority. Aplikace s aktivní službou přitom mohla bez omezení nabývat na objemu, zatímco systém raději rušil procesy, které fungovaly správně. Výsledkem bylo pomalé obnovování aplikací po přepnutí, vyšší zátěž procesoru a větší spotřeba baterie.
Android 17 to řeší proaktivně: každá aplikace dostane jasnou hranici ještě předtím, než stihne destabilizovat zbytek systému. Cena za překročení? Tvrdá – okamžité ukončení bez záznamu o pádu. To vývojářům komplikuje ladění, ale Google na druhou stranu rozšiřuje ProfilingManager API: aplikace si bude moci sama vyžádat výpis paměti v momentě, kdy se blíží kritické hranici, a vývojář tak získá data pro analýzu.
Co to znamená pro vývojáře
Google vydal k přechodu na nový model sadu konkrétních doporučení. Nejdůležitější je plné zapnutí nástroje R8, který komprimuje a zamaskuje bytekód, odstraní nepotřebné závislosti a zmenší objem kódu trvale přítomného v paměti. Výsledky u aplikace Monzo jsou přesvědčivé. Vedle zmíněného snížení zamrznutí a rychlejšího startu se instalační balíček zmenšil o přibližně 9 %.
Práce s obrázky je podle Googlu nejčastějším zdrojem paměťových problémů. Doporučuje používat knihovny Glide nebo Coil se zapnutým přepisováním a ořezem, a tam, kde není potřeba průhlednost, přejít z výchozího formátu ARGB_8888 na RGB_565, který zaujme polovinu paměti. Pro odhalování úniků paměti Google odkazuje na nástroj LeakCanary integrovaný v Android Studiu – pomáhá najít objekty, které zůstávají v paměti déle, než by měly, například aktivity nebo fragmenty, jejichž životní cyklus již skončil.
Vývojáři mají rovněž implementovat callback onTrimMemory, který systém volá ve chvíli, kdy aplikace přechází do pozadí nebo se stává kandidátem na ukončení. Správná reakce – uvolnění obrazových cache a videobufferů – může být rozdílem mezi tím, zda aplikace přežije, nebo ji systém ukončí.
Jakkoli jsou změny technicky opodstatněné, vývojáři s rozsáhlými legacy kódovými základnami budou mít před vydáním ostré verze co dělat.
