Az idei évben formabontó irányzatnak számított az alacsony szintű hardverelérést biztosító grafikus API, amelyből a Google meglepetésre kimaradt, mivel a vállalat az Androidra az AEP, azaz Android Extension Pack kiterjesztést kínálta az OpenGL ES 3.1-es API-hoz.
Az eseményekkel kapcsolatban számos Androidban érdekelt, grafikus vezérlőt is fejlesztő gyártót megkérdeztünk, hogy a Google, fejlesztők által láthatóan nem támogatott koncepciója mennyire jelent majd problémát a piac változásait figyelembe véve.
A hivatalos válasz szinte minden esetben az volt, hogy az AEP jövőbiztosnak tekinthető, vagyis nem kell tartani az Android technológiai lemaradásától. Szerencsére több cég esetében a kérdéseket sikerült némi beszélgetéssel felváltani, így kiderültek olyan apró részletek is, amelyekről eddig kevés részlet szivárgott ki.
Többek között megtudtuk, hogy a Google nagyon is foglalkozik magával az alapproblémával, csak éppen a túlzott fragmentáció következtében nem tudnak annyira radikális megoldásokat bevetni, mint amilyet az Apple és a Microsoft megengedhet. Ez rendkívül logikus meglátás, hiszen az Apple saját lapkákat fejleszt és azokban sorra az Imagination által fejlesztett IGP-k köszönnek vissza, még ha a hivatalos elnevezés tekintetében manapság az Apple neve olvasható ki a grafikus meghajtókból. Ugyanez elmondható a Microsoft esetében is, hiszen a redmondi óriáscég a Qualcomm fejlesztéseire épít, vagyis Adreno IGP-vel rendelkező rendszerchipek kerülnek a Windows Phone eszközökbe. Ezzel szemben az Androidon megtalálhatók a Qualcomm, az Imagination, a Vivante, az NVIDIA, a ZiiLabs és a Broadcom megoldásai, vagyis rendkívül sok opciót kell figyelembe venni, amelyek sora ráadásul a jövőben bővülni fog.
A Google több vállalat véleménye alapján úgy gondolta, hogy egy ennyire fragmentált piacra hiba lenne bevezetni egy alacsony szintű hardverelérést biztosító grafikus API, így az Android Extension Pack kifejlesztése nem egy önálló döntés volt, hanem egy gyártókkal megbeszélt és mindenki által elfogadott lépés.
Az Android operációs rendszerben érdekelt cégek szerint egyértelmű előnyei vannak az alacsony szintű hardverelérésnek. Kár vitába szállni azzal, hogy sokkal több lehetőség adódik a fejlesztők előtt a hardver hatékony kihasználására vonatkozóan, de soha senki sem beszél az új API-k hátrányáról. Nevezetesen arról, hogy a grafikus meghajtó egy igen vékony réteg lesz a hardver és az adott program között, vagyis a hardver optimális vezérlését az adott alkalmazásnak kell ellátnia.
A gyártók szerint az egész irányzat alapötlete csupán annyi, hogy konzolon ez a modell működik. Ez ugyan bizonyított tény, viszont egy fix hardverre van optimalizálva minden, tehát az absztrakció mértéke minimális. Megfelelő ellenőrzés mellett valóban ki lehet terjeszteni a koncepciót pár hardverre, de nem lesz olyan fejlesztőstúdió, amely több tucat architektúraspecifikus optimalizálást ír majd a programjába. Ez baj, mivel utóbbi hiánya az elméletben elérhető teljesítmény kétharmadának elvesztésével járhat. Erre elvileg azért nem láttunk még példát, mert az elérhető, alacsony szintű hardverelérést biztosító grafikus API-k jelenleg egyetlen gyártóhoz köthetők, tehát a fejlesztőknek nem kell megküzdeni több, alapjaiban eltérő architektúra specifikus optimalizálásával.
Szintén megtudtuk, hogy egy API specifikációjának sincs különösebb jelentősége, addig amíg az támogatható egy adott architektúra által. Alacsony szintű hardverelérés esetén a teljesítményt nagymértékben az adott alkalmazás fejlesztője fogja meghatározni aszerint, hogy mely architektúrákra optimalizálta magát a programkódot, illetve melyekre nem.
A Google úgy néz ki, hogy a partnereket bevonva egy egyszerű döntést hozott, mivel úgy gondolhatták, hogy az alacsony szintű hardverelérés összes előnye nem ér annyit, amennyi hátrányt ez a modell hozhat az Androidon mérhető fragmentáció mellett, így maradt az AEP, amely a fentiek tudatában lehetséges, hogy elfogadhatóbb alternatíva.
