Speicherprobleme bei Android auf älteren Geräten umgehen

Unter Android wird die Arbeitsspeicherverwendung von Managed Anwendungen durch die Parameter

• dalvik.vm.heapgrowthlimit
• dalvik.vm.heapsize
• dalvik.vm.heapstartsize

Sollen Änderungen an den Parametern Permanent vorgenommen werden kann entweder der Eintrag in /system/build.prop modifiziert werden, was ein beschreibbares und nicht signiertes (!) System Image voraussetzt (es sei denn das System Image wird nach der Änderung signiert). Wird ein Signiertes System Image beschreibbar gemounted und verändert und die Signatur vom Bootloader geprüft kann das Image nicht mehr gebootet werden!

Eine Alternative für diese Eigenschaften stellt eine Eintragung in /data/local.prop dar. Diese kann auch von der Kommandozeile mit Hilfe von echo erfolgen (im folgenden wird eine bestehende Datei gelöscht und mit den gelisteten Properties neu erstellt):

echo 'dalvik.vm.heapgrowthlimit = 128m' > /data/local.prop
echo 'dalvik.vm.heapsize = 256m' >> /data/local.prop

Nach den Änderungen in der local.prop ist ein Neustart des Systems bzw. ein setzen mittels setprop sowie ein Neustart von Zygote notwendig.

dalvik.vm.heapgrowthlimit

Die Eigenschaft dalvik.vm.heapgrowthlimit stellt das absolute Limit für Speicher innerhalb einer einzelnen Dalvik VM Instanz dar, dass eine Anwendung ausnutzen kann. Bei vielen älteren Geräten ist dieser Parameter auf 24 bzw. 48 MB gesetzt, womit eine Anwendung maximal 24 bzw. 48 MByte Speicher zur Verfügung stehen, auch wenn das Gerät selbst über mehrere GByte Arbeitsspeicher verfügen sollte. Diese niedrigen Werte sollen vor allem das Multitasking verbessern, da so viele Prozesse parallel im Speicher gehalten werden können. Da auf Android kein Paging erfolgt werden bei voller Arbeitsspeicherbelegung Prozesse (im Normalfall beliebige Prozesse) “beendet”, d.h. einfach abgeschossen. (Das erfolgt pbrigens auch unter Linux, wenn Speicher durch Overcommit zugesagt wurde, aber wegen einer vollständig genutzten Swap Partition nicht mehr zur Verfügung gestellt werden kann anstelle von Fehlermeldungen der malloc/new Funktionen!).

Das Anheben des Parameters erlaubt also einerseits Anwendungen die Nutzung von mehr Speicher, was zum Beispiel für Mapping Anwendungen interessant sein kann um mehr Informationen auf einem Bildschirm darstellen zu können, hat allerdings auch den Nachteil, dass weniger Anwendungen im Speicher gehalten werden können, wenn Anwendungen wirklich so viel Speicher reservieren. Aufgrund der Funktionsweise des Java Garbage Collectors kann davon ausgegangen werden, dass der zur Verfügung gestellte Speicher mit der Zeit auch belegt wird.

dalvik.vm.heapstartsize

Der Parameter dalvik.vm.heapstartsize regelt die Größe des Heaps wenn die Dalvik VM gestartet wird, also die Speichermenge die auf jeden Fall von der VM für den Heap belegt wird. Ist diese zu klein muss auf jeden Fall zusätzlicher Speicher reserviert werden; ist er zu groß wird Speicher verschwendet. Aus diesem Grund ist dieser Parameter häufig auf 5 MByte gesetzt.

dalvik.vm.heapsize

Diese Heapgröße stellt das Speichergrößenlimit für Anwendungen, die in ihrem Manifest die Eigenschaft android:largeHeap=true gesetzt haben, also bekannt geben viel Speicher zu benötigen. Leider funktioniert diese Deklaration erst Seit Android 4 und hier nicht auf allen Geräten. Außerdem ist unklar welche Speichergröße solche Anwendungen erhalten und ob die jeweilige Plattform die Deklaration überhaupt berücksichtigt. Aus diesem Grund setzen wenige Anwendungen diesen Eintrag im Manifest, selbst wenn sie viel Speicher benötigen.

Die dalvik.vm.heapsize Property sollte immer größer oder gleich dalvik.vm.heapgrowthlimit sein.

Werte

Für dalvik.vm.heapstartsize hat sich ein Wert von 5m bewährt, das absolute Speicherlimit für große Heaps (dalvik.vm.heapsize) ist auf den meisten Geräten bereits auf 256m gesetzt und meistens ebenfalls ausreichend. Das kleine Speicherlimit (dalvik.vm.heapgrowthlimit) ist bei älteren Geräten oft auf 24m - 48m gesetzt was manchmal zu Problemen führen kann. Ein Anheben auf 64m ist meistens kein Problem, 128m liefert ebenfalls unter einigen Bedingungen sehr gute Ergebnisse. Voraussetzung ist allerdings, dass nicht viel zu viele Hintergrundprozesse laufen, die zusammen mehr Speicher belegen würden als vorhanden ist, da sonst beliebige Prozesse beendet werden!

This article is tagged:

• Android