A Microsoft Surface tabletek felhasználói ismerhetik azt az érzést, hogy a 32GB-osként hirdetett eszközön a Windows telepítése után adott esetben mindössze 5-10 GB szabad hely marad. Nos, az Apple valószínűleg nem szeretné ilyen élményekben részesíteni az iPhone- és iPad-tulajdonosokat, és ezért az elmúlt évben láthatólag sokat is tettek a cupertinói cég mérnökei. Az iOS 9-es verziójának telepítéséhez szükséges OTA delta update például csak 1.3GB, ellentétben például az iOS 8 monumentális, 4.58GB-os csomagjával, (nemcsak) a sárga 8GB-os iPhone 5c-tulajdonosok nagy örömére.

Az operációs rendszer és a beépített alkalmazások mellett máshol is megnyirbálták a fejlesztők a fájlméreteket. Az idei WWDC egy másik fontos bejelentése az App Store “App Thinning” fantázianévre hallgató új szolgáltatása volt. Az iOS alkalmazásboltjának és a hozzá kapcsolódó, külsős alkalmazásfejlesztők által is használható eszközöknek és API-knak ez az új képessége három dimenzió mentén csökkenti a letölthető alkalmazások méretét.

Az első és a méretcsökkenésen kívül egyéb előnyökkel is járó módszer az Apple által már eddig is használt LLVM toolchain előnyeit aknázza ki. Ezzel kapcsolatban az interneten már most rengeteg téves információ kering: e sorok írója még nem találkozott olyan technológiai oldallal, ahol helyesen közölték volna a lényegét. Ezeket a félreértéseket is szeretnénk itt és most tisztázni.

Rögtön az egyik első találat a Google-ben ez az angol nyelvű cikk, amely megpróbálja elmagyarázni – sikertelenül – a bitkód alapú fájlméretcsökkentés lényegét. A szerző először is kifejti, hogy…

A hab a tortán az Apple igény szerinti alkalmazásfordítása, amelyet Bitkódnak (sic!) nevezett el.

Nos, a bitkód nem ennek a fordítási folyamatnak a neve (és mégcsak nem is tulajdonnév, hogy nagybetűvel kelljen írni), hanem magának a kódtípusnak a neve, amit a fejlesztők mostantól fogva a “nyers” bináris helyett fognak feltölteni az App Store-ba.

Az idézett szerző az ezután következő mondatával sem menne át például egy egyetemi programozásvizsgán:

A fejlesztők nem előre lefordított binárisokat fognak feltölteni, hanem egy “köztes reprezentációt” — ez valószínűleg egy, a forráskódot és az egyéb erőforrásokat tartalmazó csomag.

A hiba ott rejlik, hogy a köztes reprezentáció (IR) nem forráskód (szinte biztos, hogy a fejlesztők többsége a forráskód közvetlen feltöltésébe a “szellemi tulajdonra” és egyéb jogi problémákra hivatkozva egyáltalán nem egyezne bele). Sőt, a “nem előre lefordított” kifejezés sem állja meg a helyét – hiszen az IR már maga is egy fordítási-optimalizálási folyamat eredménye.

Lássuk a fecskét!

Az iOS-re írt C, Objective-C, C++ és Swift nyelvű programokat ugyanis a maguk fordítóprogramja (a C család esetén ez a clang, Swift esetében pedig a swiftc) néhány köztes lépés után LLVM bitkódra fordítja, majd az LLVM innentől átveszi az irányítást – a bitkódot optimalizálja, majd assembly-t vagy rögtön tárgykódot generál belőle.

Az LLVM bitkód tehát, amint azt már fent említettük, egy úgynevezett “Intermediate Representation”, amely a magas szintű programozási nyelvek (Objective-C, Swift, …) és a platformfüggő gépi kód (például x64 vagy ARM utasításkészlet) között helyezkedik el. Gyakorlatilag egy általános processzor utasításkészletéhez hasonlít, amely – mivel sem a programozó által használt nyelvtől, sem a megcélozni kívánt konkrét hardvertől nem függ – hatékonyan használható széleskörű optimalizálásra. Az “App Thinning” azonban a hardverfüggetlenségnek nem is ezt a jó tulajdonságát használja ki.

A fejlesztők egy alkalmazás elkészültekor mindezidáig magát a végrehajtható fájlt töltötték fel az App Store-ba. Mivel az egyes iOS-eszközök szinte minden generációja más processzorral rendelkezik, ezért – bár a legtöbb új chip visszafelé kompatibilis elődeivel, és képes azok kódját futtatni – a “vas” képességeinek maximális kihasználása érdekében érdemes volt minden megcélzott CPU-ra lefordítani a kódot, és a keletkező, úgynevezett “kövér” binárist beküldeni, amely minden architektúra kódját tartalmazta. Az alkalmazás telepítésekor pedig a teljes kövér fájl letöltődött a készülékre – ennek pedig legalább fele (a két vagy több architektúrájú kód közül egy kivételével minden) teljesen fölösleges volt.

Ha viszont csak az alkalmazás bitkódos – tehát processzorfüggetlen – formája kerül feltöltésre, akkor az App Store erre beállított szerverei egy adott készülékre való letöltés előtt le tudják fordítani kizárólag arra az architektúrára, amit az adott iOS-készülék hardvere képvisel. Ekkor tehát nem lesz a binárisnak “fölösleges” része, ami adott esetben (egy több tíz vagy száz MB-os bináris esetén) jelentős helyspórolást jelenthet.

Az LLVM bitkóddal kapcsolatban egy másik tévhit is megjelent. Voltak, akik az Android által használt Dalvik virtuális gép bájtkódformátumához hasonlították (alkalmasint el-elsütve azt a hibás megjegyzést, miszerint az Apple csak most ruházta fel azzal a képességgel az iOS-t, amivel az Android már évek óta rendelkezett). A kétféle kód jellege és felhasználása azonban gyökeresen eltér. Nézzük is meg, pontosan miben:

1. Az LLVM bitkód egy főleg intermediate representation-ként, az alacsony szintű optimalizáció tárgyaként használt kód. Lehet interpretálni (az LLVM toolchainben létezik egy IR interpreter), azonban ez a felhasználása nem jellemző, és az iOS egyáltalán nem is használja. Ezzel szemben a Dalvik VM bájtkódját (dex vagy odex formátum) kifejezetten interpretálásra, esetenként futásidejű fordításra (Just-In-Time compilation) használja az Android. (És bár az LLVM JIT-ként való működtetése egyébként széleskörűen elterjedt, az iOS biztonsági okokból harmadik féltől származó kód esetén ezt sem használja ki.)
2. A Dalvik bájtkódot kifejezetten arra fejlesztették ki, hogy a Java virtuális gép formátumából viszonylag hatékonyan tudjon dolgozni, ezért például bizonyos tekintetben szoros kapcsolatot mutat a JVM utasításkészletével. Az LLVM bitkód ezzel szemben teljesen független az őt generáló magasszintű nyelvtől – többek között ezért lehetséges az, hogy iOS-re mind a C-család nyelvein, mind Swiftben egymással könnyen együttműködő modulokat fejlesszünk.
3. Az App Store új fejlesztésével együtt az iOS-készülékekre még mindig natív futtatható fájlok érkeznek. A készüléken tehát – legalábbis itt – nincs szükség JIT-fordításra, ami kis pozitív hatással lehet például az indulási időkre, de egyben azt is jelenti, hogy magán az iOS-en nem történik interpretálás sem, ami megint csak gyorsabb futást eredményez. További előnye az Apple megoldásának az, hogy ha az LLVM optimalizációi fejlődnek, erősödnek és gyarapodnak, esetleg azokban hibákat találnak és kijavítják őket, akkor a felhasználónak nem kell a készülékén operációs rendszert frissítenie, hogy az abba épített új interpreter vagy JIT képességeit élvezhesse. Az Apple ugyanis mindig a saját szerverein fordítja le az alkalmazásokat natív kódra, így a következő letöltéskor a felhasználó mindig a legfrissebb, “legokosabb” optimizer által generált natív kódot kapja.

Nemcsak a binárisoké a világ

A fentiekkel együtt azért be kell vallanunk, hogy a tényleg nagyméretű (gigabájtos) alkalmazásokban általában nem maga a végrehajtható fájl a domináns. Sokkal inkább a különféle “erőforrások”: képek és videók, egy játék hangeffektusait tartalmazó hangfájlok, vagy az offline navigációs appok adatbázisai. Ezeknek a szelektív letöltésére is lehetőségünk lesz az iOS 9-től kezdődően, méghozzá a lehető legnagyobb rugalmasság érdekében rögtön kétféleképpen is.

Az első módszer az automatizálásra helyezi a hangsúlyt. A binárisok “zsírleszívásának” mintájára ez a metódus is arra épül, hogy az egyes készülékeknek fizikailag más-más fájlokra van szükségük a futáshoz. Tekintsük csak például a képek példáját. Egy régebbi készülék egyszeres felbontású kijelzővel rendelkezik, amihez felesleges a nagyobb felbontású képeket letölteni, hiszen a képernyő úgysem tudná azokat jobb minőségben megjeleníteni. Az újabb, Retina kijelzővel rendelkező iPhone-oknak és iPadeknek viszont az egyszeres felbontású képekre nincsen szükségük, ugyanis ha a hardver tudja kezelni a nagyobb felbontású képet, akkor miért kárhoztatnák a felhasználót arra, hogy a rosszabb minőségűt mutatjuk neki?

A második módszer az “On-Demand Resources” (magyarul körülbelül “igény szerinti erőforrások”) nevet viseli. Ennek az eljárásnak a legfőbb jellemvonása, hogy a fejlesztők dinamikusan tudják az alkalmazás használatához igazítani a letöltött fájlokat – például egy játék esetében a különféle pályák és szintek közül elég annak meglennie a készüléken, amelyikkel éppen játszanak. Ezeket a fájlokat (pontosabban fájlcsoportokat) az Apple a saját szerverein tárolja, és azokat egyenként, egy címke alapján lehet lekérdezni. A letöltés teljesen automatikusan, a fejlesztők részéről minden erőfeszítés nélkül, transzparensen történik. A fájlok pedig letöltés után egy cache-ben maradnak a gyors elérés érdekében, a rendszer viszont kitörölheti azokat, ha úgy ítéli meg, hogy kevés a szabad hely a háttértáron.

Ezek tehát az App Store és az iOS 9 közreműködésével megvalósuló helymegtakarítási praktikák.

Mi a véleményetek, vajon melyik ezek közül a legfontosabb és leginnovatívabb?