Proč je iOS plynulejší než Android?

"...vysvětlení nad faktem..."

Tato konstrukce patrne znamena, ze je nekde nejaky fakt a nad nim levituje vysvetleni.

protoze, kdyz ma aplikace na krku jvm, tak logicky nemuze bezet plynule, ale to nikdo neprizna

Skuste si precitat aj ten odkazovany clanok

tak uz je mi to jasne, on je totiz velky rozdil v odezve, kdyz stisknu klavesu, nebo zasmudlam po obrazovce :)

Opravdu je, stisk klavesy je jedna udalost, vyvola jedno preruseni, vyvola to nejakou zmenu v gui, ktera se da dobre akcelerovat, protoze treba takova animace dobehne cela.
Smudlanim po obrazovce se generuje hromada udalosti, pri takovem dragovani je nutno reagovat okamzite na posun o kazdy pixel, na vsechny zmeny v pohybu, je to v principu uplne jiny rezim, navic tolik udalosti na klavesnici nemate ani sanci vygenerovat.

a mozes dat aj vysvetlenie preco by nemohla aplikacia beziaca na jvm bezat plynule?

Tezko muzu posoudit prumerny HW, ale zrovna vcera jsem zkousel SmartGit, je uplne v pohode, treba takove netbeans jsou proti MSVS2010 zihadlo plne srovnatelne s VS2005 (s lehkym prihlednutim k moznostem editoru).

Aneb uz jsem videl svizne i smejdske aplikace psane v jakemkoli jazyce, je to mnohem vic o designu a tech umelcich co to pisou nez o jazyku samotnem.

ano, denne ich pouzivam, napriklad netbeans, eclipse, sqldeveloper (ten az nato, ze je trosku prasacky napisana, ale to nema nic s rychlostou javy/JVM).

Eclipse nieje zly, ale k sviznosti C/C++ aplikacii ma daleko. Proste to vidiet na odozve, ze nieje uplne okamzita. Na sucasnych pc sa s nim da dobre pracovat, ale kazdy clovek co prejde z nativnej C/C++ aplikacie na Javovsku aplikaciu si vsimne maly rozdiel v odozve (aj na sucasnych pc).

Z diskuse pod zmíněným příspěvkem vyplývá, že to není Android, co by nutil vývojáře kreslit v hlavním vlákně, ale spíše lenost vývojářů kreslení UI vhodně oddělit. iOS (prý, jeho SDK osobně neznám) dává vývojářům lepší možnosti, jak toto realizovat a proto je tam problém méně citelný. Další záležitostí je samozřejmě GC na Androidu vs. reference counting na iOS.

Pokud jsem si všimnul, Android do verze 4 ani nepoužíval HW akceleraci GUI (s výjimkou pár aplikací, kde si to autoři napsali sami).
Windows Phone používá v naprosté většině případů retained mode. Aplikace psaná v .NETu pracuje s nějakými objekty ve stromu (přidá tlačítko do formu, nastaví mu barvu, změní popis), a o zobrazování se nijak nestará. SilverLight pak provádí zobrazování v separátním threadu, a používá u toho HW akceleraci.

Nikoliv. Android používal částečnou HW akceleraci vždycky. Verze 3.0 umožňuje plně akcelerované vykreslování, pokud to vývojář v jejím manifestu explicitně povolí, v ICS je pak toto nastavení výchozí. Dianne Hackborn v jednom příspěvku dále vysvětluje, proč není HW akcelerace až takové terno, jak by se mohlo zdát.

https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

Částečná akcelerace (tj. SW kreslení obsahu okna a pouhé vykreslení okna na obrazovce na dané pozici pomocí GPU) zjevně nestačí.
Je ten rozdíl tedy primárně v retained mode, který Windows Phone používá? V takovém případě totiž není třeba čekat na dokončení operace - řekněme přidání prvku do formu - a lze prostě kreslit to, co je už připravené (ve formě fronty GPU operací nebo hotové bitmapy), a klidně s tím po obrazovce hýbat. Stačí ve visual tree vhodně zamykat nodes, a udržovat nějaké verzování. Tohle v immediate mode těžko udělat.
BTW verze 3.0 je dnes údajně na pouhých 2.4% zařízení s Androidem. Těžko pak čekat, že vývojáři půjdou do použití akcelerace, a odstřihnou se od zbylých 97.6% zařízení (verze 4.0 má 0%).

Zváštní, pak musím být součástí těch 0%. Navíc Honeycomb je pouze pro tablety, ICS i pro telefony, takže bude mít určitě víc procent až novější mobily dostanou OTA.

Co jsem z článků a reakcí na ně pochopil, problém není v nedostatečném vykreslovacím výkonu, ale v designu aplikací. Toolkit iOS (a asi i WP7) umožňuje jednoduše přesunout část vykreslovací práce na vlákna na pozadí. UI toolkit Androidu s tím nepočítá, protože vznikl ještě před nástupem touchscreenů a potřeba aplikací reagovat okamžitě na akce uživatele se tehdy nepovažovala za tak kruciální. Pokud za použití takového toolkitu vývojář problém umocní např. přístupem do flash paměti v hlavním vlákně, není se čemu divit a neviděl bych to přímo jako vadu Androidu ale spíš diletantství programátorů.

O plnou HW akceleraci na And bych se nebál, pokud se ICS skutečně masově nasadí a nahradí jak řadu 2.3 tak 3.0 (nevidím důvod, proč by se tak nemělo stát).

neviděl bych to přímo jako vadu Androidu ale spíš diletantství programátorů.

Neřekl bych, že programátoři pro iOS nebo WP7 jsou nějak výrazně lepší. Pouze ta prostředí jim davají míň možností dělat věci neefektivně. Čili ano, je to problém Androidu.

O plnou HW akceleraci na And bych se nebál, pokud se ICS skutečně masově nasadí a nahradí jak řadu 2.3 tak 3.0 (nevidím důvod, proč by se tak nemělo stát).

Ano rozšíří, ale nákupem nových telefonů. Stávající se budou muset z větší části vyhodit. Už vidím jak moje ségra, co má Android, bude flashovat na Cyanogen, po kterém ji přestane fungovat GPS nebo kamera.

... díky rozhodnutí kohosi o čemsi kdysi dávno se už prostě daný problém řešit nebude a basta?