Was es mit dem Project Svelte in Android KitKat auf sich hat

Speicherschonender Schokoriegel

Arne Limburg, Lars Röwekamp


Der wachsende Funktionsumfang von Android führte in den vergangenen Versionen immer mehr dazu, dass auch der Speicherverbrauch deutlich anstieg. Dementgegen steht eine immer größere Marktverbreitung und damit einhergehend eine wachsende Anzahl an Low-Budget-Geräten. Auf diesen, in der Regel mit wenig Arbeitsspeicher ausgestatteten Geräten waren neuere Android-Versionen aufgrund des hohen Speicherbedarfs häufig so langsam, dass sie praktisch nicht zu benutzen waren.

Zwar schraubten die Android-Entwickler bereits in den Android-Versionen 4.1, 4.2 und 4.3 (alle unter dem Namen Jelly Bean released) erheblich an der Performance, aber erst mit der jetzt erschienenen Version 4.4 wurde das Problem des Arbeitsspeicherbedarfs angegangen.

Geschehen ist das mit dem Project Svelte, in dessen Rahmen nicht nur die Core-Funktionen von Android allesamt auf geringen Speicherbedarf hin optimiert wurden. Zusätzlich wurde (ehemalige) Core-Funktionalität in externe Google-Apps ausgelagert, was zur Folge hat, dass sie sich jetzt nicht mehr zwingend im Speicher befinden müssen, wenn sie nicht benötigt werden. Außerdem wurde den App-Entwicklern im Bereich Speicherbedarf unter die Arme gegriffen. Neben einem verbesserten Verfahren für das Recycling von Bildarbeitsspeicher (die Verwendung des Parameters BitmapFactory.Options.inBitmap wurde optimiert, dazu später mehr) gibt es nun eine Möglichkeit, auf Geräte mit wenig Arbeitsspeicher programmatisch zu reagieren. Dies kann über die Funktion ActivityManager.isLowRamDevice() geschehen, mit der, wie der Name schon sagt, überprüft werden kann, ob man sich auf einem Gerät mit wenig Arbeitsspeicher befindet [2]. Was aber soll ein Entwickler tun, wenn er genau das feststellt?

Fallstricke beim Speichermanagement

Generell muss sich ein Java-Entwickler nicht um die Freigabe von nicht mehr benötigtem Arbeitsspeicher kümmern. Dafür sorgt automatisch der Garbage Collector. Und das gilt prinzipiell auch für Android-Entwickler.

Dennoch müssen insbesondere in Android einige Dinge beachtet werden, damit der Garbage Collector korrekt arbeiten kann. Dass er nur aufräumt, wenn keine Referenz auf eine Datenstruktur mehr existiert, sollte erfahrenen Entwicklern hinlänglich bekannt sein. Die direkte Konsequenz daraus ist natürlich, dass große Datenstrukturen wie z. B. Bilddaten nur als Instanzvariable (z. B. einer Activity) gehalten werden sollten, wenn sie tatsächlich noch benötigt werden. Sollten sie für die Lebenszeit der Activity notwendig sein, ist ein ...

Was es mit dem Project Svelte in Android KitKat auf sich hat

Speicherschonender Schokoriegel

Arne Limburg, Lars Röwekamp


Der wachsende Funktionsumfang von Android führte in den vergangenen Versionen immer mehr dazu, dass auch der Speicherverbrauch deutlich anstieg. Dementgegen steht eine immer größere Marktverbreitung und damit einhergehend eine wachsende Anzahl an Low-Budget-Geräten. Auf diesen, in der Regel mit wenig Arbeitsspeicher ausgestatteten Geräten waren neuere Android-Versionen aufgrund des hohen Speicherbedarfs häufig so langsam, dass sie praktisch nicht zu benutzen waren.

Zwar schraubten die Android-Entwickler bereits in den Android-Versionen 4.1, 4.2 und 4.3 (alle unter dem Namen Jelly Bean released) erheblich an der Performance, aber erst mit der jetzt erschienenen Version 4.4 wurde das Problem des Arbeitsspeicherbedarfs angegangen.

Geschehen ist das mit dem Project Svelte, in dessen Rahmen nicht nur die Core-Funktionen von Android allesamt auf geringen Speicherbedarf hin optimiert wurden. Zusätzlich wurde (ehemalige) Core-Funktionalität in externe Google-Apps ausgelagert, was zur Folge hat, dass sie sich jetzt nicht mehr zwingend im Speicher befinden müssen, wenn sie nicht benötigt werden. Außerdem wurde den App-Entwicklern im Bereich Speicherbedarf unter die Arme gegriffen. Neben einem verbesserten Verfahren für das Recycling von Bildarbeitsspeicher (die Verwendung des Parameters BitmapFactory.Options.inBitmap wurde optimiert, dazu später mehr) gibt es nun eine Möglichkeit, auf Geräte mit wenig Arbeitsspeicher programmatisch zu reagieren. Dies kann über die Funktion ActivityManager.isLowRamDevice() geschehen, mit der, wie der Name schon sagt, überprüft werden kann, ob man sich auf einem Gerät mit wenig Arbeitsspeicher befindet [2]. Was aber soll ein Entwickler tun, wenn er genau das feststellt?

Fallstricke beim Speichermanagement

Generell muss sich ein Java-Entwickler nicht um die Freigabe von nicht mehr benötigtem Arbeitsspeicher kümmern. Dafür sorgt automatisch der Garbage Collector. Und das gilt prinzipiell auch für Android-Entwickler.

Dennoch müssen insbesondere in Android einige Dinge beachtet werden, damit der Garbage Collector korrekt arbeiten kann. Dass er nur aufräumt, wenn keine Referenz auf eine Datenstruktur mehr existiert, sollte erfahrenen Entwicklern hinlänglich bekannt sein. Die direkte Konsequenz daraus ist natürlich, dass große Datenstrukturen wie z. B. Bilddaten nur als Instanzvariable (z. B. einer Activity) gehalten werden sollten, wenn sie tatsächlich noch benötigt werden. Sollten sie für die Lebenszeit der Activity notwendig sein, ist ein ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang