Fejlesztés: Miért érezzük fürgébbnek az iOS-t az Androidnál?

Ha megkérdeznénk az Apple rajongókat, hogy miért jobb az iPhone az androidos készülékeknél valószínűleg előkelő helyen szerepelne az a válasz, hogy az iOS egyszerűen gyorsabb és sokkal simábban működik, mint a Google rendszere.

Nem ritka, hogy az Android lassan reagál, akadozik, (laggy) a képernyő érintésére, az iPhone pedig néha mintha már azelőtt tudná, hol akarjuk megérinteni a képernyőt, mielőtt az ujjunk hozzáérne.

De hogyan sikerült ezt ilyen jól megoldania az Apple-nek? Andrew Munn, a Google egyik volt szoftverfejlesztő gyakornoka szerint a helyes kérdés inkább az, hogy a Google hogyan tudta így elrontani az Androidot? Munn szerint az Android ezen a téren lehet, hogy sosem fogja tudni utolérni az iOS-t.

Hogy megértsük, mi ennek a nehezen megfogalmazható felhasználói érzésnek az alapja, szükséges egy kis háttér-információ. Korábban azt állították, hogy az Android felhasználói felülete azért tűnik lassúnak az iOS-hez képest, mert a felület a Honeycomb megérkezéséig nem volt benne a hardveres grafikus gyorsítás lehetősége. Más szóval, minden egyes alkalommal, amikor húzod az ujjad a képernyőn a CPU-nak az összes pixelt újra kell rajzolnia, ebben pedig nem igazán jók a CPU-k.

Ez az érv rendben is lenne, ha a Honeycomb megérkezésével megoldódott volna a probléma. Az Android eszközök azonban a 3.0-ás verzió telepítése után is döcögősek maradtak. Pedig a drágább Android telefonok hardveresen legalább olyan erősek, sőt némelyik erősebb is, mint az iPhone. Sokszor megírták már, hogy az iPhone 4S-ben is csak 512MB RAM van ellentétben a ma piacra kerülő 1GB-os android csúcstelefonokkal. Szóval a probléma semmiképp sem hardveres dolognak tűnik. De akkor mi lehet a gond?

Munn erre is tudja a választ. Az iOS-ben ugyanis a felhasználói felület képernyőre rajzolása és az interakciók figyelése külön szálakon fut valós idejű prioritással. A rendszer minden folyamatot megállít, ha ezen a szálon történik valami és olyankor csak erre összpontosít. Valahogy úgy képzeljük el, hogy amint megérinted a képernyőt, a rendszer azonnal átkapcsol egy őrült üzemmódba és minden más folyamatnak valami ilyesmit üzen: „Valaki tapogat, valaki tapogat, bármit csinálsz, állj le vele, valaki tapogat!”



Az Android esetében a felhasználói felület kezelése a fő szál mellett csak normál prioritást kap, vagyis az interakció közben is adatokat tölt le, emaileket, sms-eket ellenőriz a rendszer.
Munn szerint tehát két dolog miatt nem lehet soha olyan gyors az Android mint az iOS, amik már a kezdetektől fogva korlátozzák a rendszert:
– A felhasználói felület kezelése az alkalmazás fő programfutási szálán (thread) jelenik meg.
– A felhasználói felület kezelése csak normál prioritást kap.
Ameddig ez a két korlátozó tényező fennáll, addig a Galaxy Nexus-szal vagy akár a négymagos EeePad Transformer Prime-mal sincs garancia arra, hogy a képfrissítés zökkenőmentesen működjön. Állítólag a Galaxy Nexus ereje kell ahhoz, hogy az Android olyan folyamatosnak tűnjön, mint egy három éves iPhone. De akkor mi az oka annak, hogy Google Android csapata így oldja meg a renderelést?

Az igazság az – amit egyébként Eric Schmidt, a Google elnöke szívesen emleget –, hogy az Androidot még az iPhone megjelenése előtt kezdték el készíteni, és ekkor még a Blackberry vetélytársának szánták. Akkoribn az Android eszközök még nem voltak érintőképernyősek, így ez a módszer akkor egy jó kompromisszumos megoldásnak tűnt billentyűzettel szerelt telefonokra. Amikor az Apple bemutatta az iPhone-t, az Android csapat szeretett volna minél előbb piacra dobni egy olyan terméket, ami komoly vetélytárs lehet, de sajnos a felhasználói felület kezelésére szánt program átírására már nem volt idő.

De miért nem oldotta meg a problémát a Google? Nos, nem egyszerű feladat megoldani az Android Market összes alkalmazásának átírását úgy, hogy támogassanak egy új programozási interfészt. Valószínűleg ez a folyamat egy évig is eltartana, és éppen ezért lehetséges, hogy soha nem is következik be.

Szóval az Android lassú felületének problémáit csak egy módon oldhatja meg végleg a Google, ha nyomnak egy resetet és lerombolják a platformra felépített alkalmazások egész rendszerét. Ezzel szemben az iOS-t már az alapoktól multi-touch készülékekhez fejlesztették.

Várjuk a hozzáértő fejlesztők hozzászólásait! Tényleg ilyen egyszerű a magyarázat?
36 hozzászólás
bagi1992
2011. 12. 11. @ 16:22
bagi1992 képe

Ez egy korrekt cikk! Nem pletyka, komoly témája van alátámasztással. Jöhet még sok ilyen!

pontscho
2011. 12. 11. @ 17:40

– A felhasználói felület kezelése az alkalmazás fõ programfutási szálán (thread) jelenik meg.

Ahogy iOS-on is.

llaszlo
2011. 12. 11. @ 17:41
llaszlo képe

Már csak egyet nem èrzek. A MIUI csapata, hogy a fenébe tud sokkal jobb rendszert kèszíteni, mint a gyàri? Sajnos az sem lag mentes, de messze jobb, mint bàrmi màs. Valamit akkor csak lehetne csinàlni.

Artanis
2011. 12. 11. @ 17:50

hát a korrekt cikk az túlzás. se forrás, se semmi, láthatólag már magyar fordításból átvett cikk ez.

a droid más modellt használt az egészre, eddig ok. emellett nem csak az ios használja a realtime prioritásu szálat renderelésre, hanem ezt csinálja a wp7, webos.. qnx.

ennek meg pl azaz ára, ki is lehet próbálni, hogyha elkezdesz betölteni a safariban egy weboldalt, és az még nem töltõdött be, akkor elkezded rángatni összevissza folyamatosan, akkor bizony nem tölt tovább. mivel szinte minden erõforrást a real time szál elhasznál, és a telefon csak azzal törõdik hogy smooth legyen a scroll, ha elengeded, akkor tölti tovább.

ja, és meg fogja oldani az google azt, hogy mindenféle teljes reset nélkül hogy ott is jól müködjön, egyszerûen õk más utat választottak.

llaszlo
2011. 12. 11. @ 17:56
llaszlo képe

Van bárhol valami forrás arról, hogy eredetileg a droidot a BB vetélytársának szánták? Én ezt sehol sem találtam eddig. Pedig már korábban is kerestem. Egyszer egy helyen találtam errõl valamit már jó régen.

_ixc_
2011. 12. 11. @ 18:07

A beszelgeteszt Dianne Hackborn egy bejegyzese inditotta. Erre erkezett valasz Andrew Munn-tol.
A bejegyzes sajnos nem teljesen jol lett forditva.

Ajanlom nektek olvassatok el a valodi bejegyzest.

Sajat velemenyem: egyik ceg megoldasa sem jo; Mivel az apple nem fug mas gyartoktol, igy o konnyen javithatna meg a megoldasan.
Es a googlenel sem olyan drasztikus a helyzet ahogy itt le lett irva. 3.0 elott volt mar GPUval gyorsitott UI, de nem minden teruleten, ez a 3.0 utan is csak alkalmazas modositasaval kapcsolhato be.

sad_Vamp
2011. 12. 11. @ 18:14
sad_Vamp képe

LLaci: Elsõ "nexus" még bõven full billentyûs volt, sztem ez elmond mindent, emlékszem is rá, szíp fehír vót :D

llaszlo
2011. 12. 11. @ 18:16
llaszlo képe

@sad_Vamp
Errõl vannak valahol képek? Mert én kerestem csak nem találtam. Mindössze talán a modacon láttam 1-1.5 éve egy cikket errõl.

beszmac
2011. 12. 11. @ 19:33
beszmac képe

Artanis:

http://www.cultofmac.com/133624/why-android-will-always-be-laggier-than-ios/

SOHA nem veszünk át magyar oldalról cikket...

beszmac
2011. 12. 11. @ 20:39
beszmac képe

Frissítés:

A cikk még kedden jelent meg a CultOfMac-en.

A polémia valóban a _ixc_ által is megjelölt két cikk hatására indult al. A témában azóta nagyon tartalmas és érdekes cikkek születtek:

Bob Lee részben cáfolja a Munn által leírtakat, de nagyon gyengének tartja az androidos fejlesztõrendszert, ami nagy mértékben okozója a minõségi problémáknak:
http://blog.crazybob.org/2011/12/truth-about-android-ios-ui-performance.html

Danny Crichton pedig a két platform fejlesztõi közt meglévõ kulturális különbségekkel is magyarázza a dolgot és szintén a fejlesztõ-eszközöket ostorozza:
http://www.informedskeptic.com/2011/12/android-versus-ios-the-power-of-culture-and-tools/

The Last Boy Scout
2011. 12. 11. @ 21:13
The Last Boy Scout képe

Érdekes nézete ez is tényeknek. Való igaz, hogy gyorsabbnak tûnik az iOS, mivel eleve egyszálas rendszer, a multitaskot csak késõbb barkácsolták bele, de mint a fenti cikk mutatja, az is csak látszólagos. Így nézve a Classic MacOs sokkal fejlettebb megoldás, mint az OS X, hisz az is ilyen álmultitaskos egyszálú oprendszer, mint az iOS.
Viszont ha az Android UI-nak tényleg mindösszesen csak annyi a baja, hogy alacsony prioritással fut, ahogy ezek a szagemberek állítják, az nem olyan hatalmas programozói akadály, amit a google programozói nem tudnak megoldani. A prioritáskezelés optimalizálása nekem legalábbis nem tûnik annak.
Persze lehet ennek a VOLT programfejlesztõ gyakornoknak az volt, ezért is a VOLT jelzõ.

The Last Boy Scout
2011. 12. 11. @ 21:28
The Last Boy Scout képe

"SOHA nem veszünk át magyar oldalról cikket..."

Pedig nem ártana legalább rápislantani, hogy írnak mások. És nem a blikkre gondoltam :P

zenorbi
2011. 12. 11. @ 21:58
zenorbi képe

pontscho: Nemegészen. A fõ szálon marad, de más runloop-on. Próbáld meg azt, hogy létreohozl egy UITableView-t pár sorral, mellette meg fut egy timer amit szimplán inicializáltál, nem NSRunLoopCommonModes-al. Láthatod, hogy amint az UITableView-t megfogod, a timer leáll, ha elengeded, és az animációját is befejezte, a timer megint mûködik. NSRunLoopCommonModes-al.

A másik, hogy ha megpróbálsz valamit manuálisan animálni, akkor láthatod, hogy marhára akadozik. Ez azért van, mert az animációk UIViewAnimation-el történnek amit egy CALayer visz le alacsonyabb szintre. A titka az, hogy az animált részeket kiszedi egy külön részre, meganimálja majd visszarakja. Pont mint a css3 animációkkal a safari (feltéve, hogy opacity vagy transform amit animálsz). Az is plussz még, hogy animációnál megvan a mostani állás képe, és amikor indítod legenerálja a végsõ állás képét, így csak egy átmenet kell a 2 kép között. Pl ha egy UILabel-t animálsz szélességben, és a szövegnek meg kéne törnie, akkor meglátod a csalást, mert a végsõ szöveg egy nyújtott képét animálja be.

zenorbi
2011. 12. 11. @ 22:01
zenorbi képe

bocs ez lemaradt: NSRunLoopCommonModes-al a timer animáció közben is futni fog.

pontscho
2011. 12. 12. @ 01:04

Érdekes nézete ez is tényeknek. Való igaz, hogy gyorsabbnak tûnik az iOS, mivel eleve egyszálas rendszer, a multitaskot csak késõbb barkácsolták bele,

Ez meg egy boduletes marhasag. Mar az iPhoneOS v1.0 is kepes volt mind multitaszkra, mint multithread-re. Nem hivatalosan ki is lehetett hasznalni, mi ki is hasznaltuk mar akkoriban is.

@zenorbi: tudom. Viszont az OpenGL contextet, csak az a thread csesztetheti, amelyik a contextet letrehozta. Az ui szempontjabol legfeljebb az adminisztracios koltseget hordozo kod futhat mas szalon, az ami valoban meg is jelenit az csak egy szalon fut.

llaszlo
2011. 12. 12. @ 01:05
llaszlo képe

Nem az a lényeg, hogy használni tudjam a telefont és ne azzal szívni, hogy kattintok és nem reagál? Vagy pl amikor az SGS tesztjében azt lehet olvasni, hogy nem lehet felvenni a hívást, mert a telefon valamit szarakodik a háttérben? Pl telepít vagy frissít valamit. Hol nem .... le, hogy mit csinál amikor én használni akarom? Nekem az a lényeg, hogy ne szívjak azzal, hogy még telefonálni sem tudok rendesen vagy bármi mást csinálni. Érdekel az engem, hogy ezt hogyan érik el? NEM!

bubor
2011. 12. 12. @ 02:42

@llaszlo
Nem erdekel, ne kommenteld, ne olvasd.

Lassan mar annyira erosek a mobil hw-ek, tegra 3 4+1 magjaval, akar meg dedikaltan kaphat egy magot az ui. Nem kell javitani, egyszeruen a telefonok tulnovik a problemat.

llaszlo
2011. 12. 12. @ 02:44
llaszlo képe

@bubor
Ha nem tudsz szöveget értelmezni akkor te se olvasd!! Felesleges, pláne hozzászólni.

zenorbi
2011. 12. 12. @ 02:52
zenorbi képe

pontscho: OpenGL-rõl szó sincs most. Egyébként meg az OpenGL context-et más threaden is használhatod, csak bind-elni kell. Ami nem engedett az az, hogy egy OpenGL context-nek egyszerre 2 szálon küldjünk üzenetet, viszont ez is megoldható egy context share-el, az egyikbe ott van a textúra meg minden, a másikba meg a render szál. Az egész render lényege iPhone-on, hogy amikor animál, akkor kiszedi a standard renderbõl a nézetet, meganimálja OpenGL-esen majd visszarakja.

zenorbi
2011. 12. 12. @ 02:56
zenorbi képe

Egyébként ez a "de sajnos a felhasználói felület kezelésére szánt program átírására már nem volt idõ" tipikus példája annak, hogy egyszer spórolsz valamin, évekig fogsz miatta szívni. Nem azt mondom, hogy minden alapból meglegyen kódolag, de már gondoljanak a jövõre. Elsõ verzió mûködhet azzal a ronda rendereléssel, de a kód mögötte már fel legyen készítve a jövõbeli tervekre. Ha spóroltak, egyértelmûen tudtak róla, hogy kelleni fog ez.

intrex
2011. 12. 12. @ 03:12
intrex képe

EDM: "Érdekes nézete ez is tényeknek. Való igaz, hogy gyorsabbnak tûnik az iOS, mivel eleve egyszálas rendszer, a multitaskot csak késõbb barkácsolták bele, de mint a fenti cikk mutatja, az is csak látszólagos."

Tisztában vagy az iOS szálkezelésével? Egyszálas rendszer, aha :D

Amúgy pedig a legelsõ játékok amelyek 3 éve jelentek meg már folyamatos grafikát biztosítottak a touch screen folyamatos interakciója közben is.

Vagy a zenelejátszás, azt is ugyanaz az egy szál csinálja?

Jesszusom.

trumi
2011. 12. 12. @ 04:18

Hozzátenném hogy az én 1g. touch-omon ha elfoglalt a gép egy betöltéssel, simán nem reagál a bökésre, csúsztatásos érintésre.. Ez meg annak mond ellent, hogy "Valaki tapogat, valaki tapogat! Ha csinálsz valamit, azonnal állj le!", amin egyébként hatalmasat röhögtem, köszi az esti nevetést beszmac!

trumi
2011. 12. 12. @ 04:20

Én nem vagyok ugyan programozó, de azt nem értem, hogy pl. amikor belefejlesztik a hardveres gyorsítást egy Flash-be, akkor miért számít nekik hogy inteles vagy nem inteles, egyáltalán hogy milyen a GPU. Nemtökmindegy??? Nem úgy kéne mûködnie, hogy a Flash kiadja az ukázt az oprendszernek, hogy ezt az objektumot told arrébb, majd az oprendszer megcsinálja. Hogy a rendelkezésre álló GPU segítségével vagy sem, az magánügye, majd õ azt lekezeli. Nem így kéne mûködnie? Tudom offtopik.

mhejjas
2011. 12. 12. @ 05:58

Szerintem olyan szavakat, hogy "task" meg "thread" olyanok használjanak, akik tudják, hogy mit jelentenek.
Csak a tisztánlátás kedvéért: abból, hogy a felhasználó számára milyen szintû multitasking funcionalitás jelenik, vagy nem jelenik meg egy rendszerben, gyakorlatilag semmilyen következtetést nem lehet levonni arra nézve, hogy az adott rendszer valójában egyszerre hány task-ot/szálat kezel, vagy képes kezelni.

Trumi:
Gondolom a processzorba épített grafikus magot másképp kell/lehet kezelni, mint a külsõ GPU-t.

_woar_
2011. 12. 12. @ 14:24

Még egy dolgot hozzáfûznék a gyorsaság érzéséhez. Az iOS amint elindítasz egy programot, azonnal rajzol. Ha normálisan mûködnek a rendszerek (iOS-Android), mind a két esetben kb azonos idõ alatt áll fel, használatra készen a program. Azonban, iOS-en már "percek" óta nézheted az alkalmazás csicsáit (hozzányúlni ugyan úgy nem tudsz), mire a droid egyáltalán megnyikkan.

bubor
2011. 12. 12. @ 14:45

@trumi
mas opengl-t tamogatnak, amit en lattam azokban opengl es volt.

Marius
2011. 12. 12. @ 16:04
Marius képe

Nem erzem furgebbnek az iOS-t az Androidnal.

iFac3
2011. 12. 13. @ 02:41
iFac3 képe

Hát.... nem tudom... én ennyire nem értek hozzá... azt viszont észrevettem, hogy iOS 5 óta "laggy" lett a 4-esem. Valaki tapasztalt hasonlót?

trumi
2011. 12. 13. @ 03:55

@mhejjas, @bubor: Értem (egyébként a régi G4-es Mac Minim is tud OpenGl-t, akkor meg... értitek), de ha egyszer nem a program kezeli, hanem az oprendszer, akkor ugyanott vagyunk és nem értem: miért nem mondja meg a Flash, a Firefox (annak is speciális processzorigényei vannak a hardveres támogatáshoz) az oprendszernek hogy "csináld ahogy akarod, csak hardveres legyen". Ha egyszer az oprendszer képes tökéletesen mûködtetni hardveresen egy Exposét, akkor miért látható bármiféle GPU-különbség az oprendszerre épül (azon futó és azt utasítgató) programok számára? Pont ez az oprendszer lényege, hogy egyfajta library-ként funkcionál, hogy ne az applikációnak magának kelljen specifikusnak lennie - mégis specifikus, és képtelen egy G4-re lefordított Flash dílolni az oprendszerrel hardveresgyorsítás-ügyben. Értitek? :)

bubor
2011. 12. 13. @ 13:55

@trumi
igen tud, csak korabbi valtozatat, opengl 4.2nel tart a vilag, ezen kivul az embeded eszkozoknel opengl es 2.0nal. Flash olyan utasitast hasznal ami 3as glben van, vgad csak opengl 2.0, akkor library kenytelen cpuval szamoltatni. Az meg nem optimalis, hogy csak regi opengl utasitasokat hasznal, valamiert kihoztak ujabb meg ujabb verziokat. Otimalizalni persze csak specifikusan lehet, hasznalod az oprendszer/cpu/gpu adta lehetosegeket, aztan kiirod, hogy nem megy ppcn, mert mar asztali ppc nincsen.
Lehet kopkodni adobera, hogy miert nem optimalizal tobb oprendszerre, tobb platformra, tobb opengl verziora, de apple sem volt kepes hw-s video dekodolast megoldani azokon a vga kartyakon, ami egyebbkent tamogatja.

iNtelligent inside
2011. 12. 14. @ 06:18
iNtelligent inside képe

"Érdekes nézete ez is tényeknek. Való igaz, hogy gyorsabbnak tûnik az iOS, mivel eleve egyszálas rendszer, a multitaskot csak késõbb barkácsolták bele, de mint a fenti cikk mutatja, az is csak látszólagos"

Ha hallgattál volna...

Darida Ádám
2011. 12. 14. @ 19:22

Igen, szarul lett megírva a szoftver, ennyi. Várhattak volna kicsivel többet és megírhatták volna rendesen.
Egyébként EZ és, hogy elég rondán tud kinézni a felhasználói felület, az a két ok ami miatt nem vennék Androidos telefont. Nekem iszonyatosan zavaró az a gagyi akadozás az összes android telón... már a felületet viszont egész jóra megcsinálták.
Majd, ha 2x4 magos procikkal szerelik az androidos telókat és 2 gigás vgaval, akkor talán majd nem fog döcögni:D

iFac3
2011. 12. 14. @ 19:34
iFac3 képe

Mondjuk volt a kezemben galaxy S 2... annak nem akadozott a menüje...

pontscho
2011. 12. 15. @ 21:58

ontscho: OpenGL-rõl szó sincs most. Egyébként meg az OpenGL context-et más threaden is használhatod, csak bind-elni kell.

Dehogynincs szo. Az egesz ui render azon keresztul megy. Ez utobbirol mutathatnal valamit, mert ami megoldast eddig lattam erre, az mind oda lyukadt ki, h a main thread-re hivatkozott vissza. :)

MegaX
2011. 12. 19. @ 02:16

Nekem egy Samsung Galaxy S2-m van. De volt régebben egy iPod Touch om is. Mindkettõ rendszer használtam már. Nekem a galaxy hardveres felszereltsége is jobban bejön (samoled, 4.5" os kijelzõ stb) De a vita nem is errõl szól ez csak a személyes véleményem. A vitával kapcsolatban: Az android tényleg kicsit lassabb ami szerintem annak is betutható, hogy linux alapokon fut és a linux futtat egy dalvik virtuális gépet a java-android környezetnek. Így csak néhány natív program van androidra míg iOS en úgy tudom mindent objectiv-C ben lehet írni és minden natívan fut. Ez szintén okozója annak, hogy a közép és alsókategóriás android telefonok akadoznak. A Google ezt az utat választotta és kész. Nyilván olcsóbb és gyorsabb volt mint megírni nulláról egy normális iOS szintû rendszert. De a mai csúcskategóriás telefonok már elég erõsek ehhez. Most jön ki a Galaxy Nexus az még az S2 nél is erõsebb... Az android véleményem szerint ezekben a pillanatokban elõzi le az iOS-t mert ezekkel a készülékekkel már NEM akadozik és a nyiltság és testreszabhatóság bizony nagyon jó dolog. Nekem a touchomnál elegem volt abból, hogy várni kell a JB re meg Cydia meg ha felrakok intelisceent meg mindenféle extrát akkor belassul mint a fene és hipp-hopp lemerül. Az android aksiidejét lehet persze szídni szintén az iPhone hoz képest. De úgytudom az iOS 5 ben sok sok mindent bevezettek ami az androidban már volt és hirtelen az iPhone üzemidõk is lecsökkentek. De javítsatok ki ha tévedek mert igazából 2. generáció touch om volt és az már elavultnak számít azóta nem láttam iOS-t :)

Hozzá szeretnél szólni te is? Először be kell lépned!