Noua interfata este cu certitudine o bine venita schimbare, dar haideti sa nu uitam scopul principal. Nu am auzit multi oameni plangandu-se de aspectul Android-ului, dar am auzit oameni intrebandu-se cum isi va dezvolta Google portofoliul in domeniile tehnologice adiacente celor deja dominate de Android. Asta este ceea ce Material Design incearca sa realizeze, uniformitate in experienta utilizatorului de la telefon la TV, si pana la masina. Nu avem nici un exemplu in cauza, asa ca sunt curios de cum va decurge totul pentru Google si cum va arata in final software-ul pe un calculator sau ecran TV.

Ei bine, doar nu credeati ca Google ar fi trecut prin toata aceasta agitatie daca nu ar fi adus Android-ul pe noi platforme. Am auzit zvonuri cum ca vom vedea servere bazate pe Android, iar in acest domenii foarte specializate un sistem de operare pentru telefoane nu ar avea nimic de oferit. De acea Google face niste schimbari in privinta functionarii sistemului de operare. Probabil cea mai importanta schimbare este trecerea de la VM-ul Dalvik la cel ART (runtime-ul Android). In timp ce pana acum utilizatorii au avut optiunea de a comuta intre cele doua, Android L foloseste strict ART ca runtime. Ce vrea asta sa insemne? Vorbind in termeni simpli, aplicatiile Android contin byte-code Dalvik. Acesta nu este cod pe care procesorul dispozitivului vostru il poate rula, asa ca trebuie tradus inainte de a fi trimis procesorului. In mod traditional, byte code-ul Dalvik era interpretat si tradus in momentul cand era necesar, dar Android 2.2 a adaugat un compilator JIT (just-in-time) care transforma cel mai folosit byte-code Dalvik in cod masina chiar si inainte de a fi executat. Asta este grozav, dar traducerea din Dalvik in cod masina necesita resurse (timp si putere de procesare) iar ART urmareste optimizarea procesului mentionat. Convertirea ia loc acum la prima pornire sau dupa ce o aplicatie este instalata, astfel incat codul masina este pregatit pentru folosire in orice moment. ART ar trebui sa aduca imbunatatiri de performanta si eficienta, dar noul runtime aduce de asemenea si alte beneficii…

…una dintre acestea fiind flexibilitatea. Cum profita Google de aceasta? Prin adaugarea in Android a suportului pentru 64-bit, la 9 luni dupa introducerea lui iPhone 5S, primul smartphone care a folosit un procesor pe 64-bit. Nu va lasati pacaliti de departamentele de marketing care va vor spune ca procesoarele pe 64-bit sunt automat mai rapide decat cele pe 32-bit. Exista situatii in care un procesor pe 64-bit ar avea avantaj majore in privinta performantei, dar altceva este mai important: posibilitatea de a adresa o cantitate mult mai mare de memorie: de 4 trilioane de ori mai mult. Incercati sa puneti asta pentru un moment in perspectiva: nu exista o presiune imensa de a adauga mai multa memorie telefoanelor sau tabletelor. Dar serverele? Asta este o alta poveste, una care are de a face cu cantitati uriase de memorie.

Desigur, Android L ramane un sistem de operare mobil, asa ca dispozitivele mobile isi primesc partea lor de atentie. Se pretind imbunatatiri in privinta autonomiei si au fost optimizate si librariile care se ocupa de animatii si grafica. Dispozitivul poate acum sa trimita instructiuni catre GPU in paralel cu executia lor (pentru fiecare afisare) si mai multe tipuri de efecte si animatii sunt procesate pe GPU. Aceste optimizari erau necesare pentru conceperea unei interfete atat de interactive. Alte schimbari in structura grafica includ noi functii care ar trebui sa aduca capabilitatile 3D ale Android-ului la “grafica ca pe PC”. Desigur asta este o exagerare, dar cu toate acestea inseamna ca programatorii primesc noi instrumente pentru realizarea jocurilor de Android. Asta este ceva ce iOS a realizat putin mai bine dupa cum ne spune istoria, asa ca este interesant sa vedem cum isi imbunateste Android-ul setul de abilitati.