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