Názory k článku
Proč je iOS plynulejší než Android?

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 :)

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

Jinak, ukaz nejakou javovou ktera bezi (z ruznych platforem na prumernem HW). Ja zadnou takovou nikdy nevidel.

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%).

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).