[Vergleich] 'SWAP-Space' vs Android-Konzept des 'Android-Life-Cycles'

Es wird oft die Frage gestellt, ob es Sinn macht, bei Android einen 'SWAP-Space' einzurichten.

Die Frage, ob 'SWAP-Space' bei Android etwas bringt, ist leider nicht ganz eindeutig zu beantworten.

Ich möchte daher einfach mal die Fakten beleuchten, eine Meinung bilden, muss sich jeder selbst.

Um das ganze zu verdeutlichen, will ich es mal etwas näher beleuchten. Dazu muss ich mal ein paar Arten von Speicher von ein ander abgrenzen:

• Arbeitsspeicher (RAM): Das ist der Speicher, auf den die CPU direkt zugreifen kann. In diesem Speicher werden die auszuführenden Anwendungen und Prozesse reingeladen. Programm-Code kann nur dort ausgeführt werden. Dieser Speicher ist mit Abstand am schnellsten. Allerdings gehen die Inhalte des Arbeitsspeichers beim Ausschalten und auch beim Neustart verloren. Installierte Anwendungen landen erst dann im Arbeitsspeicher, wenn sie gestartet werden.
  
• Dauerspeicher (Festplatte, internen Flash-Speicher, externe SD-Karte): Das ist der Speicher, der in wesentlich größerer Menge vorhanden ist, auf dem Anwendungen und Daten gespeichert werden, und der über ein Ausschalten oder einen Neustart hinaus seinen Inhalt behält. Hierbei möchte ich noch die drei oben in Klammern aufgezählten Arten von einander abgrenzen:
  • Festplatte sind ein besonders großer, mit Mechanischen Teilen aufgebaute Art des Dauerspeichers.
  • Internen Flaschspeicher (am ehesten mit einer SSD zu verglichen) ist ein mechanik-freiere Dauerspeicher der auf dem Flash-Memory Prinzip basiert, jedoch sehr schnell ist aber da er fest in das Gerät eingebaut ist, nicht in besonders großer Menge vorhanden ist.
  • Externe SD-Karte ist ein auf dem Flash-Speicher Prinzip basierender Dauerspeicher, der jedoch eher auf größe als auf Geschwindigkeit optimiert ist. Im allgemeinen ist der Interne Speicher meist deutlich schneller als externe SD-Karten, auch wenn diese Class 10 sind.

Über 'SWAP-Space':

Prinzipiel ist 'SWAP-Space' ein Konzept, das es bei vielen Betriebssystemen gibt. Prinzipiell ist der 'SWAP-Space' ein Stück eines Dauerspeichers (bei Android entweder in dem internen Flashspeicher oder auf der externen SD-Karte).

Wenn das Betriebssystem feststellt, dass eine bereits gestartete Anwendung oder ein Hintergrund-Prozess gerade nicht gebraucht wird, wird der 'Arbeitsspeicher-Inhalt (RAM)' der Anwendung oder des Hintergrund-Prozesses in den 'SWAP-Space' ausgelagert. Wenn die entsprechende Anwendung jedoch wieder aktiv werden soll, muss das Betriebssystem erst die Speicher-Inhalte der Anwendung wieder aus dem 'SWAP-Space' in den Arbeitsspeicher zurück transferieren. Eine Anwendung kann nicht direkt im 'SWAP-Space' ausgeführt werden! Gegebenenfalls muss dazu erst der Inhalt einer anderen Anwendung aus dem Arbeitsspeicher in den 'SWAP-Space' transferiert werden, bevor im Arbeitsspeicher genug freier Platz vorhanden ist, um etwas aus dem 'SWAP-Speicher' in den Arbeitsspeicher transferieren zu können.

Über das Android-Konzept:

Bei der Entwicklung von Android hat man sich für ein alternatives Konzept entschieden. Hier war ursprünglich nicht vorgesehen, mit 'SWAP-Space' zu arbeiten, sondern man hat das Prinzip des 'Android-Life-Cycles' eingeführt. Hierbei muss eine Android-Anwendung entsprechend entwickelt sein, um nach diesem Konzept zu arbeiten. Aber das ist kein Problem, jede Android-APP ist entsprechend aufgebaut, sonst könnte sie nicht als App laufen, d.h. jede Android-APP kann mit diesem Prinzip umgehen!

Bei dem Android-Life-Cycle-Konzept wird, wenn festgestellt wird, das wenig Speicher vorhanden ist, eine Anwendung, die lange nicht mehr im 'Vordergrund' war, in der Form aus dem Speicher genommen, dass man die App selbst beauftragt, sie möge alle Informationen, die sie benötigt, um ihren momentanen Zustand wieder herzustellen, wegspeichern. Diese Informationen nennt man den 'savedInstanceState'. Dann kann die Anwendung beendet werden, und wenn die Anwendung wieder in den Vordergrund geholt wird, wird sie neu gestartet und bekommt den 'savedInstanceState' wieder vorgelegt, so dass sie wieder exakt in dem Zustand, in dem sie war, wieder dem Benutzer präsentiert wird. Allerdings muss die App aus diesen Daten erst wieder den Inhalt ihres Speichers erneut aufbauen. (Manche Apps tun das speichern ihres Zustandes nur unvollständig, dann bemerkt man, dass sie, wenn sie lange im Hintergrund waren, nicht exakt im selben Zustand in den Vordergrund kommen. Beispielsweise könnte eine lange Liste oder Text nicht genau in der Position gescrollt sein, in dem man die Anwendung in den Hintergrund gelegt hat.)

Welches Konzept (mit wenig Arbeitsspeicher umzugehen) jetzt das bessere ist, kann man schwer sagen. Beide Konzepte haben Vorteile und Nachteile. Der Vorteil des einen, ist meist der Nachteil des anderen Konzeptes:

Vorteile des Android-Life-Cycles:

• Es müssen im allgemeinen viel weniger Daten als der 'Gesamte Speicher-Inhalt' in den 'savedInstanceState' gespeichert werden. Das macht das Lesen und Schreiben des 'savedInstanceStates' schneller.
• Der 'savedInstanceState wird im allgemeinen in dem Internen Flashspeicher gespeichert, der i.A. schneller als die externe SD-Karte ist, aber auch meist kleiner. Aber die deutlich geringeren Datenmengen des 'savedInstanceStates' können dort problemlos abgelegt werden.

Vorteile des 'SWAP-Space':

• Die Daten im 'SWAP-Space' müssen nicht erst bearbeitet werden, um daraus den Zustand einer App zu erstellen. Wird ein Speicherbereich aus dem 'SWAP-Space' in den Hauptspeicher transferiert, ist die App sofort arbeits-bereit, sie muss nicht erst ihren Zustand aus einem 'savedInstanceState' wieder herstellen.
• Auch Hintergrund-Prozesse können mit 'SWAP-Space' ausgelagert werden und später wieder in ihrem Ursprungszustand reaktiviert werden.
• Bei der Entwicklung muss der Entwickler nichts beachten, daher ist der 'SWAP-Space' bei (fast) allen Betriebssystemen verwendbar.

Hey,

danke für die kurze Erläuterung. Das mit dem savedInstanceState kannte ich so nicht, mir war nie klar wie Android das mit gekillten Anwendungen macht.

Zwei Sachen interessieren micht noch:
Was bedeutet die "Swappiness" als Setting? Meist kann man die ja von 0 - 100 Einstellen?!

Außerdem, nur die Frage ob ich das richtig einordne. Der Arbeitsspeicher ist belegt, der LMK stellt fest das er für eine neue Anwendung Platz braucht. Erst dann wird in den Swap-Speicher bzw. nach dem Android-Life-Cycle-Konzept eine vorhandene App (teilw.) verschoben? Nicht schon vorher?

Beste Grüße

Hallo Siegfried,

Deine Nachfrage bezieht sich auf Mechanismen, die eine Regulierung der 'SWAP'-Nutzung bei Android betreffen.

Meine bisherigen Ausführungen haben diesen Teil noch nicht mit die Erörterungen gezogen, da sich meine Kenntnisse einerseits aus Linux-Kenntissen und aus Android Software-Entwicklung herleiten. Zur Android-Spezifischen 'SWAP'-Lösung kann ich noch nichts sagen, da ich mich erst noch in dieses Thema einarbeiten muss Das werde ich jetzt natürlich tun, aber es benötigt etwas Zeit.

Daher erfolgt eine Antwort erst in ein paar Tagen, ich bitte um Verständnis, es ist aber bestimmt besser, ich antworte später fundiert als sofort mit Halbwissen.

Hallo,

mach dir wegen mir nicht extra die Mühe
Interessant ist das für mich zwar schon, aber mehr in der Theorie. Weder nutze ich derzeit eine SWAP Partition, noch bin ich in der Lage zu programmieren. Leider

Mir fällt auch gerade auf, dass ich die "swappiness" vom Z-Ram (Arbeitsspeicherkomprimierung) kenne, den ich in der tat mal genutzt habe. Aktuell bekomme ich es nicht hin, da es für mein MotoX keinen entsprechenden Kernel gibt. Mein "Kernel Adiutor" kann das zwar, aber da schmiert dann mein Gerät ab

Korrektur:

u.k-f schrieb:

...Deine Nachfrage bezieht sich auf Mechanismen, die eine Regulierung der 'SWAP'-Nutzung bei Android betreffen....

Zum Vergrößern anklicken....

stimmt gar nicht!

Swappiness ist ein Steuer-Parameter aus dem Linux-Kernel (und somit auch dem Android-Kernel). (Quelle: Der Kernel-Parameter "swappiness")

Damit wird gesteuert, wann der Linux-Kernel beginnt, Daten in den 'SWAP-Space' auszulagern. Mögliche Werte liegen zwischen 0 (kein 'Swappen') und 100 (viel 'Swappen').

Letztlich kann man damit aber indirekt das Zusammenspiel von 'Swap' und den Android-OOM-Mechanismen (OOM:= OutOfMemory) beeinflussen.

Wenn der freie Speicher knapp wird, werden beide Mechanismen versuchen, auf ihre Weise einzugreifen. Ist die 'Swappiniss' auf einem hohen Wert eingestellt, wird zuerst der Kernel versuchen, das Problem durch 'Swappen' zu lösen, dann kommt Android nicht zum Zuge.

Stellt man den Wert nieder ein, werde die Android-OOM-Mechanismen eingreifen, bevor der Kernel beginnt zu 'Swappen'.

Wie sich das bei mittleren Werten genau verhält, kann ich leider nicht sagen!
[
Nachtrag:

Da ich eigentlich eine vollständige Abhandlung bieten wollte, ist es schon im Rahmen meines eigenen Anspruchs sinnvoll, dass ich noch was nachliefere.

S13gfried schrieb:

...Mir fällt auch gerade auf, dass ich die "swappiness" vom Z-Ram (Arbeitsspeicherkomprimierung) kenne...

Zum Vergrößern anklicken....

Das Thema ZRam sollte ich in die obigen Ausführungen auch noch mit aufnehmen.

ZRam ist ein interessantes Mittelding: Eine Zip-komprimierte RAMDisk, in die der Kernel als 'SWAP-Space' nutzt. Schneller als eine Flash-Disk, aber etwas langsamer als reiner RAM, da zum (de-)komprimieren Rechenleistung verbraucht wird.

Ich werde das alles in den Opener mit aufnehmen.

Ah ok. Also ist der ZRam auch ein Swap-Space, nur halt im RAM. Meistens macht man auch nicht den ganzen Ram als ZRAM, sondern nur einen Teil. Würde also bedeuten, das er bei hohem swappiness recht früh den unkomprimierten RAM Bereich in den komprimierten ZRam Bereich schiebt.
Somit läuft man ja auch nicht Gefahr, das der LMK oder OOM Mechanismus (zu) früh greifen .

Auf meinem S3 mit 1Gb Ram habe ich mit einem hohen ZRAM Space viel rausgeholt, Multitasking war besser möglich. Ob ich das mit meinen 2GB noch notwendig ist sei dahingestellt, ich merke aber, das es was bringen köööönnte. Zumal die Anwendungen ja nicht kleiner werden...

Gerade wenn ich offline Navi an habe, Dashcam und vlt. noch Blitzerapp (+ normale Dienste im Hintergrund) merke ich, dass der LMK da schon manchmal beim switchen offenbar was gekillt hat. Mein Navigon verträgt das killen oder das savedInstanceState mal definitiv nicht gut.

Aber das schweift etwas vom Thema ab. Wobei der ZRAM es ja doch noch irgendwie im Kern trifft.

Muss die SWAP Partition auch vom Kernel gesteuert werden? Also gibt es eine Chance nur mit Root diesen einzurichten? würde ich direkt mal probieren....

Theoretisch bestünde die Möglichkeit, dass der Hersteller tatsächlich einen Kernel ohne 'Swap-Support' gebaut hat, aber das ist eher unwahrscheinlich (Könnte man in den 'Kernel-Build-Einstellungen' machen, ist aber absolut unüblich).

Insofern sollte man den 'SWAP-Support' (bei den meisten Geräten) mit reinen 'Root-Tools' einstellen können.