Ezt adja a fejlesztőknek az új Android, a KitKat

Alapoktól átrendezett memóriakezelés

A KitKat fejlesztésénél a Google nagy hangsúlyt fordított arra, hogy régebbi, illetve belépő szintű modelleken is elfogadhatóan fusson az operációs rendszer. A piacon több százmillió olyan androidos eszköz van, amely csak fél gigabájt RAM-mal rendelkezik, ezeket igyekszik kiszolgálni a KitKat alacsonyabb memóriahasználatot eredményező néhány újdonsága. A Dalvik JIT cache-viselkedésének optimalizálásával memórianyomás esetén dinamikusan csökken az alkalmazások által elfoglalt tár mérete (némi teljesítményveszteség árán), a Kernel SamePage Merging pedig a memóriát "deduplikálja", vagyis az azonos lapokat összevonja. Ez utóbbi a párhuzamosan betöltött könyvtárak esetén értékes, ezeket a lapokat jellemzően nem írja a rendszer, csak olvassa, így a KSM nagy megtakarítást hozhat. Szintén újdonság a Linux zRam modul megjelenése, amellyel a háttértárra swappelés előtt inkább tömöríteni igyekszik a memóriát a rendszer, ezzel a beépített eMMC-nél gyorsabb, a tömörítetlen memóriánál lassabb új réteg jelenik meg a memóriahierarchiában.

A rendszer maga is számos ponton átalakult, a kód alapos optimalizálásával a kulcs rendszerfolyamatok kisebb heappel is beérik, ezt azonban az Android sokkal agresszívabban védelmezi a nagy memóriaigényű alkalmazásokkal szemben. További optimalizáció, hogy a háttérben futó folyamatok indítását a KitKat igyekszik időben eltolni, így az I/O és memóriacsúcsok nem esnek egybe. Ilyen szituáció például, mikor az utcáról hazaérve a telefon átáll 3G-ről WiFi-re, és rengeteg alkalmazás akar hirtelen  kapcsolatot létesíteni.

A memóriával kapcsolatos szituáció a fejlesztő számára is lekérdezhető egy új API-n keresztül. Az ActivityManager.isLowRamDevice() segítségével az alkalmazás viselkedése hozzáigazítható a telefonban található RAM-hoz, így például más gyorsítótárazási stratégia működhet kevés memóriával rendelkező modellek esetében és lekapcsolható néhány, nagy memóriahasználattal járó funkció. A fejlesztőknek két új eszközt is készített a Google, a procstats segítségével megnézhető, hogy időben hogyan változott az eszközön az alkalmazások memóriahasználata, a meminfo pedig a korábbinál részletesebb adatokkal szolgál az esetleges problémák kiszúrására.

NFC-áttörést hozhat a Host Card Emulation

Az androidos NFC egyik nagy hátulütője volt, hogy biztonságos környezetet igénylő használatához szükség volt egy Secure Elementre a rendszerben. Ez tipikusan egy speciális SIM-kártya volt, amely a rendszertől teljesen elzártan, biztonságosan tárolta az NFC-s tranzakcióhoz szükséges adatokat. Ezt a funkciót a KitKatben már átveszi az Android, a Host Card Emulation képesség implementálásával már nem kizáró feltétel a szolgáltató együttműködése például egy mobilfizetési rendszerhez.

Mondani sem kell, ez alaposan átrendezi a viszonyokat az NFC-s fizetés kialakulóban lévő piacán. A KitKattől fogva ráadásul a telefonok HCE módú kártyák olvasójaként is funkcionálhatnak, vagyis nem csak vásárolni, de eladni is lehet egy ilyen készülékkel. A HCE elsősorban az amerikai piacon hozhat áttörést, ahol a Google Wallet használatát a legtöbb szolgáltató blokkolta, az új technológia segítségével ez megkerülhető lett. "Az Android HCE az ISO/IEC 7816 szabványt támogató smart card eszköz működését emulálja, amelyek az ISO/IEC 14443-4 (ISO-DEP) protokollt használják adattoábbításra" - áll az Android fejlesztői oldalán. A nagyközönségnek semmitmondó számok az Europay-MasterCard-Visa által használt protokollt jelentik, vagyis a HCE-t támogató eszközök automatikusan támogatják a nagyok kártyás fizetési megoldásait.

Felhős nyomtatási és tárolós keretrendszer

A KitKat végre támogatja a Google felhős nyomtatási rendszerét, a Cloud Printet, de beépülő modulokkal ez a támogatás más szolgáltatásokra is kiterjeszthető. A KitKat API-kat használva a nyomtatógyártók is készíthetnek ilyen modulokat, a Google példájában már a HP megoldása szerepel, a Print Service Plugin feltérképezi a hálózaton található nyomtatókat és felajánlja ezeket célpontként. A telepített beépülők a beállítások új, nyomtatás nevű menüpontja alatt kezelhetőek, egyébként ezek a Play Store-ból lesznek elérhetőek és telepíthetőek. A nyomtatás az Android megosztási infrastruktúráját használja, de nem működik automatikusan minden share-kompatibilis alkalmazással. A nyomtatáshoz egyedi API-k tartoznak, és szükséges, hogy az alkalmazás átmeneti dokumentumként egy PDF-et generáljon a megosztani kívánt adatokból, a rendszer ezt adja át a nyomtató keretrendszernek.

A Google egy csapással megoldja az online tárhelyek töredezetttségének a problémáját is. A telepített tárhely-appok (Drive, Dropbox, Box, Skydrive, stb.) beregisztrálhatják magukat a rendszerbe, ezután pedig az alkalmazások számára egyedi partícióként érhetőek el, így a fájlok könnyedén megnyithatóak vagy menthetőek. A megoldáshoz szintén új API-k tartoznak, amellyel a szolgáltatás által kínált funkciók lefordíthatóak a rendszer néhány alap képességére (böngészés, beolvasás, feltöltés). A keretrendszer implementációja egyszerű frissítésként leküldhető, így a meglévő felhasználók számára is (a KitKat telepítését követően) elérhetővé tehető.

A tárolórendszer a kliensalkalmazásokban (amelyek a dokumentumok kezelését-megnyitását végzik) egyszerűen implementálható, az új create_document és open_document intenciók használatával. Ez megnyitja a szabványos tárolós UI-t, amelyben a felhasználó kiválaszthatja a regisztrált szolgáltatásokat és fájlműveleteket végezhet. Az új megoldás visszafelé kompatibilis, a korábbi get_content intencióhoz rendelt korábbi műveleteket is megjeleníti, így az átmeneti időszakban sem maradunk fájlműveletek nélkül. A KitKaten alapértelmezésben a Drive és a helyi háttértár, valamint a letöltések mappa jelenik meg gyárilag tárolóként, a lista pedig a telepített alkalmazások révén bővül.

Összevont érzékelők

A Google észlelte a változatos érzékelők energiafogyasztásával kapcsolatos problémákat és a Sensor Batching formájában megoldás is készült rá. Az iOS új Core Motion keretrendszeréhez hasonlóan az új szoftver az alkalmazás és a hardver közötti köztesréteg, elsődleges feladata mérsékelni a rendszerszintű fogyasztást. A Google ezt úgy igyekszik elérni, hogy az alkalmazástól átveszi az adatok lekérésének precíz időzítését, és igyekszik az érzékelőt és a processzort egyszerre, rövid időintervallumokra felébreszteni, majd minél hosszabb időre lekapcsolni.

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

A keretrendszert használó alkalmazás meghatározhatja, hogy milyen gyakran szeretne adatot kapni, az időzítéssel kapcsolatos többi feladatot a rendszer átveszi. A Google szerint a Sensor Batching az olyan, viszonylag hosszú ideig futó alkalmazások esetén lesz hasznos, mint a fitneszappok, pozíciókövetés, a cég szerint ezek az alkalmazások a Sensor Batching használatával akár egész nap futhatnak (adatkérés sűrűségétől függően), annyira alacsony az új keretrendszer fogyasztása. Az új rendszert egyelőre csak a Nexus 5 támogatja, ahogy a megfelelő meghajtók elkészülnek a többi szenzorhoz, úgy válik szélesebb körűvé a technológia támogatása.

Új UI és Chrome-alapú WebView

A KitKat némi ráncfelvarrást is hoz a Holo témához, a fejlesztők számára is található ebben érdekesség. Az első a teljes képernyős üzemmód, amelyben a teljes rendszer UI eltüntethető, beleértve az állapotsort és az alsó gombokat is, ezek egy alulról vagy felülről indított gesztussal húzhatóak be igény szerint. Az alkalmazáson belül használható animációk is kaptak egy vérfrissítést, ami várhatóan kicsit "mozgalmasabbá", átélhetőbbé teszi az egységsugarú felhasználók számára az Android használatát, a különböző kijelzők közötti átmenetet.

Az alkalmazások és a rendszer közötti vizuális akadály lebontása nevében az alsó és felső rendszersáv immár áttetszővé tehető, tetszőleges háttérrel - alkalmazásokon belül is. Hogy az itt feltüntetett adatok mégis olvashatóak maradjanak, egy enyhe gradiens segítségével érte el a Google. Az áttetsző sávok használatát külön engedélyezni kell az alkalmazásban a megfelelő ablakstílus meghívásával.

A HTML5-JavaScript-alapú, WebView-t használó alkalmazások számára hatalmas változás, hogy a megjelenítés alapját a KitKattől fogva a Chrome 30-as kiadása látja el, ami új szabványok támogatását és számottevően gyorsabb JavaScript-teljesítményt hoz. A fejlesztők örömére a WebView támogatja a Chrome DevToolst is, így a teljesítményhangolás sokkal hatékonyabb lehet.

Multimédiás finomságok

A KitKat a multimédiás alrendszerben is fontos újdonságokat hoz. Megjelent a kijelzőn megjelenő információ videóként rögzítésének lehetősége, amellyel MP4 formátumban vehetjük fel a felhasználó tevékenységét. A rendszer alapértelmezetten támogatja az MPEG-DASH (és a hozzá kapcsolódó DRM) adaptív streaming formátumot is, ez a webes videók megjelenítésében hoz majd óriási előrelépést, ahogy a tartalom a hálózati sebesség függvényében, automatikusan válthat felbontást. További újdonságok között szerepel a DSP tunneling, amellyel a hangszínszabályozott lejátszás energiahatékonysága növelhető és megjelent a Wi-Fi minősítéssel ellátott, hivatalos Miracast-támogatás is.

Az Android 4.4-gyel alapos ráncfelvarrást kapott a Google OpenCL-riválisa, a RenderScript is, amely azonos, GPU-gyorsítást igénylő kódon 20-60 százalékos gyorsulást képes elérni a cég becslései szerint. Első körben a gyorsabb RenderScript a Nexus 4-5-7-10 négyesen érhető el, ahogy a friss meghajtók elkészülnek, a támogatás köre kibővül. A sima gyorsulásnál talán nagyobb dobás, hogy a RenderScript végre elérhető Android NDK-val készülő, nem-Java alkalmazások esetében (ezek elsősorban játékok), az új C++ API-val. Ez utóbbi ráadásul visszamenőleg is érvényes, egészen Android 2.2-ig támogatott a natív RenderScript használata.

Az új Android 4.4 KitKat további újdonságairól itt érdemes olvasni. Az új Android fejlesztői újdonságairól az App!mobile konferencia workshopjain és a december elején induló App! Android Update képzésen is alaposan beszélünk majd.