App Thinning: így takarít majd meg tárhelyet az App Store a készülékeden

Ez a cikk legalább 1 éve frissült utoljára. A benne szereplő információk a megjelenés idején pontosak voltak, de mára elavultak lehetnek.

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.

dfWZLYmX

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.

Screen Shot 2015-06-12 at 00.13.42

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?

Screen Shot 2015-06-12 at 00.06.00

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.

Screen Shot 2015-06-12 at 00.06.49

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?

Ezek még érdekelhetnek:


  1. “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 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.”
    Most ez komoly? Én nem tudom, hogy hol él a cikk írója, de nem tűnt fel neki, hogy a iPhone telefonok 8 16 32 stb GB-nak vannak hírdetve, közben pedig közel nincs rajta annyi szabad hely, aminek hírdetik. A 8 gigás telefonon 5,3 gb a SZABAD kapacitás. Tényleg nem részesíti, csak amióta iPhone létezik ezt csinálja az Apple. Miről tetszik beszélni? Ráadásul az iPhone az egyedüli telefon, amit nem lehet bővíteni. De legalább jó drága. Az eszem megáll az ilyen irományoktól. Jézusmária. Elég csúnya dolog megtéveszteni az embereket. Ez nagyon gáz, kedves cikkíró!

  2. @makimano: ugye azért érzed az érdemi különbséget, hogy míg a 32GB-ból 22-27GB-ot vesz el a rendszer, addig az iPhone-ok esetén ez arányaiban lényegesen kevesebb? amellett minden egyes eszköz esetén le van írva az is, hogy: “1 GB = 1 milliárd bájt; a formázás utáni tényleges tárhely ennél kevesebb.”, tehát egyrészt nem 1024-gyel váltanak át, ami miatt már eleve nem annyi a felhasználható tárhely, másrészt a formázás is csökkent ezen – de ez még mindig nem annyit, mint a Surface esetén, hogy ~80%-ot (átlag 25GB-tal számolva) elfogyasszon a rendszer. a cikkíró erre utalt, felesleges túlgondolni.

    ha a 8GB-ot vesszük alapul, az általad említett 5,3GB fennmaradó szabad hely nagyjából 34%-ot (2,7GB) jelent a rendszer számára egy 8GB-os iPhone esetén, ez 32GB-ra vetítve (a rendszer mérete viszont ugyanannyi marad!) pedig már csak 8,43% körüli, ami közel tizede csak a 80%-nak (9,5%).

    az iOS-es készülékeken a rendszer által felhasznált hely az évek során a funkciókkal párhuzamosan növekedett, de a fizikai tárhely egy már legyártott készüléken nyilván nem fog növekedni. ettől függetlenül egy 32GB-os készüléken az iOS egyetlen verziója sem fogja a készülék tárhelyének közel 80%-át elfoglalni telepítés után, és az időben visszafelé menve egyre csökken a rendszer által elfoglalt terület, tehát nem lehet azt sem mondani, hogy ez mindig is így lett volna. valamennyit nyilván foglalt, de arányaiban mégsem ennyit.

  3. @AppleFan: látom, az arányokkal való viszonyítás neked sem megy. de így akkor a pontosított számokkal újraszámolom neked.

    ha már tablet, akkor egy iPaddel a Surface RT mérhető össze leginkább:
    kapacitás / szabad tárhely / a rendszer által elhasznált
    32 GB / 15 GB / 17GB-ot, vagyis ~53,125%-ot foglal a rendszer legfrissebb verziója
    64 GB / 44 GB / 20GB-ot, vagyis ~31,25%-ot foglal a rendszer legfrissebb verziója

    viszont ez a számítás így nem helyes, mert a Surface RT esetén a 32GB helyett a decimális rendszer miatt már csak 29GB van formázás után (64GB-on meg 59GB), ebből elvesz 5GB-ot a recovery partíció, majd 8GB-ot a rendszer a beépített appokkal. így újraszámolva az arányokat:

    tényleges kapacitás / szabad tárhely / a rendszer által elhasznált
    29 GB / 15 GB / 12GB-ot, vagyis ~41,38%-ot foglal a rendszer legfrissebb verziója
    59 GB / 44 GB / 15GB-ot, vagyis ~25,42%-ot foglal a rendszer legfrissebb verziója

    http://www.cnet.com/news/microsoft-explains-low-surface-storage-in-weak-support-note/

    és ez még mindig sokkal több arányaiban, mint bármelyik 8GB-os, iOS-t futtató készülék esetén.

  4. @makimano: a Surface-en az egyharmadot sem éri el a szabad hely. A 8 gigás iPhone-on pedig több, mint kétharmad. Ezt összemosni a megtévesztő. Amúgy a cikk teljesen másról szólt! Kitűnően megírt, informatív, hiánypótló munka, köszönet!

  5. Jadeye: Kit érdekel az iPad? 😀

    Nem érdekelnek az arányok. Nem is írtam arányokról, el sem olvastam a válaszod mert nem érdekel. Annyit írtam hogy nem 5-10gb marad hanem tobb. Az hogy melyiken milyen arányban milyen fos az nem érdekel. 😀

  6. @AppleFan: “Cikk író” köszöni és egybeírja a munkakörét (“cikkíró”). Egyébként nem tudom, hogy feltűnt-e, de a cikk legelső két linkje konkrét esetekről, példákról szól, ahol a meghirdetett kapacitásnak csak töredéke marad. (Na, találd ki, hol találtam őket: a Google-ön…) Nem mindegy, hogy 8 GB-ból szabad 5, vagy 32-ből. A Surface-jelenség amúgy is csupán az írás bevezetője, a lényeg az elsőt követő maradék pár tucat mondatban van, esetleg érdemes azokat is elolvasni…

Írd le a véleményedet! (Moderációs elveinket ide kattintva olvashatod.)

Hozzászólás írásához be kell jelentkezned!