Tl; dr
Mit root können Sie oom_adjWerte anpassen , um zu verhindern, dass Apps beendet werden. Alternativ können Sie die Ziel-App zwingen, im Speicher zu bleiben, indem Sie sie "sperren" oder einige verwandte Einstellungen ändern, die für das Beenden von Apps bei geringem Arbeitsspeicher verantwortlich sind.
Hintergrund: Android RAM Management
Android verwendet eine andere Art der Handhabung von Prozessen. Anstatt jeden Prozess nach Beendigung seiner Aktivität zu beenden, werden die Prozesse so lange beibehalten, bis das System mehr Speicher benötigt. Die Idee ist, die Geschwindigkeit zu verbessern, wenn Sie diese Aktivität erneut starten. Aber wie / wann beendet Android einen Prozess, wenn es mehr Speicher benötigt und welcher Prozess zuerst beendet werden muss?
Dies wird vom LMK-Treiber (Low Memory Killer) von Android verwaltet. Möglicherweise wissen Sie bereits, dass jeder App / jedem Prozess in Android ein oom_adjWert zugewiesen
ist, der die Wahrscheinlichkeit angibt, dass er bei einer OOM-Situation (Out of Memory) beendet wird. Je höher der Wert, desto wahrscheinlicher ist es, dass er getötet wird. Gültiger Bereich ist -17bis +15. (Wenn in der -17Reichweite bedeutet, dass es nicht getötet wird). Demnach gibt es sechs Gruppen (OOM-Gruppen), in die Apps / Prozesse eingeteilt sind:
- Vordergrund App
- Sichtbare App
- Sekundärserver
- Versteckte App
- Inhalt Anbieter
- Leere App
Grundsätzlich könnten diese beschrieben werden als:
FOREGROUND_APP: Dies ist der Prozess, bei dem die aktuelle Vordergrund-App ausgeführt wird. Wir wollen es wirklich lieber nicht töten!
VISIBLE_APP: Dies ist ein Prozess, bei dem nur Aktivitäten gehostet werden, die für den Benutzer sichtbar sind. Wir möchten daher, dass sie nicht verschwinden.
SECONDARY_SERVER: Dies ist ein Prozess, der einen sekundären Server enthält. Das Beenden dieses Servers hat für den Benutzer keine großen Auswirkungen.
HIDDEN_APP: Dies ist ein Prozess, bei dem nur Aktivitäten gehostet werden, die nicht sichtbar sind, sodass er ohne Unterbrechung beendet werden kann.
CONTENT_PROVIDER: Dies ist ein Prozess mit einem Inhaltsanbieter, an den keine Clients angeschlossen sind. Wenn es Kunden hätte, wäre seine Anpassung diejenige mit der höchsten Priorität dieser Prozesse.
EMPTY_APP: Dies ist ein Prozess, in dem derzeit nichts ausgeführt wird. Auf jeden Fall der erste, der geht.
Diese Gruppen werden durch oom_adjWertelimits definiert , und Apps fallen entsprechend oom_adjdem dieser bestimmten App zugewiesenen Wert in eine dieser Gruppen . "Vordergrund-Apps" haben normalerweise einen oom_adjWert von 0oder weniger (daher sind sie am wenigsten tötbar, dh mit hoher Priorität).
"Leere Apps" haben eine höhere oom_adj(sie werden vorzeitig beendet; dh niedrige Priorität). Außerdem oom_adjändert sich der Wert je nach Status der Benutzer-App. 0Dies ist der Fall , wenn die App im Vordergrund aktiv ist und einen höheren Wert erhält, wenn die App in den Hintergrund tritt.
Warum unterscheiden sich ihre "Tötbarkeit"? Apps, die zu diesen verschiedenen Gruppen gehören (die unterschiedliche Gruppen haben oom_adj's), werden auf verschiedenen Ebenen des freien Arbeitsspeichers getötet. Diese auslösenden RAM-Grenzen werden durch die LMK-Minfree-Werte definiert. Die obigen 6 Kategorien entsprechen 6 RAM-Grenzwerten, die im LMK-Minifree festgelegt sind. Beispiel: Stock Android 4.3 in meinem Gerät kommt mit den minfree Werten von 48,60,72,84,96,120. (diese sind in MB).
Praktisch bedeutet dies, dass leere Apps getötet werden, wenn der RAM-Wert unter 120 MB sinkt, Inhaltsanbieter, wenn der RAM-Wert unter 96 MB sinkt, versteckte Apps, wenn der Speicherwert unter 84 MB liegt usw. (Möglicherweise stellen Sie fest, dass dieser letzte Wert (48 MB) nicht wünschenswert ist, wenn speicherintensive Apps wie schwere Spiele verwendet werden.)
NB:
Im neueren Kernel oom_ score _adjwird anstelle des alten verwendet oom_adj. (Der gültige Bereich für oom_score_adj liegt zwischen -1000 und 1000). Wird oom_adjaber auch aus Gründen der Kompatibilität beibehalten.
Es wird gesagt, dass es viele OOM-Prozesskategorien gibt, denen von den verschiedenen oom_adjPrioritäten zugewiesen werden ActivityManagerService, aber letztendlich würden alle unter den oben genannten sechs Slots / Gruppen (gemäß oom_limits) berücksichtigt, um durch die minkfreien LMK-Trigger getötet zu werden. Daher sind diese sechs für normale Benutzer wichtig.
- Mit dieser Memory Manager-App können wir die minfree-Werte überprüfen (auch ändern) und die OOM-Gruppierungen von Apps / Prozessen einfach anzeigen.
Nicht jedes Gerät hat dieselbe OOM-Konfiguration.
Verbesserung der RAM-Verwaltung
Heutzutage gibt es eine benutzerfreundliche Implementierung des RAM-Verwaltungsmechanismus mit Benutzeroberfläche in den Systemeinstellungen (z. B. App-Optimierung in den Batterieeinstellungen, geschützte Apps in einigen ROMs, z. B. Huawei EMUI usw.), die den gleichen Effekt wie oben beschrieben haben können:
Trotzdem können wir jetzt untersuchen, wie RAM verwendet werden kann, ohne Vordergrundanwendungen zu oft zu beenden. Die Zielbereiche umfassen:
1. Anpassen der Minifree-Werte an die eigenen Bedürfnisse
2. Sperren von Apps im Speicher, um zu verhindern, dass sie getötet werden
3.Die versteckte App-Grenze von Android überschreiben
Minifreie Werte anpassen
Sie können die minfree-Werte mit dem Speichermanager ändern und auf Anwenden tippen. (Zusätzlich gibt es eine Option "Beim Booten anwenden" und ein Häkchen, um die Einstellungen für alle Boots beizubehalten.) Dies können mehrere Apps erreichen, z. B. Memory Manager , Minfree Manager usw.
Alternativ können Sie terminal / adb mithilfe von Seiten verwenden:
#!/system/bin/sh echo “values” > /sys/module
Sperren von Apps, um im Speicher zu bleiben (damit sie resident werden)
a) Verwenden der App-Einstellungen (Xposed)
- Eine einfache Methode ist das Xposed-Modul, App-Einstellungen (Sie müssen das Xposed-Framework installiert haben).
- Laden Sie nach der Installation des Frameworks das Modul "App-Einstellungen" über das Xposed-Installationsprogramm herunter.
- Öffnen Sie die App-Einstellungen und lassen Sie die Anwendungen laden. Wählen Sie die Ziel-App aus (in diesem Fall Firefox-Browser ).
- Aktivieren Sie auf der Einstellungsseite das Umschalten und Aktivieren des Bearbeitungsmodus, aktivieren Sie die Option "Resident" und speichern Sie. ( Wenn Apps resident bleiben, bleibt der Speicher der Apps erhalten, ohne dass sie getötet werden. Es wird empfohlen, die Schaltfläche zum Beenden in der Zielanwendung zu verwenden, wenn sie nicht mehr benötigt wird. Andernfalls wird der Speicher anderer Apps entzogen.)
b) Verwenden von Memory Locker
Eine weitere Implementierung dieses Konzepts besteht darin, die Zielanwendung im Speicher zu sperren, indem die Systemdateien für die Einstellung oom_adjaller laufenden Prozesse gesteuert werden.
So funktioniert die Anwendung:
Memory Locker steuert Dateien im Verzeichnis / data sowie Systemdateien im Stammverzeichnis, um oom_adj für die Ausführung von Prozessen festzulegen.
Alle gesperrten Anwendungen werden nach jedem Neustart automatisch gesperrt. Apps werden als heruntergeladene / System-Apps klassifiziert, um ausgewählte Ziel-Apps zu entsperren und auf die Sperre auf der rechten Seite zu klicken. (Sie können optional die oom_adj
Priorität festlegen )
Überschreiben des versteckten App-Limits
Zusätzlich zum Mechanismus zum Beenden des Arbeitsspeichers gibt es einen weiteren Parameter, der das Beenden versteckter und leerer Apps steuert. Apps werden getötet, wenn sie bestimmte Grenzen überschreiten.
Es gibt eine build.prop-Einstellung, die dies steuern kann (Standard ist normalerweise eine niedrige Zahl unter 25, und durch Ändern dieser Einstellung kann dieser Wert auf einen viel größeren Wert wie 80 erhöht werden).
Fügen Sie diese Zeile zur Datei build.prop in / system hinzu und lassen Sie eine weitere leere Zeile darunter (stellen Sie sicher, dass Sie zuerst eine Sicherungskopie erstellen).
ro.sys.fw.bg_apps_limit=80
Referenzen und Credits
- Android RAM Management ( Sonderpunkte : mrhnet )
- Memory Locker
- Xposed - Allgemeine Informationen, Versionen und Änderungsprotokoll