Ich versuche, ein besseres Verständnis zu erlangen, damit ich die Auswirkungen potenzieller Interoperabilitätsprobleme auf die Zuverlässigkeit beim Erstellen einer Android-App/einem Android-Dienst einschätzen kann. Ich möchte herausfinden, wie die Prozesspriorität bestimmt wird. Die Unterschiede in der Priorität zwischen Diensten und Aktivitäten und ob der Scheduler ihre Priorität unterschiedlich behandelt. Grundsätzlich versuche ich zu verstehen, wie wahrscheinlich es ist, dass eine Aktivität oder ein Dienst von einem Schurkenprozess aus einer anderen Anwendung (oder sogar dem Linux-Kernel) ausgehungert wird.
Hat jemand gute Links, die Sie empfehlen könnten… Meine Suche hat noch nicht viel ergeben.
Danke!
Bearbeiten: Meine Sorge betrifft das Aufteilen/Scheduling der Prozessorzeit, nicht die Speicherressourcen (die Speicherressourcen sind in der Android-Dokumentation gut beschrieben.) Nochmals vielen Dank!
Benutzer370305
Die folgende Liste stellt die verschiedenen Arten von Prozessen in der Reihenfolge ihrer Wichtigkeit dar (der erste Prozess ist der wichtigste und wird zuletzt beendet):
Vordergrundprozess
Sichtbarer Prozess
Serviceprozess
Hintergrundprozess
Leervorgang
Notiz: Android stuft einen Prozess auf der höchsten Ebene ein, basierend auf der Bedeutung der derzeit im Prozess aktiven Komponenten. Wenn ein Prozess beispielsweise einen Dienst und eine sichtbare Aktivität hostet, wird der Prozess als sichtbarer Prozess und nicht als Dienstprozess eingestuft.
Die Reihenfolge, in der Prozesse beendet werden, um Ressourcen zurückzugewinnen, wird durch die Priorität der gehosteten Anwendungen bestimmt. Die Priorität einer Anwendung entspricht der Komponente mit der höchsten Priorität.
Wenn zwei Anwendungen die gleiche Priorität haben, wird der Prozess, der am längsten eine niedrigere Priorität hatte, zuerst beendet. Die Prozesspriorität wird auch durch Abhängigkeiten zwischen den Prozessen beeinflusst; wenn eine Anwendung von einem Dienst oder Inhaltsanbieter abhängig ist, der von einer zweiten Anwendung bereitgestellt wird, hat die sekundäre Anwendung eine mindestens so hohe Priorität wie die von ihr unterstützte Anwendung.
Alle Android-Anwendungen laufen weiter und bleiben im Speicher, bis das System seine Ressourcen für andere Anwendungen benötigt.
Es ist wichtig, Ihre Bewerbung richtig zu strukturieren, um sicherzustellen, dass ihre Priorität der Arbeit angemessen ist. Wenn Sie dies nicht tun, könnte Ihre Anwendung beendet werden, während sie sich mitten in etwas Wichtigem befindet. Die folgende Liste beschreibt jeden der in Abbildung gezeigten Anwendungsstatus und erklärt, wie der Status durch die Anwendungskomponenten bestimmt wird, aus denen er besteht:
Aktive Prozesse Aktive (Vordergrund-)Prozesse sind diejenigen, die Anwendungen hosten, deren Komponenten derzeit mit dem Benutzer interagieren. Dies sind die Prozesse, die Android versucht, reaktionsfähig zu bleiben, indem Ressourcen zurückgefordert werden. Es gibt im Allgemeinen nur sehr wenige dieser Prozesse, und sie werden nur als letztes Mittel beendet.
Aktive Prozesse umfassen:
1. Aktivitäten in einem „aktiven“ Zustand; das heißt, sie stehen im Vordergrund und reagieren auf Benutzerereignisse. Sie werden die Aktivitätszustände später in diesem Kapitel genauer untersuchen.
2.Aktivitäten, Dienste oder Broadcast-Empfänger, die derzeit einen onReceive-Ereignishandler ausführen.
3.Dienste, die einen onStart-, onCreate- oder onDestroy-Ereignishandler ausführen.
Sichtbare Prozesse Sichtbare, aber inaktive Prozesse sind diejenigen, die „sichtbare“ Aktivitäten hosten. Wie der Name schon sagt, sind sichtbare Aktivitäten sichtbar, aber sie befinden sich nicht im Vordergrund oder reagieren auf Benutzerereignisse. Dies geschieht, wenn eine Aktivität nur teilweise verdeckt ist (durch eine nicht bildschirmfüllende oder transparente Aktivität). Es gibt im Allgemeinen nur sehr wenige sichtbare Prozesse und sie werden nur unter extremen Umständen beendet, damit aktive Prozesse fortgesetzt werden können.
Gestartete Serviceprozesse Verarbeitet Hosting-Dienste, die gestartet wurden. Dienste unterstützen die laufende Verarbeitung, die ohne sichtbare Schnittstelle fortgesetzt werden sollte. Da Dienste nicht direkt mit dem Benutzer interagieren, erhalten sie eine etwas niedrigere Priorität als sichtbare Aktivitäten. Sie gelten weiterhin als Vordergrundprozesse und werden nicht beendet, es sei denn, Ressourcen werden für aktive oder sichtbare Prozesse benötigt.
Hintergrundprozesse Prozesse, die Aktivitäten hosten, die nicht sichtbar sind und für die keine Dienste gestartet wurden, gelten als Hintergrundprozesse. Im Allgemeinen wird es eine große Anzahl von Hintergrundprozessen geben, die Android unter Verwendung des Musters „Zuletzt gesehen-zuerst-getötet“ beendet, um Ressourcen für Vordergrundprozesse zu erhalten.
Leere Prozesse Um die Gesamtsystemleistung zu verbessern, behält Android häufig Anwendungen im Speicher, nachdem sie das Ende ihrer Lebensdauer erreicht haben. Android behält diesen Cache bei, um die Startzeit von Anwendungen beim Neustart zu verbessern. Diese Prozesse werden bei Bedarf routinemäßig abgetötet.
I think Android is basic Linux so, whatever scheduler works for Linux is same in Android.
Der Unterschied zwischen Android-Scheduler und Linux-Scheduler
Scheduler – 5 Dateien – Der Android-Kernel enthält auch geringfügige Änderungen am CPU-Prozess-Scheduler und an den Zeiterfassungsalgorithmen. Wir kennen die Geschichte dieser Änderungen nicht, und die Auswirkungen waren bei einer oberflächlichen Untersuchung nicht ersichtlich.
Prozesspräemption:
Wie bereits erwähnt, ist das Linux-Betriebssystem präventiv. Wenn ein Prozess in den TASK_RUNNING-Zustand eintritt, prüft der Kernel, ob seine Priorität höher ist als die des aktuell ausgeführten Prozesses. Wenn dies der Fall ist, wird der Scheduler aufgerufen, um einen neuen Prozess zum Ausführen auszuwählen (vermutlich der Prozess, der gerade lauffähig geworden ist). Wenn die Zeitscheibe eines Prozesses Null erreicht, wird sie außerdem vorzeitig beendet und der Scheduler wird aufgerufen, um einen neuen Prozess auszuwählen.
Die Planungsrichtlinie in Aktion
Stellen Sie sich ein System mit zwei ausführbaren Aufgaben vor: einem Texteditor und einem Video-Encoder. Der Texteditor ist E/A-gebunden, da er fast die ganze Zeit damit verbringt, auf Tastendrücke des Benutzers zu warten (egal wie schnell der Benutzer tippt, er ist nicht so schnell). Trotzdem erwartet der Benutzer, dass der Editor bei einem Tastendruck sofort reagiert. Umgekehrt ist der Video-Encoder prozessorgebunden. Abgesehen vom Lesen des Rohdatenstroms von der Festplatte und dem späteren Schreiben des resultierenden Videos verbringt der Encoder seine ganze Zeit damit, den Videocodec auf die Rohdaten anzuwenden. Es gibt keine starken zeitlichen Einschränkungen bei der Ausführung – ob die Ausführung jetzt oder in einer halben Sekunde gestartet wurde, konnte der Benutzer nicht erkennen. Natürlich, je früher es fertig ist, desto besser.
In diesem System gibt der Scheduler dem Texteditor eine höhere Priorität und eine größere Zeitscheibe als dem Videocodierer, da der Texteditor interaktiv ist. Der Texteditor hat viele Timeslices zur Verfügung. Da der Texteditor darüber hinaus eine höhere Priorität hat, kann er bei Bedarf den Video-Encoder vorwegnehmen. Dadurch wird sichergestellt, dass der Texteditor sofort auf Tastendrücke des Benutzers reagieren kann. Dies ist zu Lasten des Video-Encoders, aber da der Texteditor nur zeitweise läuft, kann der Video-Encoder die verbleibende Zeit monopolisieren. Dadurch wird die Leistung beider Anwendungen optimiert.
Danke für die Info … Ich habe diese Beschreibung in der Vergangenheit gelesen und sie ist eine großartige Beschreibung dafür, wie Android die Priorität in Bezug auf das Beenden eines Prozesses und das Zurückfordern der Ressourcen festlegt. Die große Information, die mir fehlt, betrifft die Prozessausführung … Zum Beispiel kann ein Hintergrundprozess, der sich dreht und eine große Menge an Verarbeitung verbraucht, verhungern oder einen Vordergrundprozess von der sichtbaren Aktivität beeinflussen. Ich gehe davon aus, dass die gleichen Regeln gelten würden, aber ich versuche, darauf eine definitivere Antwort zu erhalten. Danke noch einmal.
– Gregg Rivinius
28. Oktober ’11 um 17:19
@Chris Wenn Sie denken, dass ich etwas über das Kopieren und Einfügen gesagt habe (was Sie zu meiner Antwort kommentiert haben), liegen Sie falsch. In der Antwort wurde dieser Link bereits erwähnt. Ich habe nur versucht, es zu fokussieren. Aber ja, es ist nutzlos, da ich die Frage nicht richtig verstanden habe.. Danke!
– Benutzer577898
20. Mai ’12 um 5:36
Abgestimmt. Der gesamte Text wurde nur aus den Dokumenten kopiert. Verwenden Sie in Zukunft einfach einen Link zum Original.
– Johann
25. Juli ’13 um 14:43
Hacker
Android unterscheidet sich in dieser Hinsicht ein wenig von einem normalen Linux-System. Es gibt zwei Dinge, die Android verwendet, um die Planung zu beeinflussen: Prozess-/Thread-“Nice”-Ebene und Kontrollgruppen.
Die “nice”-Stufe des Prozesses beeinflusst die normale “faire” Planungspolitik von Linux; Threads mit einer höheren Niceness werden seltener ausgeführt als Threads mit einer geringeren Niceness. In der Situation, in der Sie einen Thread mit einer “Standard”-Priorität haben (wie in Process.THREAD_PRIORITY_DEFAULT) werden deutlich häufiger ausgeführt als solche mit Hintergrundpriorität (oder Process.THREAD_PRIORITY_BACKGROUND).
Theoretisch kann dies sicherstellen, dass die Vordergrund-/UI-Threads nicht wesentlich durch Hintergrundarbeit beeinträchtigt werden … in der Praxis reicht dies jedoch nicht aus. Überlegen Sie, ob Sie 10 Hintergrundthreads haben, die alle ausgeführt werden sollen, aber ein Vordergrundthread, der die Benutzeroberfläche steuert. Dies kann immer noch zu spürbaren Auswirkungen auf das Verhalten des Vordergrundthreads führen.
Um dies zu beheben, verwendet Android auch Linux-Cgroups auf einfache Weise, um eine strengere Planung im Vordergrund vs. im Hintergrund zu erstellen. Die Vordergrund-/Standard-Cgroup ermöglicht das normale Thread-Scheduling. Die Hintergrund-Cgroup legt jedoch nur einen kleinen Prozentsatz der verfügbaren CPU-Gesamtzeit fest alle Threads in dieser Kontrollgruppe. Wenn dieser Prozentsatz also 5 % beträgt und Sie 10 Hintergrundthreads haben, die alle ausgeführt werden möchten, und einen Vordergrundthread, können die 10 Hintergrundthreads zusammen nur höchstens 5 % der verfügbaren CPU-Zyklen aus dem Vordergrund beanspruchen. (Wenn kein Vordergrund-Thread ausgeführt werden möchte, können die Hintergrund-Threads natürlich alle verfügbaren CPU-Zyklen verwenden.)
Android verschiebt Threads implizit zwischen den Standard- und Hintergrund-Cgroups, wenn Sie seine öffentlichen APIs verwenden, um die Thread-Priorität festzulegen. Wenn Sie also die Priorität eines Threads auf setzen Process.THREAD_PRIORITY_BACKGROUND oder höher, werden Sie den Thread auch in die Hintergrund-Kontrollgruppe stellen. Stellen Sie es auf Process.THREAD_PRIORITY_DEFAULT und es wird in der Standard-Cgroup sein.
Aus diesem Grund können Sie durch Befolgen der normalen Konvention, Ihre Hintergrund-Worker-Threads in die Hintergrundpriorität zu setzen, sicherstellen, dass sie Ihren Vordergrund-UI-Thread nicht stören.
Darüber hinaus verschiebt Android alle Threads in einem Prozess in die Hintergrund-Cgroup für Prozesse, von denen es weiß, dass sie für den Benutzer nicht kritisch sind. Die Threads jedes Hintergrundprozesses oder Dienstprozesses werden in die Hintergrund-Überwachungsgruppe gestellt, unabhängig davon, ob einzelne Threads eine Vordergrundplanungspriorität angefordert haben.
Ja es ist möglich damit Ihr Prozess ausgehungert wird.
Android verwendet Linux 2.6 für sein niedriges Ressourcenmanagement. Linux 2.6 verwendet zufällig mehrstufige Feedback-Warteschlangen als seinen Planungsalgorithmus. Dies begünstigt E/A-gebundene Prozesse und kurze CPU-Burst-Prozesse (ideal für Telefone für Reaktionsfähigkeit/Interaktion). Dies bedeutet jedoch, dass CPU-intensive Prozesse und Prozesse mit niedriger Priorität Gefahr laufen, zu verhungern. Ich bin mir nicht sicher, ob Linux 2.6 die Priorität von wartenden Prozessen regelmäßig erhöht, damit sie schließlich bedient werden und so ein Hungern vermieden wird.
Realistischerweise sollten Sie sich jedoch keine Sorgen machen müssen, da Sie entweder die aktive Aktivität oder ein Dienst sind, die beide relativ hohe Prioritäten haben, wie die vorherige Antwort zeigt.
