Test Android gegen iOS im Test: Zwei Religionen im Vergleich

[Liara T'Soni]

@Liara : Nur weil der Code der Apps durch den JIT-Compiler nun schneller abläuft, bedeutet das nicht dass sich an den 100ms für den GC etwas ändert. Denn diese Zeit ist ja im System gesetzt. So ein Timer sollte unabhängig von der Geschwindigkeit des Systems sein. Sonst würde es auch bei jedem anders getaktetem Gerät auch unterschiedlich sein. Und selbst auf demselben System würde es je nach aktueller Auslastung auch unterschiedlich schnell laufen. Er läuft aber überall alle 100ms.

Wie lange der GC dann alle 100ms für das bereinigen des Speichers benötigt, ist eine andere Sache. Sollte er nichts zu tun haben, macht sich das auch nicht bemerkbar. Und auf schnelleren CPUs wird er auch schneller fertig sein. Ich bin aber mal gespannt wie sich Android auf den ersten DualCores machen wird. Die Oberfläche dürfte davon profitieren.

Was ????

1. Der GC läuft nicht über einen 100ms Timer.

Wenn er nicht im Programm gerufen wird dann läuft er zu einer unbestimmten Zeit die von der Runtime vorgegeben wird. Er läuft nur dann wenn er gebraucht wird. Das kann 5 mal innerhalb einer Sekunde passieren aber auch auch erst nach 10sek sein.

2. Der GC, wenn er nicht von einem Programm aufgerufen wird, friert nicht das gesamte System ein sondern nur den Thread wo gerade Müll gelöscht werden soll.


Hier mal ein kurzer log habe die Stellen mit GC Aktivität markiert

11-18 21:11:14.775 D/ProcessManager(22726): executeProcess(): waiting for child process ...
11-18 21:11:14.785 D/ProcessManager(23437): executeProcess(): in child process ...
11-18 21:11:14.785 D/ProcessManager(23437): executeProcess(): in child process, after dup2()
11-18 21:11:14.785 D/ProcessManager(23437): executeProcess(): in child process, after closePipes()
11-18 21:11:14.785 D/ProcessManager(23437): executeProcess(): in child process, after fcntl()
11-18 21:11:14.785 D/ProcessManager(23437): closeNonStandardFds(): skipFd=[61]
11-18 21:11:14.785 D/ProcessManager(23437): closeNonStandardFds(): after getrlimit(): RLIMIT_NOFILE=[7], rlim_max=[1024]
11-18 21:11:14.795 D/ProcessManager(22726): executeProcess(): read child status count=[0], result=[0]
11-18 21:11:21.735 D/skia    (  324): purging 232K from font cache [27 entries]
[COLOR="Blue"]11-18 21:11:21.835 D/dalvikvm(  324): GC_EXPLICIT freed 9234 objects / 548224 bytes in 104ms
11-18 21:11:22.425 D/dalvikvm(22629): GC_EXPLICIT freed 197 objects / 11144 bytes in 59ms[/COLOR]
11-18 21:11:24.869 D/ContactMessageStore(  320): MSG_UPDATE_CONTACTS_TABLE >>
11-18 21:11:24.869 D/ContactMessageStore(  320): query thread cost time >>>2
11-18 21:11:24.875 D/ContactMessageStore(  320): createTempContactTable() >>>
[COLOR="Blue"]11-18 21:11:24.925 D/dalvikvm(22726): GC_FOR_MALLOC freed 5854 objects / 736216 bytes in 57ms[/COLOR]
11-18 21:11:24.965 D/ContactMessageStore(  320): createTempContactTable() <<<
11-18 21:11:24.965 I/Database(  320): sqlite returned: error code = 17, msg = prepared statement aborts at 17: [SELECT _id, recipient_address, message_count, unread_count FROM threads WHERE message_count > 0]
11-18 21:11:25.385 D/ContactMessageStore(  320): notify MmsSms
11-18 21:11:25.385 D/ContactMessageStore(  320): MSG_UPDATE_CONTACTS_TABLE <<
[COLOR="Blue"]11-18 21:11:28.435 D/dalvikvm(22903): GC_EXPLICIT freed 702 objects / 40984 bytes in 64ms
11-18 21:11:33.445 D/dalvikvm(  324): GC_EXPLICIT freed 401 objects / 15792 bytes in 75ms
11-18 21:11:38.415 D/dalvikvm(19279): GC_EXPLICIT freed 43 objects / 1992 bytes in 43ms[/COLOR]
11-18 21:11:40.255 W/KeyCharacterMap(22726): Bad keycharmap - filesize=32
11-18 21:11:40.255 W/KeyCharacterMap(22726): Error loading keycharmap file '/system/usr/keychars/bravo-keypad.kcm.bin'. hw.keyboards.0.devname='bravo-keypad'
11-18 21:11:40.255 W/KeyCharacterMap(22726): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
11-18 21:11:44.895 D/CSUtil  (19984): serverTime = 1288382273374
11-18 21:11:44.895 D/CSUtil  (19984): serverTime = 47517
11-18 21:11:44.905 D/CSUtil  (19984): curGMTTime = 72704909
[COLOR="Blue"]11-18 21:11:44.995 D/dalvikvm(19984): GC_FOR_MALLOC freed 14471 objects / 512968 bytes in 34ms
11-18 21:11:46.435 D/dalvikvm(22835): GC_EXPLICIT freed 2599 objects / 243128 bytes in 71ms
11-18 21:11:52.435 D/dalvikvm(22863): GC_EXPLICIT freed 9663 objects / 435712 bytes in 68ms
11-18 21:11:52.485 D/dalvikvm(22726): GC_FOR_MALLOC freed 2794 objects / 526752 bytes in 42ms
11-18 21:11:57.415 D/dalvikvm(23332): GC_EXPLICIT freed 1664 objects / 66080 bytes in 47ms[/COLOR]
11-18 21:11:57.675 I/wpa_supplicant(15690): Scan requested (ret=0) - scan timeout 30 seconds
11-18 21:12:00.497 D/HotSpotHW(  230): HotSpot: checking received event
11-18 21:12:00.497 D/HotSpotHW(  230): HotSpot result=0, buf=
11-18 21:12:00.505 I/wpa_supplicant(15690): got scan complete
11-18 21:12:00.505 I/wpa_supplicant(15690): wpa_supplicant_get_scan_results:return scan results2
11-18 21:12:00.505 I/wpa_supplicant(15690): AP:ssid[FRITZ!Box WLAN 3131],rssi[-45],BSSID=XX:YY:4a:a7:0d:7f
11-18 21:12:00.505 I/wpa_supplicant(15690): AP:ssid[EasyBox-E1E056],rssi[-85],BSSID=00:26:4d:e1:XX:YY
11-18 21:12:00.505 I/wpa_supplicant(15690): Received 649 bytes of scan results (2 BSSes)
11-18 21:12:00.505 I/wpa_supplicant(15690): wpa_driver_wext_get_scan_results---
11-18 21:12:00.505 D/LocationMasfClient(  230): getNetworkLocation(): Returning cache location with accuracy 75.0
11-18 21:12:00.875 W/LocationMasfClient(  230): uploadCollectionReport(): no ReplyElement
11-18 21:12:01.955 D/LocationManager(22835): requestLocationUpdates: provider = network, intent = PendingIntent{4779e5f8: android.os.BinderProxy@4779e5b0}
11-18 21:12:01.985 D/LocationManager(22835): requestLocationUpdates: provider = passive, intent = PendingIntent{4779e5f8: android.os.BinderProxy@4779e5b0}
11-18 21:12:03.916 W/KeyCharacterMap(22726): Bad keycharmap - filesize=32
11-18 21:12:03.916 W/KeyCharacterMap(22726): Error loading keycharmap file '/system/usr/keychars/bravo-keypad.kcm.bin'. hw.keyboards.0.devname='bravo-keypad'
11-18 21:12:03.916 W/KeyCharacterMap(22726): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
11-18 21:12:06.265 D/ProcessManager(22726): executeProcess(): waiting for child process ...
11-18 21:12:06.265 D/ProcessManager(23446): executeProcess(): in child process ...
11-18 21:12:06.265 D/ProcessManager(23446): executeProcess(): in child process, after dup2()
11-18 21:12:06.265 D/ProcessManager(23446): executeProcess(): in child process, after closePipes()
11-18 21:12:06.275 D/ProcessManager(23446): executeProcess(): in child process, after fcntl()
11-18 21:12:06.275 D/ProcessManager(23446): closeNonStandardFds(): skipFd=[52]
11-18 21:12:06.275 D/ProcessManager(23446): closeNonStandardFds(): after getrlimit(): RLIMIT_NOFILE=[7], rlim_max=[1024]
11-18 21:12:06.295 D/ProcessManager(22726): executeProcess(): read child status count=[0], result=[0]

Edit:
Ohne jegliche Kenntnisse über den GC kann man auch so die Aussage dass der GC alle 100ms das System einfriert eindeutig falsifizieren. Wenn der GC selbst zum Löschen 25-200ms braucht dann würde ja bedeuten, dass das System sich im dauerhaften Status der Einfrierung befindet und versucht Strings, Objekte zu löschen die gar nicht vorhanden sind. Sinn ?

 

[Fonce]

Außerdem erklären die auch auch im CRE das wenn man eine for-Schleife anlegt und in dieser immer wieder eine variable deklariert der GC alle 100ms aufgerufen wird!

Also z.B. so:

for(int i=0;;i++){
int j = i;
}

EDIT:
Dadurch würden nämlich im Stack immer wieder Objekte vom Typ int angelegt und da die natürlich in relativ regelmäßigen Abständen geschieht folgt daraus, das in relativ gleichem Abstand der GC aufgerufen wird und dieser auch etwa die gleiche Zeit zum aufräumen braucht.
Das dürfte sich eigentlich auch mit jeder normalen VM leicht nachbilden lassen.
EDIT-ENDE:

Das bedeutet aber noch lange nicht das dies immer eintritt.
Auch kann man dies einfach lösen in dem man die Variable vor der schleife deklariert.


Also so:

int j;
for(int i=0;;i++){
j = i;
}

EDIT 2:
@Liara T'Soni
Die Log kann ich nur mit adb auslesen wenn man root Zugang hat oder? Schreibe derzeit nämlich ein Programm für Android und da könnte das auslesen denke ich ganz hilfreich werden.

 

[Liara T'Soni]

Es wird den Entwicklern nahe gelegt den GC eben nicht manuell aufzurufen. Die Speicherverwaltung läuft automatisch und jeder manuelle Eingriff verursacht eher Probleme z.B. Interrupt des gesamten Systems was dann die Performance beeinträchtigt. Der GC ist in seinem Algorithmus schon optimiert, lediglich echte Experten würde hier durch Anpassung es schaffen einen Performance Gewinn zu erzielen. Und wie schon gesagt funktioniert der automatische GC wie ein Zähler Stichwort: reference counting und nicht wie ein Timer (!!)

@Fonce
Keine Ahnung ich habe mir den Podcast nicht wirklich angehört, das sind knapp 2 Stunden. Da lese ich lieber ein zwei Artikel in weniger als einer halben Stunde.

Aber wer bitte deklariert Variablen innerhalb von Schleifen ? Lernt man nicht bereits in der ersten Stunde Programmierung dass man so etwas nicht machen soll und wo Variablen stattdessen deklariert werden ? Ich kann mich da wage noch an so etwas erinnern. Ist nur schon 10 Jahre her.

Das mit der unendlichen for-Schleife, die einen Variable für den Schleifen Zähler innerhalb deklariert hat ist zwar ein nettes Beispiel dass der GC hier evtl. alle 100ms zuschlagen würde aber dabei bleibt es auch. Ist es nicht etwas realitätsfremd ? Wer baut einen unendlichen Schleifen Zähler der eine Million mal in der Sekunde eine Variable deklariert? Witzig, so etwas hat man in den ersten Stunden C++ Programmierung gemacht um zu sehen was dann passiert.


Abschließend kann ich nur sagen dass AntiUser und Kampfkeks zu dem Thema lediglich ein theoretisches Beispiel missbraucht haben um ein Ruckeln auf Android Systemen zu erklären.

Bei Android gibt es den GC, welches alle 100ms läuft und das System kurz auf Eis legt.

Behauptung welche irrtümlich als Fakt deklariert wurde ist hiermit widerlegt!


Edit:
Den logcat kannst du auch ohne adb und root auslesen. Entsprechende Apps findest du im Market: aLogcat, Catlog

 

[Fonce]

Naja, die jetzt auch nicht direkt von einer unendlichen Schleife gesprochen im CRE, so wie sie es erzählt haben, kann man es mit dem Code von mir oben gut verdeutlichen, das es ein absolut blödes und theoretisches Beispiel ist.
Aber das beste daran ist, das man sehr viele damit aus dem Takt bringen kann und nicht nur Android, da ungebremster Duchlauf und ständige Speicherbelegung. Wobei gute C/C++ Compiler das dann eigentlich so umschreiben dürften wie ich es gemacht habe, der Compiler von Java kann dies aber definitiv nicht, was man auch leicht mit der Iterator basierten Schleife testen kann welche einem Eclipse zusammenbastelt.
Grob gesagt kann man sagen, das man bei der Programmierung für Android genauso aufpassen muss wie überall anders auch. Man muss halt Ahnung von dem haben was man dort macht.

 

[Liara T'Soni]

Ja sicher, ich stecke da jetzt nicht so tief in der Materie, du hast da sicherlich mehr Ahnung von. Auf der I/O im Mai wurde angedeutet das der GC im nächsten Milestone (Gingerbread oder Honey) defintiv geändert wird und man bereits daran arbeitet.

Ich bin schon auf Gingerbread gespannt vor allem könnte noch eine erhebliche Verbesserungen auf uns zu kommen die da wäre:
Hardware beschleunigtes UI und web Browsing durch die GPU

 

[Magellan]

Soviel zu den "Fakten" warum Android ständig ruckeln würde
Da bin ich ja echt erleichtert dass ich mir keine Gedanken machen muss warum mein Desire nicht 10mal die Sekunde ruckelt!
Danke, interessanter Einblick.

 

[Fonce]

Naja, was heisst "tief in der Materie", hab mir das jetzt aus dem was ich aus dem weiss wie Objekte in einer JavaVM ablegt werden hergeleitet und ich denke das es in der DalvikVM nicht viel anders realisiert worden sein wird.

 

[AntiUser]

Wie mir scheint meinte er nicht wann er läuft, sondern wie lange er läuft. Das passt mit dieser Aussage überein:

In a performance sensitive code path, like the layout or drawing method of a view or the logic code of a game, any allocation comes at a price. After too many allocations, the garbage collector will kick in and stop your application to let it free some memory. Most of the time, garbage collections happen fast enough for you not to notice. However, if a collection happens while you are scrolling through a list of items or while you are trying to defeat a foe in a game, you may suddenly see a drop in performance/responsiveness of the application. It's not unusual for a garbage collection to take 100 to 200 ms. For comparison, a smooth animation needs to draw each frame in 16 to 33 ms. If the animation is suddenly interrupted for 10 frames, you can be certain that your users will notice.

Quelle

Auch in deinem Log sieht mehr deutlich, das der GC durchaus mal 100ms etwas blockieren kann. Wenn du grade diesen Anwendung benutz oder andere Prozesse diese Anwendung benutzen, dann kann es ruckeln. Natürlich wurde das Problem mit 2.2 weiter entschärft und auch die großen Arbeitsspeicherzahlen entschärfen das weiter. Das Grundlegende Problem bleibt aber bestehen. Das sieht man sehr schön bei G1 unter 2.2 vs. N1 unter 2.2. Vergleicht man die beiden dann sieht man, das die wesentlich bessere Hardware viel von den Problemen entschärft hat, die damit aber leider nicht weg sind.

Und hier hat das iPhone einfach einen Vorteil, denn es hat keinen GC.

Das Rendern der GUI über Hardware kommt noch hinzu, aber da hoffe ich auf 2.3(3.0).

 

[Liara T'Soni]

Kennst du das Video schon ? http://www.youtube.com/watch?v=ptjedOZEXPM
Ist zwar etwas älter von der google I/O 2008 als noch nicht der JIT implementiert wurde, dürfte aber für dich interessant sein um zu verstehen wie DalvikVM funktioniert.

 

[Fonce]

Wie mir scheint meinte er nicht wann er läuft, sondern wie lange er läuft. Das passt mit dieser Aussage überein:



Quelle

Auch in deinem Log sieht mehr deutlich, das der GC durchaus mal 100ms etwas blockieren kann. Wenn du grade diesen Anwendung benutz oder andere Prozesse diese Anwendung benutzen, dann kann es ruckeln. Natürlich wurde das Problem mit 2.2 weiter entschärft und auch die großen Arbeitsspeicherzahlen entschärfen das weiter. Das Grundlegende Problem bleibt aber bestehen. Das sieht man sehr schön bei G1 unter 2.2 vs. N1 unter 2.2. Vergleicht man die beiden dann sieht man, das die wesentlich bessere Hardware viel von den Problemen entschärft hat, die damit aber leider nicht weg sind.

Und hier hat das iPhone einfach einen Vorteil, denn es hat keinen GC.

Das Rendern der GUI über Hardware kommt noch hinzu, aber da hoffe ich auf 2.3(3.0).

Naja ob es ein Vorteil ist ist eine ganz andere Geschichte, den wenn auf dem iPhone ein Programmierer bei den Pointer mist baut, dann hilft dort nur noch ein Neustart um den Speicher wieder freizugeben! In deiner DalvikVM kann dies nicht passieren, da hier Speicher generell nur durch den GC freigegeben wird und der Entwickler sich darum nicht selber kümmern muss.
Ich kann ja jetzt schlecht beurteilen wieviel Erfahrung du in der Programmierung hast, aber wenn diese sehr gering ist, solltest du besser nicht Aussagen über Vor- bzw. Nachteile des einen oder anderem Systems treffen(Also bzgl. C/C++/objective C gegen DalvikVM).
Auch ist dein Beispiel mit G1 vs. N1 totaler unsinn, den dann könnte man das iPhone 3G mit dem iPhone 4 vergleichen, was aufs selbe hinausläuft, da bessere Hardware nun einmal immer zu besserer Performance führt.

 

[AntiUser]

@Fonce

Natürlich hat alles Vorteile und Nachteile. Vorteil kein GC ist hier jetzt wohl genug Durchgekaut. Aber ganz klarer Nachteil bei iOS, wenn der Programmierer scheiße baut, dann geht es richtig Rund. Und er kann durchaus etwas mehr Mist bauen.

Hier noch mal ein Artikel zur OS X Speicherverwaltung, die auch dem iOS nicht grundsätzlich anders ist:
http://wiki.osxentwicklerforum.de/doku.php?id=wiki:speicherverwaltung

Zum Programmieren kann ich nur so viel sagen, das ich schon ein paar Programme entwickelt habe . Bisher nur in Java aber aktuell schwenke ich um auf Objectiv C. Ich denke(hoffe) das das reicht .

Zum 3G vs. iPhone 4 ist natürlich richtig. Aber grade mit iOS 4.2 sieht man, das Apple das System noch weiter optimieren kann und es auch tut. Und grade da ist, meiner Meinung nach, der Unterschied. 2.2 ist ein unheimlich Optimiertes System, läuft aber unter dem G1 nicht wirklich. Vergleicht man 2.2 auf dem G1 mit dem iPhone 3G (ungefähr gleiche Hardware), denn merkt man gut welches schneller läuft.

Ganz klar ist auch, bei entsprechender Hardware verringern sich die Probleme in einen Maße, das diese für den Anwender quasi nicht mehr existent sind.

Auch klar ist, das wir hier grade auf sehr hohen Niveau meckern . Aber ich finde diese Sachliche Diskussion gut, ich lerne immer gern neue Dinge hinzu.

 

[voon]

Interessant .... da sieht man schoen, das das nicht (nur) Apple, sondern Nextstep ist unter der Haube ueberall diese NS-Prefixe....

 

[Fonce]

objective C diente ja auch als Sprache für NextStep

Zitat von Wiki:

Objective-C wurde hauptsächlich von Brad Cox und Tom Love in den 80er Jahren bei PPI, später Stepstone, entwickelt, später dann von NeXT in die GNU Compiler Collection integriert, um als Basis für NextStep zu dienen.

 

[AntiUser]

So ... ich habe mir jetzt mal das HTC Desire besorgt, da ich leider nur Zugriff auf ein altes Android Gerät hatte. Zwei Sachen sind mir dabei negativ sowie positiv aufgefallen.

Negativ:

Zum einen das angesprochene Ruckeln der Oberfläche kann man mit dem Gerät aber 100% nachvollziehen. Grade im Menü merkt man das deutlich. Ich persönlich habe das Gefühl, dass dieses Gerät erst eine Zeit braucht um auf den aufgelegten Finger zu reagieren. Bei iPhone klebt die Oberfläche am Finger, bei Android hat das immer ein wenig Spielraum. Ansonsten ruckelt es leicht, wenn es im Menü bedient. Das finde ich extrem ärgerlich. Was richtig ist, das es auf der normalen HTC Sense Oberfläche nicht ruckelt.

Für mich ein enormer Kritikpunkt ist die inkonsistente Bedienung. Die HTC Programme sehen anders aus als die von Google. Die wiederum anders als welche aus dem Market u.s.w.! Das finde ich extrem nervig. Und nennt mich verwöhnt, aber mir fehlen die ganzen schönen Animationen. Es sieht alles irgendwie so trocken aus ...

Positiv:

Die Widgets sind eine super geniale Sache. Grade der HTC Friend Stream ist super und so etwas fehlt mir absolut bei meinem iPhone.

Der W-Lan Hotspot, weswegen ich die Kiste auch gekauft habe. Habe es fast genau so günstig wie ein MiFi gekommen. Da habe ich mich dann für HTC entschieden .

Noch mal eine Frage an die Experten:

Ich suche ein Programm, womit ich eine Übersicht der offenen Programme wie (oder ähnlich wie) iOS habe. Kennt da jemand was? Die acht offenen Programme reichen mir persönlich nicht. Und kennt jemand einen guten RSS-Reader ?

 

[Gu4rdi4n1337]

ES Taskmanager oder Advanced Taskmanager

da kannste beenden, hinwechseln etc

das einzigste ruckeln was ich merke ist in der kompletten app übersicht

oder du drückst mal lange die home taste da kommt ne auswahl der letztens geöffneten programme

 

[AntiUser]

das einzigste ruckeln was ich merke ist in der kompletten app übersicht

Genau das meinte ich .

Danke für die Tips, probiere ich mal aus .

 

[Gu4rdi4n1337]

hast du jetzt eigentlich die AMOLED oder SLCD variante?

 

[meiermanni]

Mein Iphone geht mir momentan so auf den Sack nach Update auf 4.2.1

Erst einen Tag lang der Authentifizierungsfehler(der sich dann selbst behoben hat), jetzt kommt es zu keiner Datenübertragung mehr mit 3G obwohl es verfügbar ist(über Edge wird auch nichts geladen). Wenn ich dann allerdings über WLAN reingehe funzt es.

Geht mir echt tierisch auf den Keks, weil so ist das Gerät unbrauchbar.
Wo ist da jetzt die hochgelobte Qualität, weil sowas kann echt nicht sein, solche Probleme hatte meine Freundin mit ihrem Wave noch nie (und das bei Samsung!).

 

[Gu4rdi4n1337]

naja gestern versucht nem iP4 was per bluetooth zu schicken...

HTC Desire wird nicht unterstützt war die meldung xD

 

[meiermanni]

naja gestern versucht nem iP4 was per bluetooth zu schicken...

HTC Desire wird nicht unterstützt war die meldung xD

sorry, aber mit diesem Kackphone kannst du nichts per Bluetooth verschicken. Das ist echt der größte Fail ever. Hätte ich das vorher gewusst hätte ich es nie gekauft. Anscheinend wird jeder User kriminalisiert, man soll wo schön im Itunes alles kaufen und BT wurde zumindest für Datentausch geschlossen, bloß blöd wenn man mal kurz seiner Mutter ein Bild ihres Enkels schicken möchte