IOS und Android (garbage collection)

Ich habe nun erfahren, warum IOS mit den selben Mitteln (Hardware) schneller läuft als Android. Ich habe aber trotzdem noch nicht genau verstanden, wie IOS ohne garbage collection auskommt und Android eben nicht. Da ich in diesem Bereich vollkommen Ahnungslos bin, würde ich mich freuen, wenn mir jemand, der darüber mehr weiß, es erklären könnte, wo die Unterschiede liegen und warum Android nicht ohne garbage collection funktioniert.

Garbage Collection ist sicher nicht der Grund, warum IOS performanter wirkt. Garbage Collection ist ein Bestandteil der Speicherverwaltung von der Java Virtual Machine, kurz JVM und erleichtert die Freigabe von nicht mehr genutztem Speicher in einem Programm/App. Gerade ich als Softwareentwickler habe das schätzen gelernt, dass man sich nicht mehr um alles selbst künnern muss. Du kannst gern bei Wikipedia, Google & Co nachsehen, wie das genau funktioniert und was die Vor- und Nachteile sind.
Zur Performance von Android und IOS gibt es auch massenhaft Infos im Netz. Meiner Meinung nach scheint IOS performanter, da es weniger unterschiedliche Hardware gibt und Apple damit die Software besser an diese Hardware anpassen kann. Außerdem lässt Android mehr gleichzeitige Hintergrundprozesse bzw. Dienste zu, die sich dann um die geringen Ressourcen eines Smartphones streiten. Nicht zuletzt kann bei Android jeder sehr einfach und ohne hohe große Einstiegshürden Software entwickeln, während das bei IOS etwas kostspieliger ist. Mann könnte also behaupten, dass bei Android mehr unerfahrene Entwickler vorhanden sind, da jeder Entwickler sein kann. Bei IOS überlegt nan sich, ob man dafür extra na Mac kauft und die Entwicklermitgliedschaft jauft. Ich hab selbst auch schon zwei kleine Apps geschrieben. Eine Android App zu schreiben ist sehr einfach, eine gute, performantecund Ressoucen schonende zu schreiben ist aber alles andere als das.

Bedeudet das, dass der Entwickler der App dafür zuständig ist, ob eine App flüssig läuft oder nicht? Kann er es beeinflussen? Also viel Arbeit flüssig, wenig Arbeitsaufwand langsam?

Na ja, wenn man gemein wäre, könnte man das so formulieren, aber das wollen wir nicht. ;-)
Ein Kollege arbeitet sich gerade in Android ein. Daher hier mal ein Beispiel:
Man programmiert eine App, die das Wetter anzeigen soll. Beim Start soll sofort das Wetter am aktuellen Ort angezeigt werden. Man könnte jetzt direkt eine Verbindung zur Wetterdatenseite auf der Startseite programmiere. Wenn man das macht, blockiert das aber die Anzeige der Startseite. Diese muss warten bis das Laden fertig ist und hängt während dieser Zeit. Stattdessen sollte man das Laden der Wetterdaten laut Google Entwicklerrichtlinien in einem separaten Thread machen. Erstens blockiert das nicht die Anzeige und zweitens unterstützt man bei der Auslagerung in einzelne Threads die mehreren Kerne der Smartphone SOCs. Jeder Kern kann eine Aufgebe übernehmen und diese dann eben auch oft parallel arbeiten, anstatt die ganze App nur einen Kern nutzt und die wahre Leistung des Octacore verpufft. ;-)

Android Apps bestehen im Wesentlichen aus Java Code der zur Laufzeit interpretiert wird. Apple Apps bestehen aus in Maschienencode compilierten Objective-C oder Swift Progammen. Maschienencode ist schneller als interpretierter Code.

Das mit dem interpretierten Code ist nur teilweise richtig. Seit der neuen ART ab Android 5 wird der Code nativ ausgeführt. Sie Wikipedia: Android Runtime – Wikipedia