Android GPU/CPU Grafik roundup (warum ist Android "mehr" laggy als iOS / wp7 ?)

(ich share das hier jetzt mal für die, die das noch nicht kennen)
Die folgenden 2 Beiträge, vonDianne Hackborn und Andrew Munn

beschreiben sehr detailiert und einfach
(eig. für jeden mit guten englisch und bissl tech-interesse zu verstehen)

-wie Android das OS "rendert" , darstellt (Grafik und system)
-Wie CPU und GPU einfluss üben
- Warum Android 4 "besser" damit umgehen kann als mit V2 oder V3.
- Warum Android mehr "laggy" (bzw anfälliger dafür ist) als iOS & Wp7
- Gründe, beispiele und evtl lösungen in Zukunft

ist gut text das ganze, aber sehr interessant.
Nehmt euch das als Bettlektüre

Unbedingt zurerst den beitrag von Dianne lesen:

https://plus.google.com/105051985738...ts/2FXDCz8x93s

dann den von Andrew

https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS

Verdammt, das ist gut, und ein Schlag in 'Androids' Gesicht. Das sollte sich jeder Android-Fan mal durchlesen. Der zweite Artikel ist der interessantere.

Über Apple wird geflamt... und der Müll, den Google da mit Android bisher erschaffen hat, wird schöngeredet.... ich schmeiß mich weg...

Das Galaxy Nexus hole ich mir aber wohl trotzdem.

"geschrieben auf meinem iPad"

Sehr interessante Artikel - vielen Dank!

Als einen "Schlag ins Gesicht" für Android würde ich es aber dann doch nicht sehen. Wahrscheinlich in jedem OS müssen früher oder später Entscheidungen für den einen oder den anderen Weg getroffen werden und die erweisen sich halt auch mal als ungünstig oder gar falsch. Das ist so.

Leider werden die Artikel auch nicht dazu beitragen, dass die Fanboys beider Lager schlauer werden, denn die meisten werden es weder lesen noch verstehen

Für mich bleibt Android das im Moment bevorzugte System und die paar Millisekunden, die es manchmal laggt gönne ich mir einfach...

Zitat von Äppler

Sehr interessante Artikel - vielen Dank!

Als einen "Schlag ins Gesicht" für Android würde ich es aber dann doch nicht sehen. Wahrscheinlich in jedem OS müssen früher oder später Entscheidungen für den einen oder den anderen Weg getroffen werden und die erweisen sich halt auch mal als ungünstig oder gar falsch. Das ist so.

Leider werden die Artikel auch nicht dazu beitragen, dass die Fanboys beider Lager schlauer werden, denn die meisten werden es weder lesen noch verstehen

Für mich bleibt Android das im Moment bevorzugte System und die paar Millisekunden, die es manchmal laggt gönne ich mir einfach...

100%ige Zustimmung!

Hier ist eine kurze Zusammenfassung in deutsch (für diejenigen, die des Englischen nicht so mächtig sind):
http://t3n.de/news/android-entwickle...les-os-349141/

Also so wie es dargestellt wird, wäre ich für eine Neuprogrammierung des Frameworks. Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende. Von dem ständigen herumdoktern bzw. verbessern der alten Fehler halte ich nicht viel. Dann lieber einmalig den Ärger mit nicht mehr kompatiblen Anwendungen. Das ist zwar schmerzhaft, aber manche Fehler kuriert man besser aus, anstatt sie ständig mit sich herumzuschleppen.

ja neuprogrammierung hätte gute seiten klar. auf sehr lange sicht gesehen evtl die bessere lösung...

ich finde die 2 Beiträge echt super gemacht, sie zeigen Neutrale Fakten, räumen endlich auf in der Gerüchteküche und vor allem-> kein Fanboy palaber sondern einfach nur Pures knowhow.

Ich finde es aber auch KEIN "schlag in Androids gesicht". Im Gegenteil, es hat alles vor und Nachteile.
Und wen man bedenkt das Android eigentlich von anfang an nicht als pureTouch OS gedacht war, so bringt es Apple dennoch sehr stark zum Schwitzen
und ich finds super das Andrew auch hierrauf einging
(die vorteile einer solchen programmierung wie sie jetzt ist und die vergleiche mit iOS (die zu deren nachteilen führen) :
Siehe:

It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority.
On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.

Grab your closest iPad or iPhone and open Safari. Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around. All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is intercepting all events and rendering the UI at real-time priority.

The reality is that (this way) Android can render (bigger) web pages as fast or even faster than iOS

sehr interessant.

iOS geht also den "ich mach nur das was der Screen anzeigt" Weg.
Hat natürlich vorteile, aber auch nachteile.

- was aber erklärt warum iOS ist, wie es ist.

- warum developer versuche, beim iphone komplexe aktive "live widgets" einzufügen nicht klappten bzw zum cpu dropdown oder crash führten

- was gut erklärt warum kein 100% echtes multitasking auf dem Iphone funktioniert. (apps werden nur pausiert). weil einfach im hintergrund kaumwas gerendert / prozessiert wird.
(bis auf wenige kleine / wenig ressourcen verbrauchende ausnahmen wie musik etc)

- was auch erklären würde (evtl auch ein (aber nicht kleiner) Grund von vielen) warum auf iOS selbst mit 1ghz leistung kein "akzeptabler" flashplayer umfang möglich war !

- was auch beudeuten würde das iOS in vielen sachen (renderings etc) noch kein effektiv 100%igen dualcore support hat.
was natürlich in naher zukunft evtl nicht nötig sein wird,
aber in baldinger zukunft wenn die Webdesigns und Rendering ressourcen zunehmen werden (evtl alles MINIMUM dual oder quadcore braucht in ein paar jahren, oder lass es mal 5-10 jahre sein)
dann wird apple vor einer großen herrausvorderung stehen, da dann evtl ein "single thread rendering" nicht mehr genug ausreicht um konkurrenzfähig zu sein....
oder einfach die "neue generation" oder bestehende, MEHR wollen (sich ans Multi OS leben gewöhnen) mehr von allem, live, alles auf einmal...

Android geht den anderen weg: "Alles her damit xD"
was natürlich nachteile in sachen UI performence bringen kann (die wie ihr seht aber im millisekundenbereich sehr klein sind) , aber auch vorteile eben beim effektivem vielem Arbeiten
(oder wie in dem beispiel beim Scrollen einer Großen aufwendigen Internet-seite , wärend diese noch im hintergrund lädt)


ich will jetzt damit KEIN krieg der Pro und Contra iOS Vs Android anzetteln, sondern finde einfach die hintergrund infos, das warum und wie mit neutralen infos und fakten , interessant
Man lernt nie aus

ich pers. würde aber zZ den aktuellen vorteil von android, der dezimierung des "sporadischen millisekunden lags" vorziehen.
Wäre aber natürlich super wenn Google und Android BEIDES vereinen könnten

das sind jetzt nur ein paar freie Gedanken

Sehr intressanter Artikel bzw. Beide. Naja jedes OS hat so seine vor und Nachteile. Und jedes OS ist auf seine Art und weise toll. Ich hab alle drei und mag auch jedes.

Mit der kostenlosen PocketPC.ch App von meinem Venue Pro aus geschrieben.

Zitat von Dahizzo

- was auch beudeuten würde das iOS in vielen sachen (renderings etc) noch kein effektiv 100%igen dualcore support hat.

Da muss ich als Laie nochmal nachhaken: Ich hatte das so verstanden, dass Android versucht alles gleichzeitig zu machen, wohingegen bei iOS eine Priorisierung stattfindet. Die UI kann also falls notwendig 100% der Ressourcen für sich beanspruchen, während Android maximal einen Teil für sich beanspruchen kann.
Nehmen wir als Beispiel eine UI, welche 800 MHz für die flüssige Darstellung braucht. iOS bekommt einen 1GHz Prozessor, rendert die UI mit 800MHz Real Time und hat noch 200 MHz für den Hintergrund. UI ist flüssig etc., aber im Hintergrund passiert fast nichts. Android bekommt einen 1GHz Prozessor, UI braucht 800MHz um flüssig zu sein, rendert aber beides gleichzeitig. Der Hintergrund erhält 500 MHz und die UI erhält 500 MHz. Folge: UI nicht flüssig.
Aufrüsten auf Dual-Core mit 2x1GHz. iOS UI nach wie vor flüssig, mehr Reserven für Hintergrundprozesse. Android nun auch flüssig, da die 1GHz ausreichen um die UI flüssig darzustellen. Vorteil iOS: Spitzen, welche kurzfristig mehr als 1GHz benötigen, werden wegen Real Time Priorität aufgefangen. Android stottert kurzfristig, da keine Priorisierung vorliegt und der Prozess nicht mehr Ressourcen erhält.

Soweit ich das als Laie also verstehe, kann Android nie so flüssig wie iOS werden, weil es die Ressourcen teilen muss und der UI somit immer weniger Ressourcen zur Verfügung stehen als bei iOS. Potentere Hardware dürfte dieses Problem abmildern, da außer bei extremen Lastspitzen immer genügend Leistung vorhanden sein sollte um alles parallel abzuarbeiten. Es erscheint mir dann hier auch klar zu sein, warum Android am meisten von potenterer Hardware profitiert.
Aber wie genau ergibt sich hier jetzt ein Nachteil bei iOS für Mehrkern-Systeme? Beide Systeme verwenden Threads, Apple hat lediglich einen priorisiert. Warum ist dies dann nicht Dual-Core fähig? Bisher musste ja alles stoppen, weil der Single-Core im iPhone nicht die Power hatte um auch den Hintergrundprozess noch zu bearbeiten. Wieso funktioniert das nicht, dass die "überflüssige" Rechenpower sich jetzt um die anderen Prozesse kümmert? Am PC verwende ich das gleiche Prinzip, lediglich spiegelverkehrt: Ich gebe einem Prozess (z.B. komprimieren eines Films) eine niedrige Priorität um weiterhin flüssig arbeiten zu können und komprimiere den Film im Hintergrund mit all der überschüssigen Rechenkraft. Das funktioniert auch bei Mehrkernsystemen ganz gut...

natürlich nutzt iOS den DualCore; das da oben war auch nur wieder so eine Behauptung...

Es stimmt aber schon, auch auf dem iPad2 mit Dualcore bleibt der Seitenaufbau komplett stehen, wenn man vorher scrollt und den Finger drauf lässt.

Grade bei dem zweiten Artikel in den Comments sind auch ein paar kritische Worte zum Inhalt zu finden. Sollte man sich vielleicht auch mal ansehen. Da hat der Author auch angekündigt eine korrigierte Version zu veröffentlichen.

Genau so wie Straputsky es schreibt ist es "theoretisch" bei Apple wohl auch, praktisch das weiß nur apple

bin da auch kein "Pro" indem gebiet, waren nur ein paar gedanken deren berichtigung (und diskussion) toll wären


hab beim satz "kein 100% dualcore" extra ein "NOCH" eingefügt xD
apple kann da durchaus was machen softwaremäßig.

Mein Gedanke war der (jetzt andem Browser beispiel oben):

Wenn iOS immer die Aktion priorisiert was gerade läuft auf dem screen /bzw NUR die aktion und alles andere auf "pause" setzt was im hintergrund geht,
also das Laden der internetseite STOPT nur weil ich den screen berühre zum scrollen (also mit dem screentouch eine neue Aktion als Prio1 gesetzt wird)
dann wird in diesem fall der 2x core ja nicht gerade zu 100% (für den user) in der Safari app genutzt.
(bzw werden die cores nur für den seitenaubau genutz, nicht aber für mehr)
das sollte ja (mitunter) der sinn von 2x cores sein, mehrere aktionen / cpu berechnungen gleichtzeitig.
mehrere threads gleichtzeitig (ob priorisiert auf 1 oder 2 ist erstmal egal) -> aber doch nicht auf Stop/Pause xD

das man das nicht im dauerbetrieb macht bei apple, um evtl akku zu schonen, ist ja gut...
aber ne app könnte man damit doch "effizienter" machen.

evtl wiederspricht dies aber dem script selbst. und ist daher vielleicht garnicht möglich in iOS... (?)

mit dem rest stimmt ich dir zu
Android BRAUCHT hardware power!
Apple kann mit weniger leben. aber Apple lebt halt "total anders".

aber ja-bin mal auf den neuen editierten post von Andrew gespannt!!

edit: oh ok er wurde von andrew schon editiert!
gleich mal lesen,
der obrige link stimmt noch

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.

stimmt das denn so überhaupt? sinn macht es ja...

Zitat von CremeDeLaCreme

stimmt das denn so überhaupt? sinn macht es ja...

Aus Wikipedia:

Am 9. Januar 2007 stellte Apple einen Prototyp dieses Geräts (iPhone) auf seiner Macworld Conference & Expo in San Francisco vor.

Im Sommer 2005 kaufte Google das im Herbst 2003 von Andy Rubin gegründete Unternehmen Android, von dem nur wenig mehr bekannt war, als dass es Software für Mobiltelefone entwickelte und standortbezogene Dienste favorisierte. Am 5. November 2007 gab Google bekannt, gemeinsam mit 33 anderen Mitgliedern der Open Handset Alliance ein Mobiltelefon-Betriebssystem namens Android zu entwickeln.

könnte ja dann stimmen.
Google gab zwar im Nov2007 bekannt daran zu arbeiten, aber die eigentliche arbeit (im verborgenen) hat ja schon viel früher begonnen

Wurde auf einer anderen Seite schon zur Genüge diskutiert, aber denkt an zwei Sachen. Die bisherigen Testergebnisse von ICS und das der Typ inzwischen für MS arbeitet

Swiftkeyed mit meinem I9100.

Zitat von Aladan

Wurde auf einer anderen Seite schon zur Genüge diskutiert,

haste mal den link zu der seite bitte? evtl per PM
nicht um mein senf dazuzugeben, das werd ich nicht.

interessiert mich aber was da diskutiert wird.

Also die Betrachtungen, gerade zu Dual-Cores, hier gehen leider ziemlich in die falsche Richtung. Ich gehe es jetzt aus der Sicht von WP7 an, da ich da deutlich besser die Details kenne als bei iOS, nehme aber an, dass es technisch ähnlich funktioniert.

UI-Priorisierung, etc. stimmt soweit.

Allerdings ist es in WP7 so, dass die normale Software sich überlegt wie die UI gelayoutet sein soll, wo die Scroll-Position sein, soll, etc. und statt das ganze dann so zu rendern (zeitaufwendig) wird eine Liste mit den nötigen Zeichenoperationen erstellt (flott) und dann via DirectX (oder bei iOS dann halt OpenGL) direkt an den Grafikchip übergeben. Dieser ist ja ein massiv paralleler Rechner und genau für Rendering optimiert. Der kann dann halt aufgrund der Zeichenbefehle ein Bild erstellen. Verschiebe ich dieses Bild gibt es auch dafür spezielle Hardwareunterstützung => alles geht recht flott und kaum mit Ruckeln. Die CPU ist erst gefragt wenn neue Daten positioniert werden müssen oder nachgeladen (das kann dann trotzdem dazu führen, dass was dauert). Ähnlich verhält es sich beim Rendering von HTML-Seiten im IE9 (PC wie Desktop).

Bei den meisten Apps in Android ist es so, dass zwar das "Windows Management" und Überblendungen zwischen Anwendungen von der Hardware beschleunigt werden. Die einzelnen Controls in diesen rendert jedoch oft die CPU, die aber eher für allgemeine Aufgaben konzipiert ist und hier weit weniger leiststungsstark ist als der Grafikchip. Bei Anwendungen die direkt ICS targeten sieht es hier schon besser aus.

Rechenzeit kann man nicht Mhz-weise aufteilen sondern eben nur zeitlich (solange man keinen Dual-Core hat bedeutet Multi-Tasking, dass das OS zwischen mehreren Prozessen hin und her schaltet). D.h. dann bekommt halt Thread/Prozess 1 zunächst 50 ms und dann Thread/Prozess 2 50 ms, usw. Dauert jetzt das Rendering länger und läuft mit derselben Priorität ab wie andere Prozesse (z.B. Mailabruf) dann kann es evtl. schon mal nicht fertig werden => ruckelt.

Bei Windows Phone hingegen ist die CPU da schon wieder komplett frei, da das Rendering ja am Grafikchip läuft. Es gibt aber auch andere Flaschenhälse. Benötigt z.B. das Rendering-Daten aus dem Flash-Speicher (Icons, etc.) wird für das Laden dieser 1.) auch wieder die CPU gebraucht und problematischer 2.) wird z.B. gerade eine App installiert und daher gerade in den Flash-Speicher geschrieben/davon gelesen hat man dort einen Flaschenhals. Bei 2. hilft dann aber weder Dual-Core noch Quad-Core, noch GPU-Rendering weiter - da hilft nur die Prioritäten anders zu verteilen.

Die Sache mit dem nur ein Prozess und der im Vordergrund hängt hingegen weniger damit zusammen, dass es anders nicht ginge (werden halt die Zeichenbefehle vor der Grafikkarte abgefangen - UI eines Hintergrundprozesses zu rendern macht ja ohnehin genau gar keinen Sinn), sondern tatsächlich hauptsächlich damit, dass diese Prozesse eben die Experience beeinträchtigen können (im Hintergrund werden Videos transcodiert, ich will aber eigentlich ein Game zocken). Was aber wohl auch einige Anwender kennnen ist der Fall, dass man eine App im Hintergrund "vergessen" hat und dann der Akku recht zügig in die Knie geht, weil die im Hintergrund "irgendwas" tut - zumal man die ja auf sämtlichen OS ohne extra nachzusehen aktuell nicht sieht.

Der Weg den Google geht, dass Anwendungen, die als Target-API den Stand von ICS verwenden generell voll beschleunigt auszuführen und die älteren eben zwecks Kompatibilität weiter in Software rendern zu lassen halte ich aktuell für den einzig sinnvoll gangbaren Weg. Irgendwann sterben die älteren Geräte aus (ein paar Jahre), spätestens dann dürfte jeder seine App nur noch auf 4.0 als Basis zuschneiden und dann hat man auch überall beschleunigtes Rendering. Bis dahin heißt es wohl weiterhin damit zu leben, dass es halt doch öfters mal wo hakt.

So einen Übergang zu machen ist halt nicht einfach, wenn man es ursprünglich anders konzipiert hat. Bei Windows am Desktop ist es ja auch so, dass seit Windows Vista die Fensterberechnungen, etc. wenn Aero aktiv ist in der GPU gerendert werden, während der Inhalt der Fenster bei den meisten Anwendungen in Software berechnet wird. WPF und Silverlight nutzen hingegen wenn verfügbar auch dafür die Grafikhardware - eine Koexistenz ist also durchaus auch in der Praxis möglich.

Zitat von StevieBallz

Rechenzeit kann man nicht Mhz-weise aufteilen sondern eben nur zeitlich (solange man keinen Dual-Core hat bedeutet Multi-Tasking, dass das OS zwischen mehreren Prozessen hin und her schaltet). D.h. dann bekommt halt Thread/Prozess 1 zunächst 50 ms und dann Thread/Prozess 2 50 ms, usw. Dauert jetzt das Rendering länger und läuft mit derselben Priorität ab wie andere Prozesse (z.B. Mailabruf) dann kann es evtl. schon mal nicht fertig werden => ruckelt.

Auch du bleibst nicht von meinen dummen Fragen verschont...

Die entscheidende Größe wäre dann aber doch eher so etwas wie das Produkt aus Rechenzeit und Taktfrequenz, oder? Rechenzeit alleine ergäbe jetzt für mich nicht viel Sinn. Dann würde es ja keinen Unterschied machen, ob ich jetzt 1,0 oder 1,4 GHz habe.

Zitat von Straputsky

Auch du bleibst nicht von meinen dummen Fragen verschont...

Die entscheidende Größe wäre dann aber doch eher so etwas wie das Produkt aus Rechenzeit und Taktfrequenz, oder? Rechenzeit alleine ergäbe jetzt für mich nicht viel Sinn. Dann würde es ja keinen Unterschied machen, ob ich jetzt 1,0 oder 1,4 GHz habe.

Der Unterschied zwischen 1,0 und 1,4 GHz kommt (bei ansonsten identischen Bedingungen) daher, dass bei 1,4GHz innerhalb der (oben angenommenen) 50 ms pro Thread/Prozess mehr Operationen ausgeführt werden können als bei 1,0 GHz.

Ja, Äppler hat da schon recht. Um es aber noch komplizierter zu machen: 1 Ghz bedeutet nicht immer gleich viel. Viel hängt an der internen Architektur des Chips. So schafft ein Snapdragon der ersten Generation bei 1 Ghz weniger Operationen in 50 ms als ein Snapdragon der zweiten Generation bei 1 Ghz.

Auch interessant ist, dass wenn ich nur eine Anwendung habe, dass dann meisten Dual-Core 1 Ghz nicht doppelt so schnell ist wie ein 1 Ghz Single-Core. Kommt auf die Anwendung drauf an aber einerseits entstehen Zeitverluste wenn die Partner miteinander kommunizieren und sich abstimmen (was oft nötig ist). Und andererseits gibt es gemeinsam genutzte Resourcen die beide brauchen und auf die mehrfacher gleichzeitiger Zugriff halt Probleme bringen kann - da muss dann einer warten.