Project Svelte: Wie Google Android 4.4 schrumpfte

In einem Interview hat Dave Burke von Android jetzt ein paar Details bekannt gegeben, wie Google Android schrumpfte, damit ab Android 4.4 KitKat wieder Geräte mit 512 MB RAM Arbeitsspeicher unterstützt werden können.

Android KitKat Logo

Burk hat es gegenüber den Kollegen schon wirklich ziemlich passend beschrieben, denn nach dem Project Butter musste Android wieder durch die fettige Butter entstandenes Gewicht verlieren. Besonders Geräte mit nicht so guter Hardware hatten von Project Butter gar nichts, im Gegenteil, die Anforderungen für ein wirklich flüssiges System sind damit scheinbar gestiegen. Also musste Project Svelte her, die erste richtige Diät für Android. Ihr Ergebnis gibt es ab Android 4.4 KitKat, weniger passend trägt auch diese Version wieder eine Süßigkeit als Beinamen.

Für Project Svelte hat man ein Nexus 4 ordentlich begrenzt, statt vier nur noch zwei Kerne verfügbar gemacht, die Taktgeschwindigkeit herabgesetzt, die Auflösung gesenkt und den Arbeitsspeicher auf 512 MB RAM begrenzt. Android lief nun alles andere als geschmeidig, doch das galt es zu ändern. Zunächst ging es an die Arbeit den sogenannten Memory Footprint zu senken, damit wird quasi der Speicherbedarf einer Anwendung festgelegt. Android selbst musste hier enorm abschlacken, um diesen allgemeinen Speicherbedarf auf 512 MB oder weniger zu begrenzen. Diese Diät wurde auch bei allen Apps angewandt, die auf einem Nexus-Gerät vorinstalliert sind. Auch verbessert hat man, wie Apps auf zu wenig verfügbaren Arbeitsspeicher reagieren.

Besonders wichtig war dann noch App-Entwicklern bessere Funktionalitäten bereitzustellen, wodurch die den Speicherverbrauch ihrer Apps besser erkennen und daraufhin senken können. Mit der Funktion ProcStats (Entwickleroptionen ab KitKat) lässt sich nun viel besser analysieren, welche Apps wie viel Arbeitsspeicher verbrauchen, vor allem auch, wann sie das unnötig im Hintergrund tun, während sie eigentlich gar nicht mehr wirklich aktiv sind. Entscheidend ist dann natürlich noch, wie man mit Apps vorgeht, die stundenlang nicht aktiv waren aber weiterhin Arbeitsspeicher für sich beanspruchen. Das wird vom System erkannt, sodass diese Apps dann komplett im Hintergrund „gekillt“ werden, um Arbeitsspeicher nicht unnötig zu verbrauchen.

Schlussendlich bleibt ein Problem bestehen: Entwickler müssen ihre Apps selbst entschlacken und optimieren. Ein schlankeres Betriebssystem ist nur ein Teil, wenngleich ein wichtiger, doch auch die Mitarbeit von App-Entwicklern ist nun gefragt.

[asa_collection items=1, type=random]Beliebte Smartphones[/asa_collection]

(Quelle ReadWrite)

  • Pino

    Wie dumm muss man eigentlich sein. Da kastriert man ein Nexus 4 künstlich und erzeugt unrealiste Vergleiche (die SoC Architektur macht auch einen riesßen unteschied aus, Billigphones nutzen die sicher nicht) ansatt einfach ihre eigenen Mittelklasse- und Low-End-Geräte zu nehmen. Es leuchtet mir einfach nicht ein wie man bei einem Projekt, das wie für das Galaxy Nexus und Nexus S gemacht ist, so einen scheiß fabrizieren kann.
    Nur um ihre eigene 18 Monate-Vorgabe ja nicht zu überschreiten. Da sieht man wie ernst die das nehmen. Nexus 7 2012-Nutzer können jetzt mit absoluter Sicherheit wissen, dass ihr Gerät nie wieder ein Update sieht.

    • Aber wenn es rein um die Menge des Arbeitsspeichers geht, ist scheiß egal wie alt oder neu das Gerät ist, der Rest spielt erst recht kaum eine Rolle?!

      • Pino

        warum reduzieren sie dann den takt und die kerne? also bitte, man hätte einfach die beiden geräte updaten können und gut ist. dann hätte man denen das abgekauft, dass die android entschlacken möchten um es zu defrgamentieren. in einem jahr wird sowieso kein schwein mehr ein smartphone mit 512mb bauen. und die marke nexus hätte wieder mehr als nur den sinn eines preiswerten smartphones…

        • Ja gut, warum die anderen Module künstlich nach unten geschraubt wurden, macht für mich auch nicht viel Sinn im Bezug auf den Arbeitsspeicher.

          Und bzgl der Updates bin ich nach wie vor Meinung die Treiber sind das Problem. Das mit den 18 Monaten ist nur eine faule und zugleich dumme Ausrede.

          • Pino

            seh ich nicht so. google schließt die verträge mit den chipherstellern. wenn sie das mit den treibern nicht langfristig regeln sind SIE schuld. auch wenn texas instrument keine neuen socs mehr produziert, aufgelöst haben sie sich nicht.

            ein vorbild für die anderen hersteller ist google so jedenfalls nicht. langfristig wird es also eher schlechter als besser. Ich prognostiziere: es wird in den nächsten wochen und monaten sicher keine welle von billigen android 4.4 smartphones mit 512mb ram geben, und wenn dann werden die paar wenige genauso keine updates bekommen wie bisher.

          • its me

            Tolle Prognose, wenn es im Einsteigerbereich schon 1GB Ram gibt.
            Weshalb sollten Hersteller den Anpassungsaufwand auf sich nehmen, um kostenlose Updates für alte Phones zu bringen (z.B. Sony Xperia Ray mit 512MB)?

            Die bringen ganz bewusst keine, damit man sich neue Geräte anschafft…

          • Pino

            eben, deswegen hätte google ja zeigen können, das man es ernst meint und wenigstens die eigenen aktualisieren sollen. wer dann wirklich so großen wert auf updates legt und sein handy/tablet zwei jahre oder länger nutzen wöllte, hätte sich über die nexus-linie gefreut. so bleibt nexus eher was für preisbewusste.

          • Ja, das stimmt schon.

          • Bei uns sowieso nicht, in Asien aber nach wie vor ohne Ende.

          • Martin Jastram

            jedenfalls kommen dann keine geräte mit 2.X mehr auf den markt, sondern mindestens 4.4, um die vorteile von svelte nutzen zu können.
            die taktik geht doch auf.

      • Martin Jastram

        ziel ist ja wohl, NEUE geräte mit 4.4 auszustatten und keine alten gurken.
        da macht ein beschnittenes N4 ImhO jede menge sinn.
        ich weiß gar nicht, warum wir da überhaupt drüber reden.

    • Martin Jastram

      dumm ist hier nur einer…..

  • Pingback: Anonymous()

  • Frederic Püllen

    Immer wieder interessant wie Entwickler bei solchen Verbesserungsvorgängen vorgehen, danke für den Einblick :)