Vlákno názorů k článku
Proč je iOS plynulejší než Android? od Neviditelný - Z diskuse pod zmíněným příspěvkem vyplývá, že to...

  • Článek je starý, nové názory již nelze přidávat.
  • 8. 12. 2011 16:51

    Neviditelný (neregistrovaný)

    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.

  • 8. 12. 2011 17:39

    Lael Ophir (neregistrovaný)

    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.

  • 8. 12. 2011 18:32

    Neviditelný (neregistrovaný)

    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

  • 8. 12. 2011 20:47

    Lael Ophir (neregistrovaný)

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

  • 8. 12. 2011 22:06

    Daniel Smetana

    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.

  • 8. 12. 2011 22:13

    Neviditelný (neregistrovaný)

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

  • 9. 12. 2011 9:18

    mat (neregistrovaný)

    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.