Az idei Google I/O konferencián a Google bejelentette az Android L-t, mely a vállalat operációs rendszerének új állomását képviseli. Évek óta a legnagyobb fejlesztésnek tekinthető a szoftver, hiszen olyan alapvető dolgokat cserélnek le benne a fejlesztők, mint a Dalvik. Mint ismeretes, utóbbi egy olyan futtatási környezet, amire a programozók olyan applikációkat írhatnak, amelyek tulajdonképpen minden androidos eszközön elindulnak. Gyakorlatilag egy virtuális gépről van szó, ami az elmúlt években túlkorossá vált, köszönhetően annak, hogy nem volt túl átfogó a fejlesztésére kidolgozott stratégia.
A Dalvik teljesítménye sajnos ma már nem üti meg az elfogadható szintet, így a Google számára szükségessé vált a csere. Erre pont jó az időzítés, hiszen az ultramobil piac éppen a 64 bites átálláson dolgozik, így az Android L alapvető újítása a 64 bites utasításarchitektúrák mellett az ART bevezetése is. Az új operációs rendszerben az ART lesz az alapértelmezett futtatási környezet és ezt már ARMv8, AMD64 (x86-64) és MIPS64 architektúrákhoz tervezték, de a kompatibilitás miatt támogatja a 32 bites opciókat is. A Dalvik ezzel egyetemben eltűnik, így az Android L már csak az ART futtatási környezettel lesz szállítva.
Az ART egyébként minden szempontból jobb, mint az elődje, de tulajdonképpen ez nem meglepő. A sebességelőny a 25%-tól kezdve elérheti akár a háromszoros szintet, illetve az üzemidő is nő, hiszen az ART-ra írt programok hatékonyabban futhatnak. Az új futtatási környezet többféle fordítási lehetőséget is tartalmaz (Ahead of Time, Just in Time, interpreted), emellett az Android L hatékonyabban bánik a memóriával is, ami lényeges előny, hiszen az aktuális Android operációs rendszerek ebből a szempontból igen pazarlóak, ami időnként lassulásokhoz vezet.
A grafika szempontjából is megújul az Android L. Az alacsony szintű hardverelérést biztosító grafikus API-k előretörésével várható volt, hogy a Google is újít valamit, de ez nem feltétlenül az, amit a piac zöme várt. Az Androidon marad az OpenGL ES 3.1, ami elég komoly versenyhátrány a konkurensekkel szemben, de bemutatkozott az AEP, ami az Android Extension Pack rövidítése. A Google az ARM, a Qualcomm és az NVIDIA partnereként olyan OpenGL ES kiterjesztéseket tervez, mely lehetővé tesz az Android L operációs rendszeren a tesszelláció, a geometry shader és az ASTC textúratömörítés kihasználását, míg a compute shadert az OpenGL ES 3.1 biztosítja.
Bár a kiterjesztéseket a fejlesztők jellemzően gyűlölik az OpenGL API-kban, ám a Google ezúttal kezeskedik értük. A szabványnak ugyan nem része az AEP, de szigorú specifikációk vannak megfogalmazva, hogy a gyártók implementációi megfelelők legyenek. A Google sokat merített az OpenGL 4.4 ARB specifikációiból, így biztosítva azt, hogy az AEP-be később beszálló gyártók is tudjanak rá kompatibilis implementációkat készíteni.
Az AEP a fejlesztők körében még nem túl népszerű. Egyelőre csak az Unreal Engine 4 támogatja és ennyi. Ma már persze számos fejlesztő nem hisz a vállalhatatlanul elavult rendszerek foltozgatásában, amit tulajdonképpen az AEP tesz, de a piac lefedése akkor is komoly érdek. Még ha kényszerből is, de többek között a Unity támogatására talán még számíthat a Google.
