Android 17: obligă dezvoltatorii să reducă consumul RAM

Imaginează-ți că deschizi o aplicație și vezi cum telefonul decide, în tăcere, că aceasta nu mai merită să rămână în memorie. Închideri fără avertisment. Blocări bruște. Aceasta este realitatea pe care Google încearcă să o evite, determinând dezvoltatorii să regândească felul în care aplicațiile Android folosesc memoria RAM.

Android 17 impune reguli mai stricte: aplicațiile trebuie să funcționeze bine pe dispozitive cu memorie limitată, altfel sistemul va interveni. Google a stabilit un calendar clar: dezvoltatorii au timp până în februarie 2027 să reducă amprenta de RAM și să facă aplicațiile mai puțin pretențioase pe o gamă mai largă de hardware. Obiectivul este simplu și pragmatic: dispozitivele mid-range și entry-level să rămână funcționale, fără ca producătorii să fie nevoiți să adauge mai multă memorie sau să crească prețurile.

Ce trebuie să facă dezvoltatorii pentru ca aplicațiile lor să reziste

Începeți cu profilarea. Folosiți instrumente de profilare a memoriei și testați pe dispozitive cu 4 GB RAM sau mai puțin. Identificați obiectele mari care rămân în memorie mai mult decât ar trebui. Puneți-vă întrebări dificile: ce servicii de fundal sunt cu adevărat esențiale? Ce resurse pot fi livrate prin streaming, în loc să fie incluse în pachet? Tratați memoria ca pe o resursă limitată, nu ca pe o simplă cerință de bifat.

Imaginile consumă multă memorie RAM. Treceți la pipeline-uri moderne și la formate precum AVIF sau WebP, acolo unde este cazul, decodați imaginile la dimensiunile exacte la care sunt afișate și preferați încărcarea la cerere. Folosiți cu atenție pooling-ul de Bitmap și eliberați memoria imaginilor imediat ce elementele vizuale ies din ecran. Alocarea dinamică a memoriei ajută: creați structurile mari doar atunci când sunt necesare și eliberați-le imediat după utilizare.

Și dimensiunea codului contează. Google se așteaptă ca dezvoltatorii să reducă dimensiunea codului aplicațiilor cu până la 25% față de versiunile anterioare. Instrumente precum R8 ar trebui să facă parte din pipeline-ul de build, pentru a elimina clasele neutilizate și a optimiza bytecode-ul. Un cod mai compact înseamnă mai puține clase încărcate și un set rezident mai mic în timpul rulării.

Și strategia de testare trebuie schimbată. Simulați scenarii cu memorie redusă, activați restricțiile pentru activitatea din fundal și verificați cum reacționează aplicația când Android oprește procese. Urmăriți comportamentele neașteptate atunci când anumite componente ale aplicației sunt închise și apoi restaurate.

Dacă aplicația dvs. nu poate funcționa în noile limite de memorie, Android o va încetini sau o va opri automat.

Și producătorii de hardware modelează acest peisaj. Mulți livrează modelele de bază cu 4 GB RAM. Unii păstrează configurațiile cu mai multă memorie pentru variantele mai scumpe, ceea ce pune presiune pe dezvoltatori să asigure performanțe acceptabile pe cel mai slab numitor comun. Asta înseamnă gestionarea eficientă a thread-urilor, mai puține servicii care rulează pe termen lung și politici mai stricte pentru imagini și cache.

Google Play Console va afișa metrici de optimizare, așa că dezvoltatorii trebuie să se aștepte la vizibilitate și, probabil, la aplicarea acestor cerințe. Nu este doar o directivă a platformei, ci și un impuls venit din piață. Aplicațiile mai ușoare vor părea mai rapide, vor consuma mai puțină energie și vor menține mai mulți utilizatori mulțumiți pe dispozitivele accesibile.

Priviți această schimbare ca pe o provocare de design: proiectați pentru limite, iar publicul larg va avea de câștigat. Reduceți, profilați și iterați din timp. Termenul-limită este suficient de îndepărtat pentru a permite planificarea, dar și suficient de apropiat încât lipsa de atenție să se vadă în rapoartele de crash și în recenziile furioase.