This isn't a technical difference; it's a cultural difference - Android graphics

[kovacm]

Pre par dana je osvanuo tekst ne temu:

"How about some Android graphics true facts?" link
(Why is Android laggy, while iOS, Windows Phone 7, QNX, and WebOS are fluid?)

- od strane Dianne Hackborn (a Software Engineer who sits very near the exact center of everything Android)

i "komentar" na njegov post:

"Follow up to “Android graphics true facts”, or The Reason Android is Laggy" link


izneseno je dosta stvari. meni je licno omiljen deo (sa drugog linka):

"This is not a technical difference; it's a cultural difference. Good iOS developers don't ship software until it runs at something near 60 fps while scrolling and tracks touches almost perfectly; good Android developers do. "



----

kad procitate mozemo diskutovati na temu, a ja vec imam jedno pitanje:

Dianne kaze da se u verziji 3.0 koristi trik za ubrzavanje grafike: "is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU" - sta su mu "overlays"? zar se ne podrazumeva da sve elementa UI crtate u "teksture" (video memoriju)? npr. postoje tri teksture:

- na jednoj se nalazi pozadina
- na sledecoj se nalaze ikone programa (šira od fizičkog ekrana)
- i na trecoj je npr. notification koji moze da se povuce sa vrha ekrana

kad korisnik krene da skroluje ikone levo desno u sustini skroluje samo teksturu na kojoj se vec nalaze ikone. ovo obavlja GPU bez problema.

u tom trenutku mozete i da potamnite pozadinu sto opet radi GPU bez penala u brzini. kad povucete dole notification ekran opet se skroluje pomocu GPU.

e sad da se vratim na moje pitanje: u cemu je prednost koriscenja "overlaysa" u odnosu na kopiranje u frame buffer? zar postoji posebna memorija koja se koristi za frame buffer (zar kod GPU nije sva memorija "jednaka" - svejedno je da li je odvojena za framebuffer ili za teksturu)?

 

[KurtK]

Koliko sam ja citao Android nema uopste akceleraciju UI grafike (ili gresim?) tako da ne vidim drugi razlog za lag i seckanje jer GPU nista i ne radi.

A pitanje ce pre biti, zbog cega je to tako?

 

[telep]

Koliko sam ja citao Android nema uopste akceleraciju UI grafike (ili gresim?) tako da ne vidim drugi razlog za lag i seckanje jer GPU nista i ne radi.

A pitanje ce pre biti, zbog cega je to tako?

Nisi dobro čitao.

 

[KurtK]

Nisi dobro čitao.

Ok sad videh da sam smakao s uma 4.0 mada njega nema nesto mnogo. Evo npr ovde pise da je uveden u 4.0 sto je pohvalno:

GPU Acceleration: Most Apps Will Run Faster on Ice Cream Sandwich

A ima isto i diskusija kao ova na code.google:
Issue 6914: Make android use the GPU (if available) for UI and browsing.

 

[priest77]

Na onom drugom linku u prvom postu je objasnjeno:
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS

Android UI will never be completely smooth because of the design constraints I discussed at the beginning:

- UI rendering occurs on the main thread of an app
- UI rendering has normal priority

Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone. So why did the Android team design the rendering framework like this?

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.

This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and started from scratch. Android is the only mobile OS left that existed pre-iPhone.

 

[kUdtiHaEX]

Sto ne znaci da se to nece promeniti. Cinjenica je da se Android jako brzo menja i napreduje.

 

[vasic]

Sto ne znaci da se to nece promeniti. Cinjenica je da se Android jako brzo menja i napreduje.

Problem je što su potrebne fundamentalne promene koje zahtevaju kompletnu preradu svih aplikacija (bar tako kaže članak). Izvesno je da će tim Android nastaviti da radi na tim promenama, ali će one vrlo verovatno biti ekvivalentne Eplovom prelasku sa PPC na Intel arhitekturu (koji je zahtevao vrlo kompleksnu konverziju postojećih aplikacija), što će vrlo verovatno odvratiti neke od programera od daljnjeg razvoja aplikacija za Android (bar za neko vreme).

 

[yooyo]

A vi ste svi programeri pa se razumete u UI rendering i threadove? Ios nista drugo ne radi dok scrolluje i zbog toga je sve smooth. Otvorite neku kompleksnu web stranu i brzo scrolujte na dole. Sta vidite? Checkerboard @ 60fps. Fantasticno, zar ne.

 

[nnnn]

A vi ste svi programeri pa se razumete u UI rendering i threadove? Ios nista drugo ne radi dok scrolluje i zbog toga je sve smooth. Otvorite neku kompleksnu web stranu i brzo scrolujte na dole. Sta vidite? Checkerboard @ 60fps. Fantasticno, zar ne.

Da upravo to je razlika izmedju iOS i Androida po pitanju UI renderinga.

Na primer safari, otvorite web stranicu, i dok se ucitava, krenite da scroll, da jeste radice smooth, ali to je zato sto cim stavite prst na ekran, iOS ce da pauzira ucitavanje stranice sve dok ga ne pustite.
Dok ce Android da nastavi da ucitiva stranicu.

 

[Adam K]

Inače ne učestvujem u iOS vs Android raspravama i koliko god cenio kovacma ova tema mi je suviše nekako u fazonu "e sad ćemo i sa programerske strane da dokažemo da Android ne valja."

Što se Android tiče mnogo zavisi od toga koju konkretno spravu ste imali priliku da isprobate. Trenutno imam 2 tableta, aPad FR-809 (Igoritzin uvoz) koji ima Cortex A8, rezistivni ekran, 512MB RAMa, Froyo i neku AMD grafiku, skoro sam kupio Samsung Galaxy Player koji ima isti hardver kao Galaxy S, i ono je nebo i zemlja.

 

[KurtK]

A vi ste svi programeri pa se razumete u UI rendering i threadove? Ios nista drugo ne radi dok scrolluje i zbog toga je sve smooth. Otvorite neku kompleksnu web stranu i brzo scrolujte na dole. Sta vidite? Checkerboard @ 60fps. Fantasticno, zar ne.

Tacno si rekao, kompleksna strana brzi skrol na dole itd, moguce je dobiti checkerboard, doduse ne bas lako ali moguce. No opet stoji da je 60fps uvek prisutan, a brzi skrol kompleksne strane ti treba hmm priznaces retko kad.

Samo sto ova prica stoji za ceo android/iOS GUI, a ne samo u browseru.

 

[milika]

Hm, ovde se vec zaista moram umesati, radim iOS i android. Imam i public aplikacije/igrice i bez ikakve rasprave o tome sta je bolje losije, to svako nek odluci, no...

Sama struktura iOS je daleko tvrdje smisljena od Androida, ne zato sto su Appleovci mlogo pametniji, nego zbog daleko manje fragmentacije uredjaja, te tim i mnogo bolje kontrole citavog OS-a.
UI nema real time priority na iOS, ni blizu, Input ima, e sad kako ga koji program prihvati, ako lose sklepash GUI nema tog OS-a koji ce izbaciti kocenje, mora se biti vest.

Android ima kompletan deo za odrzavanje OS-a na vecem prioritetu od trenutne scene (aplikacije), a sto je po meni najgore, garbage collector (koji kao ne postoji, a ubija koliko se primeti) izgleda ima najveci prioritet.
Medjutim ovo pravi ekosistem daleko vece fleksibilnosti i, realno, vecih potencijala, ako znash da iskoristih i nadjesh nekog da to shvati.

To su dve strane trenutnog trzista mobilne tehnologije, zadrti fundametalci sa maksimalnom kontrolom, ali time i boljim kvalitetom u tome sto zele da rade, i slobodnjaci koji pokusavaju da udovolje svima, ali uspevaju samo do odredjene mere.

Svako bira sta zeli, ali budite relani, pogotovo programeri molim vas, jos uvek sam u iluziji da nas neko shvata poluozbiljno kada nesto iznesemo javno...

 

[kovacm]

A vi ste svi programeri pa se razumete u UI rendering i threadove? Ios nista drugo ne radi dok scrolluje i zbog toga je sve smooth. Otvorite neku kompleksnu web stranu i brzo scrolujte na dole. Sta vidite? Checkerboard @ 60fps. Fantasticno, zar ne.

isto kao i na Androidu 3.0

nisam probao, ali kazu da je Google (po Xti put) prihvatio Apple nacin (koji ima tile rendering od starta)

@nnnn iOS ne zaustavi ucitavanje stranice kad stavis prst vec zaustavi osvezavanje grafike. background taskovi nevezani za grafiku nastavljaju da se izvrsavaju (kao na Atariju kad povuces pulldown meni - zamrzne se grafika ali procesi nastave da se izvrsavaju )

@Adam K - naprotiv. mislim da je tema super za tehnicku raspravu.

nazalost 90% komentara (na oba originalna bloga/posta) su u sustini isti kao i komentari* ovde na benchu: "e sad ćemo i sa programerske strane da dokažemo da Android ne valja." ali bez ikakve tehnicke osnove.


*osim gornjeg posta, milike; nadao sam se da ce yooyo odgovoriti na moje pitanje: da li Android ne radi po principu koji sam opisao u prvom postu - da izrenderuje kompletnu grafiku u teksturu a da GPU odradi samo kompoziciju svih tekstura (sa efektima alpha blendinga ili sta je vec potrebno...) ali izgleda da je previse zatrovan hejtom prema Apple-u. :/ * sorry yooyo sto sam te doveo u ovo stanje - stvarno.

 

[yooyo]

Tile rendering je tu zbog toga sto hardware tako radi, a ne zbog toga sto je neko smislio da je to bolje. I jedan i drugi nacin imaju svoje predonosti i mane, tako da ne vidim poentu ove diskusije. Nekom je bitan smooth scrool, a neko ugasi sve animirane tranzicije jer mu je smor da gleda jedne te iste animacije.
Razlika izmedju threadovanog UI i klasicno, je u sinhronizaciji. UI thread treba da prilikom renderinga zakljuca podatke koje planira da iscrta i na taj nacin blokira worker thread ako ovaj pozeli da menja podatke.. Kod Android modela (koji je inace primenjen i u desktop svetu) UI rendering se desava u istom threadu kao i ostatak posla. Nije zgodno za animirane stvari. Srecom, programer moze uvek da sredi app tako da se UI odvija u zasebnom (main) threadu, dok se ostatak app vrti u worker threadu.

@kovac:
Otkud ti ideja da si me ti zatrovao "apple hejtom"? Meni je zao sto ti ne vidis koliko je to u stvari losa kompanija .

 

[RazbojNick]

^^Vrlo konstruktivno.

Ko se detaljnije razume u materiju (ja ne), neka napiše objektivno o čemu je reč. Ja sam pročitao oba linkovana teksta i ako su tačni, Android <4.0 nema GPU hardversku akceleraciju grafičkog prikaza pri svim operacijama. Tj. bar je nema uključenu po def.

Edit: ulete Yooyo.

https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC

 

[webster]

Otvorite neku kompleksnu web stranu i brzo scrolujte na dole. Sta vidite? Checkerboard @ 60fps. Fantasticno, zar ne.

Covek bi ocekivao vise od tebe s obzirom da se trudis da ostavis utisak nekog ko je upucen u Apple uredjaje. Od iOS-a 5 NE POSTOJI CHECKERBOARD

 

[yooyo]

Nemam ios 5 ni na jednom uredjaju, tako da nisam znao za checkerboard.
Smesna je cela ova tema. Ne mogu da verujem da je nekome toliko bitan smooth scroll.

 

[milika]

Pa bitan je user experience, a smooth scroll je aspekat toga koji daje iluziju brzine. Da je brze nije, ali zaista daje iluziju da sve brze i bolje radi.
Ne samo smooth scrool, nego i 'brzi' progress barovi, animacijice svega i svacega, ikonica menija itd...

Realno to sve usporava potreban rad za prikaz sadrzine, ali povecava user experience level.

E sad koji pristup kome odgovara, to covek bira kao platformu/browser/firmu, a vidim ovde i kao religiju

 

[ivan90BG]

Pa do kojeg se zaključka ovde dolazi?

Ja sam stekao utisak da je stvar u tome što programeri aplikacija za iOS bilo koju iole zahtevnu operaciju stave u drugu nit, a sam iOS je tako programiran da glavna nit (u kojoj se renderuje GUI) ima ogroman prioritet, pa zato stvari staju kad krene animacija u GUI-u. Tako da je ta fluidnost iOS-a posledica delom samog iOS-a, a delom načina programiranja (čak mislim da Apple propušta na App Store samo aplikacije koje poštuju ovaj proncip, a i ja sam davno pročitao u Apple dokumentaciji (za Mac OS X) da se grafika renderuje na glavnoj niti i da se preporučuje da se za bilo kakvu operaciju koja će iole da traje koristi druga nit, verovatno da je Apple za iOS ovu preporuku pretvorio u zahtev koji se mora ispoštovati da bi se aplikacija našla na App Store-u).

Jel ovo suština?

 

[yooyo]

Retko koja app pokrece worker threadove da bi obavili neki posao. Npr. u listama mozete staviti kompleksne informacije (slika sa nekim tekstom). Ios trosi memoriju samo za vidljive elemente na ekranu. Kada novi element postaje vidljiv, poziva callback u app da mu popuni novi item. Ukoliko je callback funkcija spora (npr dovlaci sliku sa neta) onda scroll moze da zapne. U tom slucaju obicno se stavi default slicica pa kad stigne sa neta onda se zameni.
Ios UI ne cuva podatke koje prikazuje vec stalno poziva app da mu ih isporuci kada mu zatreba. Ovo je sasvim dobar princip jer programer ne mora da brine o odrzavanju redundace izmedju stanja u UI i stanja u app. Zbog toga ui deo app ne moze biti poseban thread. Igre najcesce pokrenu render loop u worker threadu jer na taj nacin izvuku koji frejm vise.

 

[milika]

Ima tu malo vise komplikacije, i android ima virtualne liste, a nisu sve kontrole u iOS virtuelne. (Virtuelne kontrole su tip kontrola koje ne drze u predefinisanoj memoriji ceo sadrzaj, vec samo ono sto se trenutno prikazuje. To moze biti automatski, a moze biti i da programer mora da 'filuje' podatcima)
Worker threadove mozes i ne morash koristiti ni kod iOS-a ni kod Androida.

Sve se opet nekako svodi na licne preference programera i/ili korisnika...

Ja imam pravilo 3s, ako nesto ne zavrsi za 3s, ja spucavam worker thread, pa makar to bilo brisanje privremenih podataka, naravno kad je to moguce...

Meni se cini nekako da se previse ide u detalje, meni je to posao pa moram znati daleko vishe od korisnika, ali ako je korisniku lepo koristiti OS, iz bilo kog razloga, samo napred.
Predociti sta ti se svidja a sta ne, je ok, ali ubedjivati ljude sta je bolje, mislim da je iluzorno i pokusavati.

Moja licna preferenca je iOS, najvishe zbog koncentracije kvalitetnih developera na platformi, eto da se i ja izjasnim...

Ako neko ima konkretno pitanje da na to mozda odgovorimo, a ovo prepucavanje tehnickim detaljima ne vodi nigde.
I sam browser je samo program koji je neko napravio, dobro ili lose i ne odredjuje celu platformu, iako je mozda program koji se najvishe koristi (mozda bi na iOS-u onda angry birds i tiny wings trebalo gledat, daleko se vishe koriste od safarija )

 

[salac]

Procitao sam postove sa pocetnog linka, i izgleda da je stvar u sledecem:

Android mnogo vise podseca na klasican OS nego iOS - iOS pri iscrtavanju sadrzaja ekrana koristi single GL kontekst, kod androida vise aplikacija istovremeno moze da 'formira' trenutni izgled UI-ja. Dakle, android skoro pa ima klasicne windowse kao bilo koji desktop OS. Problem - hardver aka 3d cipovi koji su se do skora ugradjivali u telefone/tablete/whatever nisu ni imali mogucnost za rad sa vise GL konteksta, sto je odavno trivijalna stvar na GPU-ovima koji se ugradjuju u stone racunare. Posledica - kod androida je rendering GUI-ja bio samo delimicno sa hardverskom akceleracijom (samo jedan prozor), kod iOS-a je kompletan GUI imao hardversku akceleraciju (jer i postoji samo taj jedan prozor). Posledica 2 - android se sa druge strane ponasa kao pravi multitasking OS (dakle aplikacije u backgroundu mogu da crtaju po ekranu, pa zato odvajkada postoje i widgeti i notifikacije i sl.) dok iOS to nije mogao; android ima i mogucnost da se sadrzaj jednog windowsa koriscenjem API-ja prebaci u drugi, dok je to kod iOS-a nemoguce (ili bar nemoguce direktno).

Ovo verovatno povlaci za sobom jos neke interesantne stvari a koje mnogo bolje znaju pravi ios i android programeri. Evo recimo da se pise aplikacija za android koja koristi tastaturu - programer u stvari poziva aplikaciju za tastaturu sa samog androida (tj. otvara nov prozor), dok to kod iOS-a nije tako vec pretpostavljam da je tastatura u okviru standardnog GUI API-ja. Androidov metod je nesto sporiji ali je i nesto fleksibilniji - zato je na androidu moguce instalirati neku tastaturu i koristiti je u bilo kom programu. Ali, sa druge strane, stvara se problem vise prozora i njihove hardverske akceleracije. Ono sto se moze nazreti je da ce ovaj problem biti prevazidjen sa novijim GPU-ovima i drajverima koji su sastavni deo HC-a i ICS-a. Tako bar tvrde pisci androida.

Android, sudeci po onome sto sam procitao, i definitivno ima tu i tamo po neki overhead koji kod iOS-a prakticno ne postoje, a ticu se umnogome i dizajnerskih odluka.

Recimo - android koristi cfgroups sa linuxa -> background aplikacije jedu do 10% CPU-a, sto kod iOS-a verovatno nije slucaj obzirom da se aplikacije suspenduju i ne nastavljaju da rade u backgroundu.

Druga stvar - android ima vrlo striktnu politiku izolacije proces i njihovog pracenja i oznacavanja, sto podseca na 'tvrdo' stelovane linux sisteme sa selinux-om ili apparmour-om. Ovo definitivno unosi overhead, a to se pravda time da android, za razliku od iOS-a, mora striktnije da vodi racuna o pravima jer se softver instalira ne samo sa jednog centralnog mesta, vec bilo kako.

Btw, interesantno je da je Endru, covek ciji je post kovacm preneo ovde kod nas na benchmark, posle diskusije sa nekim od glavnih android programera, svoj post izeditovao, stavio prvo kontraargumente i linkove koji pobijaju njegove prvobitne stavove, a uz to je dodao i ovo:

BEFORE READING: A LOT OF MY ANALYSIS OF ANDROID PERFORMANCE IS WRONG, HOWEVER I AM LEAVING THIS POST UP BECAUSE OF MY COMMENTARY ON THE ISSUE.

Bravo za Endrua, mogli bi po nesto da naucimo od njega.

 

[kovacm]

Tile rendering je tu zbog toga sto hardware tako radi, a ne zbog toga sto je neko smislio da je to bolje. I jedan i drugi nacin imaju svoje predonosti i mane, tako da ne vidim poentu ove diskusije. Nekom je bitan smooth scrool, a neko ugasi sve animirane tranzicije jer mu je smor da gleda jedne te iste animacije.
Razlika izmedju threadovanog UI i klasicno, je u sinhronizaciji. UI thread treba da prilikom renderinga zakljuca podatke koje planira da iscrta i na taj nacin blokira worker thread ako ovaj pozeli da menja podatke.. Kod Android modela (koji je inace primenjen i u desktop svetu) UI rendering se desava u istom threadu kao i ostatak posla. Nije zgodno za animirane stvari. Srecom, programer moze uvek da sredi app tako da se UI odvija u zasebnom (main) threadu, dok se ostatak app vrti u worker threadu.

@kovac:
Otkud ti ideja da si me ti zatrovao "apple hejtom"? Meni je zao sto ti ne vidis koliko je to u stvari losa kompanija .

krajnje lepo i jasno objasnjeno: "UI thread treba da prilikom renderinga zakljuca podatke koje planira da iscrta i na taj nacin blokira worker thread ako ovaj pozeli da menja podatke.. Kod Android modela (koji je inace primenjen i u desktop svetu) UI rendering se desava u istom threadu kao i ostatak posla"

hvala! :wave:

sto se tice poslednjeg reda - citao sam neke stare teme na forumu, od pre 4-5 godina, i tada si imao prilicno drugacije misljenje i kao da si u jednom trenutku poceo da mi udaras kontru iz posta u post :|

sto se mene tice: Apple je sve samo ne losa kompanija. poslednjih 10 godina je donela toliko novina koje ostale kompanije pokusavaju da iskopiraju (sto je ok u jednu ruku). Glavni problem je sto nemaju pravog konkurenta, konkurenta koji nece kopirati ono sto oni rade, vec koji ce moci da: pomeri granice. to je najveci problem i mana Apple-a - sto nije ostavio mesta za konkurenciju (za sta su i sami krivi: oslonili su se na Microsoft).

 

[kovacm]

https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC

Ovaj drugi post Dianne H. upravo govori o onome sto sam pitao u prvom postu!

"An important part of achieving this security is having a way for individual UI elements to share the screen in a secure way. This is why there are windows on Android..."

"...in Android 1.0 having each view drawn into a texture and those textures composited to the window in another thread is just not that much of a gain, with a lot of cost."​

dakle Android radi isto sto i iOS ali i dalje mi nije jasno sta se podrazumeva pod:

"...to have the drawing inside each window be hardware accelerated"​

ona prica o GPU akceleraciji prilikom crtanja delova korisnickog interfejsa unutar jednog prozora: uzmimo npr. List View - kako GPU moze da pomogne prilikom kreiranja jednog ListView-a u kojem imate npr spisak pesama + sliku pored svake pesme + dugme play?


-- da li je ovo o cemu Dianne govori isto sto i Quartz 2D Extreme u Mac OS X-u?? (koji postoji od verzije 10.4 (!) ali se do danas ne koristi - kad se ukljuci, neke aplikacije pocnu da brljaju po ekranu... hocu da kazem da Apple-u ne polazi za rukom da napravi GPU akceleraciju za crtanje elemenata UI vec nekih 4-5 godina...)


EDIT:

btw Dianne Hackborn je radila u Be Inc. na: "OpenBinder is the core technology that ex-Be engineers started at Be, Inc. as the "next generation BeOS", finished implementing at PalmSource as one of the key foundations of the Cobalt system, and is now being open-sourced running for Linux." link

sto je na kraju zavrsilo u Androidu

 

[kovacm]

Smesna je cela ova tema. Ne mogu da verujem da je nekome toliko bitan smooth scroll.

upravo sam procitao kraj Dianne-nog posta:

"I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS."​

dakle posle xyz pisanja i citanja strucnih tekstova o Androidu zakljucak je da:

Android i iOS sve rade isto (sto se tice OS-a) ali Android i dalje nema smooth scroll.​

a zasto je to tako?


odgovor je u naslovu temu ("This isn't a technical difference; it's a cultural difference") sto yooyo samo potvrdjuje u quote-u gore.


* ocigledno je da Android nema nikakvih prepreka da ima smooth scroll ali isto tako to ocigledno nije vazno programerima *


----


ja bih rekao da je to zato sto su Mac/iPhone proizvodi, pre svega, ispoliran od strane Apple - ocekivanja korisnika su u startu "podesena" na nivo koji je Apple kreirao sa svojim proizvodom, i prosto je "sramota" da napravite nesto ispod tog nivoa (pocev od software-a, preko hardwerskih periferija pa sve do piratskih crackova - cak i pirati na Mac OS X-u postuju ovo i crackove daju u user-friendly preglednoj i azurnoj KCNSCrew bazi!).


da, definitivno je Brent Royal-Gordon bio u pravu: "it's a cultural difference"

 

[yooyo]

@kovac:
ah.. pa nisi mi jasan.. dizes u nebo Apple kako je savrsen a sa druge strane jedini developer tool na osx-u koji treba da postuje pravila "idealne organizacije" prozora je potpuna failovao. Kako to da "bezgresni" Apple izbaci tako "gresan" tool?

 

[salac]

* ocigledno je da Android nema nikakvih prepreka da ima smooth scroll ali isto tako to ocigledno nije vazno programerima *

Prvo, android i iOS ne rade sve isto, i preporucujem ti da ponovo procitas post na koji se pozivas.

Android je drugacije organizovan od iOS-a, i to u svom postu pominje i gorepomenuta Dajana. Dok kod iOS-a staje ama bas sve kada se crta GUI (ukljucujuci tu i liste koje si pomenuo), kod androida to nije tako vec multitasking nastavlja da radi svoj posao slicno kao kod desktop operativnih sistema. Penalizacija je, u najgorem slucaju, 10%. Isto kao sto postoje i penali zbog striktnog proveravanja privilegija.

Ali da se vratimo na UI - svaki UI svakog OS-a moze da radi glatko koliko ti je volja ukoliko sav hardver upregnes da servisira pre svega drugog - UI. To je ono sto radi iOS. Android radi nesto drugacije - pokusava se da UI radi sto je moguce brze ali ne po svaku cenu, svoj deo dobijaju i background aplikacije.

Oba resenja su validna i imaju svoje prednosti i nedostatke. Kod androida definitivno UI nije jedino o cemu se vodi racuna pri interakciji korisnika sa sistemom, kod iOS-a je UI uvek na prvom mestu. Sto je vrlo interesantna i neobicna stvar - evo dolazi tegra 3, sa 4+1 CPU-om... da li je zaista iOS resenje, koje znaci 'zakucavanje' svih 5 jezgara dok se input ne iservisira - jedino ispravno?

Meni, pravo da ti kazem, nije. Neka UI i zastuca tu i tamo ako imam mogucnost da mi se programi slobodno vrte u pozadini i ne bivaju suspendovani/terminisani kao kod iOS-a.

Elem, u pitanju je klasican tradeoff - ili ce sistem da ima besprekoran UI, ili ce da ima ljudski multitasking. Na ruku androida ide i vreme i nove mogucnosti koje hardver dobija - obzirom da mobilni hardver postaje sve jaci i jaci, uskoro nece biti nikakvog stucanja UI-ja a multitasking ce ostati netaknut. A iOS? Pa verujem da ce kroz par iteracija i on da se po multitaskingu priblizu androidu, sto se vec i desava - vrlo je ocito da dve platforme, po mogucnostima, asimptotski teze jedna drugoj.

ja bih rekao da je to zato sto su Mac/iPhone proizvodi, pre svega, ispoliran od strane Apple - ocekivanja korisnika su u startu "podesena" na nivo koji je Apple kreirao sa svojim proizvodom, i prosto je "sramota" da napravite nesto ispod tog nivoa (pocev od software-a, preko hardwerskih periferija pa sve do piratskih crackova - cak i pirati na Mac OS X-u postuju ovo i crackove daju u user-friendly preglednoj i azurnoj KCNSCrew bazi!).

Ajde de.... hoces da kazes da korisnicima ne smeta to sto im se aplikacije same od sebe gase u pozadini, sto nikad nisu sigurni hoce li ih docekati aktivna ili suspendovana aplikacija koju su bacili u background, sto ne mogu da startuju nekoliko aplikacija paralelno po svojoj volji? Meni je to uzasno smetalo dok sam koristio iPad - svaki program koji je imao dodira sa internetom, bacen u pozadinu, je posle nekog vremena terminisao sesije sam od sebe.

da, definitivno je Brent Royal-Gordon bio u pravu: "it's a cultural difference"

Jedini 'cultural difference' koji ja vidim je nacin organizacije iOS-a i androida. Jedni forsiraju smooth UI i bas ih briga ako zelis da ti paralelno rade 2-3-4 aplikacije, dok drugi smatraju da UI nije bas toliko bitan da njemu treba da se podredi ceo sistem, pa cak i po cenu ozbiljnog sakacenja.

Jos jednom cu da ti ponovim - 'apple way is not the only way'. Niti je bezgresan. Sve ima svoje prednosti i mane.

 

[cjokanov]

Meni deluje kao da bi pravo resenje (onako laicki) bilo da se jedno jezgro posveti UI-u, pa i 100% ako treba, a da se ostala posvete ostalim threadovima. POsebno sto je pokazano da je jedno jezgro sasvim dovoljno da UI nikada ne stuca (primer je iphone 4).

U principu, sa 2 jezgra trebalo bi da se dobiju i jare i pare android nema razloga da stuca, jer ima celo jezgro (citavih 1GHz) za UI, a IP ne bi trebalo da gasi procese jer opet ima celo jedno jezgro da im posveti onoliko vremena koliko im treba.

Medjutim ima tu jos jedna kvacica, a to su u stvari 2 Memorija i baterija. Ip uglavnom terminise procese u pozadini kada mu fali memorije. Postoji system wide notification, koji svaka aplikacija mora da uvazi (Low mem warning) i terminacija se desava upravo kada sistem posalje ovu notifikaciju. U tom trenutku aplikacije u pozadini sacuvavaju "state" i gase se.

Shvatam da ovo nekim korisnicima moze biti mana, ali isto tako je mnogima i prednost, jer u isto vreme ogranicava aplikacije u pozadini i smanjuje mogucnost da vam nesto u pozadini konstanto jede bateriju. naime ja sam na androidu stalno morao da se bakcem sa killer applikacijama kako mi odredjene aplikacije ne bi cedile bateriju u pozadini. Kod IP-a nema nikakve brige o tome.

Ja vidim da oba sistema imaju mesta za napredak, i to u komplementarnim pravcima.

Poz

 

[kovacm]

@salac

Android je drugacije organizovan od iOS-a...

kod iOS ne staje sve kad radi scroll, samo ne prihvata nove evente vezane za input dok se tekuci ne zavrsi.

na Androidu "10% za background taskove" nema veze sa iscrtavanjem GUIa - 10% manje performanse nisu problem prilikom seckanja UI-a.

sad se setih source za "Wet: Sexy Empire" koji sam pisao 2000. i slican problem za to kad ko moze da crta po screen-u:

ON cursor.message% GOSUB cursor.if_move, cursor.nodraw, cursor.if_location, cursor.update
timera%=200
timera.message|=2 ...​

svoj deo dobijaju i background aplikacije.

10% ...

koje znaci 'zakucavanje' svih 5 jezgara dok se input ne iservisira

ne znaci.

UI samo ne startuje nove input evente dok se tekuci ne zavrsi. ostali background taskovi nastavljaju da rade. (kao sto rekoh)

Elem, u pitanju je klasican tradeoff - ili ce sistem da ima besprekoran UI, ili ce da ima ljudski multitasking

kakav trade off?

u cemu je manjak iOS multitaskinga u realnom radu?

iOS multitasking je superiorniji u odnosu na Android. u nekoj od sledecih verzija ce i Google prihvatiti Apple koncept, kao sto je prihvatio i tile scrolling u 3.0...

... asimptotski teze jedna drugoj.

definitivno! uzimaju ono sto je druga osmislila bolje.

ali i dalje ostaje "Microsoft" sindrom kod Android programera: "zasto scroll mora da bude smooth"?

(ili zasto je bitno da li je neki dijalog modalan )

hoce li ih docekati aktivna ili suspendovana aplikacija koju su bacili u background

zasto je to bitno? ako aplikacija moze da prima evente dok je u pozadini, zasto je bitno da li je aktivna ili u backgroundu ili ugasena?
ako aplikacija prekine ono sto treba da radi (?) onda najverovatnije nije napisana onako kako je Apple zmaislio (- milika?)



btw ^ ^^ ^^^ "drago" mi je sto ovde ima toliko ljudi kojima je "microsoft" alfa i omega
Google je u svakom slucaju svetlosnu godinu u odnosu na M$ useless crapware i drago mi je zbog toga - da Apple ima "dobru" konkurenciju (naravno da nisu najpametniji ali su za sada najtemeljniji u onome sto rade ).



bottom line, i najveci problem je: trecerazredni software, trecerazredni programeri, koji ce i dalje praviti lose aplikacije/proizvode.

Apple (S. Jobs) je u velikoj meri doprineo da se sve u vezi njega digne da tri puta visi nivo (u odnosu na postojece stvari) ali najbitnije da se ne ponovi nesto iz 90tih:

"The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he, by peddling second rate technology, led them into it in the first place, and continues to do so today."

 

[ABET]

iOS multitasking je superiorniji u odnosu na Android. u nekoj od sledecih verzija ce i Google prihvatiti Apple koncept, kao sto je prihvatio i tile scrolling u 3.0...

Jeste superiorniji je i ne, nece ga prihvatiti jer ce u suprotnom Apple da ih tuzi. Da, u pitanju je cultural difference, jedni (kompanija i njeni postovaoci) su dzukele.

PS. Nisam rekao koji su u pitanju tako da nema razloga za warn