Bei meiner Arbeit haben wir alle Android-Geräte, die verwendet werden, um Aufträge an uns zu senden. Es verwendet eine Web-App, auf die über jeden Webbrowser zugegriffen werden kann. Wenn ein neuer Auftrag eintrifft, werden wir mit einem akustischen Signal benachrichtigt. Aufgrund der Art und Weise, wie Android mit dem Speicher umgeht, "schläft" es den Webbrowser jedoch häufig (ich kenne die richtige Terminologie nicht). Wenn wir also einen neuen Job erhalten, werden wir nicht benachrichtigt, es sei denn, wir öffnen das Web manuell erneut Browser, um es "aufzuwecken".
Gibt es Problemumgehungen für dieses Problem?
Beifall
Vermutlich verwendet das Gerät WLAN, um auf das Internet zuzugreifen - es könnte einen Versuch wert sein, dies zu versuchen:
Auf diese Weise ist WLAN immer noch aktiv und läuft, wenn das Gerät in den Ruhezustand wechselt, und die Web-App sollte immer noch funktionieren und
Wenn ein neuer Auftrag eintrifft, werden wir mit einem akustischen Signal benachrichtigt
Die obige Antwort ist nicht die richtige Antwort, sondern aus den Kommentaren unten, dies ist definitiv diejenige, in der ich zitiere.
Möglicherweise wird der Ansatz zur Verwaltung der Jobs falsch durchgeführt , insbesondere im Zusammenhang mit Android - einer benutzerdefinierten App, die einen Dienst hat , der eine partielle Wakelock- Funktion verwendet , um Jobs zu "pingen", ein Ereignis an die App und die App zu senden wacht auf. Meiner Meinung nach ist ein Browser nicht das richtige Werkzeug für die Anforderungen in Ihrem Fall.
Kurz gesagt, es gibt nichts, was getan werden kann, um den Webbrowser "am Leben" zu halten, während das Gerät schläft, da Android hinter den Kulissen, wenn sich der Kernel nicht im Ruhezustand befindet, verfolgt, welche Apps ausgeführt werden und was davon abhängt auf Leistungs- und Speicherbeschränkungen, insbesondere im Fall einer Webbrowser-Seite (wenn sie viele Stile hat, je ausgefeilter die Seite ist, desto mehr Ressourcen werden als Ergebnis in Anspruch genommen, besonders wenn sie viel Javascript hinter sich hat die Seite) könnte dies die Aufgabe für den Kernel sein, sie abzuschießen und aus dem Speicher auszuwerfen, daher kein zuverlässiger Weg.
TL; DR: Eine geeignete Anwendung anstelle eines Webbrowsers löst das Problem des OP.
Off-Topic: Es gab einen Artikel in der Technologiesektion unter den BBC-Nachrichten in Bezug auf das mobile Surfen im Internet und wie es den Akku aufgrund der Art und Weise beeinflussen kann, wie Webseiten gestaltet sind, sondern sie wurden falsch für die mobile Plattform entwickelt. Zu viele Stile, zu viel Scripting, ganz zu schweigen von Flash, sie alle hatten negative Auswirkungen darauf, wie Android die Seite anzeigt/darstellt, was wiederum bedeutete, dass dafür viele CPU-Zyklen verbraucht wurden.
Die beste Option wäre, die Minfree-Parameter des Low-Memory-Killers zu optimieren.
Etwas Hintergrund:
Der Low Memory Killer ist die Hauptstütze der Android-Speicherverwaltung. Es ist ein eleganterer Ansatz als der Linux-Oomkiller und arbeitet proaktiv, um den freien Pool aufrechtzuerhalten, anstatt nur einzugreifen, wenn Sie keinen freien Speicher mehr haben. Es unterteilt Apps in mehrere Kategorien zum Töten, wenn der freie Speicherpool bestimmte Punkte unterschreitet. Sie sind im Allgemeinen in der folgenden Reihenfolge, vom ersten bis zum letzten:
EMPTY_APP – Dies sind Apps, die nichts tun oder darauf warten, etwas zu tun. Sie sitzen nur in Erinnerung herum.
CONTENT_PROVIDER – Dies sind Hintergrund-Apps, die Inhalt für aktive Apps sind (z. B. der Play Store verwendet eine, um regelmäßig nach Updates zu suchen. HTC Facebook Sync ist ein weiteres häufiges Beispiel).
HIDDEN_APP - Diese sitzen im Hintergrund, tun nichts, leben aber noch und warten möglicherweise auf etwas.
SECONDARY_SERVER – Ein Server, der im Hintergrund ausgeführt wird, um Dienste für eine aktuell ausgeführte App bereitzustellen.
VISIBLE_APP - Dies ist eine Anwendung, die sich im Hintergrund befindet, aber derzeit etwas tut.
FOREGROUND_APP - Dies ist, was derzeit läuft und auf dem Bildschirm angezeigt wird.
Wenn der freie Speicherpool unter eine bestimmte Menge fällt (z. B. 80 MB ist die Standardeinstellung auf meiner GS3), beginnt das System zuerst, alles zu löschen, was als leere App aufgeführt ist, bis der Pool wieder über dieser Linie liegt. Wenn nach dem Beenden aller leeren Apps der Speicher immer noch unter der nächsten Zeile liegt (z. B. 64 MB), beginnt er mit den Inhaltsanbietern und so weiter, bis schließlich nur die Vordergrund-App den gesamten Speicher belegt (On mein GS3, wenn alles außer der Vordergrund-App beendet wurde und immer noch weniger als 32 MB Speicher frei sind) und das System bedrohen, wird es schließlich beendet.
Um auf Ihre eigentliche Frage zurückzukommen, wir möchten diese Werte nach unten anpassen, damit der Killer später eingreift und den Browser hoffentlich nicht tötet, wenn Sie ihn immer noch öffnen möchten.
Mit der App MinFreeManager können Sie diese Werte anpassen. Alternativ können sie direkt dort bearbeitet werden, /sys/module/lowmemorykiller/parameters/minfreewo sich die Parameter in Seiten befinden (4 Kilobyte, also bedeutet ein Wert von 8192 32 MB als ((8192 * 4)/1024 = 32 MB) und in umgekehrter Reihenfolge zu dem aufgelistet werden, was ich oben aufgeführt habe. Beides davon benötigen Sie Root. Wenn Sie kein Root haben, können wir im Grunde nichts tun, um Ihnen zu helfen.
In Ihrem Fall müssen wir wahrscheinlich den Parameter HIDDEN_APP (4. Element in der minfree-Datei) ändern. Beispielsweise beträgt dieser Parameter auf meiner GS3 standardmäßig 56 MB. Die Halbierung auf 28 Millionen oder die Verwendung der milden Voreinstellung in MinFreeManager wäre ein guter Ausgangspunkt für die Optimierung.
Roxan
t0mm13b
Roxan