Übersicht, wie Aktivitäten vom System getötet werden

Question

Kann jemand einen kurzen Überblick über die Fälle geben, wann und wie eine Aktivität durch die Laufzeit beendet wird? Ich würde gerne den Unterschied zwischen dem angehaltenen und dem gestoppten Zustand kennen. Was könnte das System dazu zwingen, eine pausierte Aktivität genau so zu löschen (low memory), als wäre sie gestoppt?

Ich denke, wenn eine Aktivität wegen eines eingehenden Telefonanrufs pausiert wird (was plötzlich eine geringe Speichersituation verursacht), bevorzugt das System einfach, Ressourcen von gestoppten Aktivitäten freizugeben. Aber wie ist das gemacht? Wann fragt das System die Aktivität "freundlich" ab, indem es finish() aufruft und wann nicht? Wann wird onDestroy() noch aufgerufen?

Answer 1

Das meiste von dem, was Sie gefragt haben, ist ziemlich gut in der Dokumentation beschrieben, aber ich denke, ich kann ein paar Dinge klären.

Ich würde gerne den Unterschied zwischen dem angehaltenen und gestoppten Zustand wissen.

Sicht. Die beiden Zustände sind unterschiedlich, da eine pausierte Aktivität nur teilweise durch eine andere Aktivität verdeckt werden kann, z. B. eine, auf die das Thema Dialog angewendet wurde. Dies erfordert, dass alle Ressourcen beibehalten werden, um den visuellen Zustand zu erhalten. Gestoppte Aktivitäten können diese Ressourcen abwerfen, die den Unterschied zwischen der zerstörten Aktivität oder der Erhaltung der Ressourcen ausmachen könnten, wenn die Ressourcen knapp sind.

Ich denke ... das System einfach zieht Ressourcen von gestoppt Aktivitäten zu veröffentlichen. Aber wie ist das gemacht?

Es muss. Gestoppte Aktivitäten sind vollständig unsichtbar, was sie zu besseren Kandidaten für das Töten macht als solche, die noch etwas zu dem beitragen, was der Benutzer sieht. Ich habe noch nie gesehen, dass Android eine unterdrückte - aber teilweise sichtbare - Aktivität aus einem unter einem wieder herausgezogen hat, aber ich vermute, dass es unter den richtigen Umständen passieren könnte. Das System kennt den Status jeder Aktivität, weil sie dorthin geleitet wird.

Wann wird das System „bitten“, um die Aktivität von Finish() aufrufen und wenn nicht, und wenn nicht onDestroy() noch genannt werden?

Das System wird ordentlich Zerstörung tun, wenn er kann, aber die API nur Garantien, dass eine Tätigkeit immer onPause() und onSaveInstanceState() sehen.

ETA: Die genauen Gründe, warum Aktivitäten aus dem Stapel entfernt werden, befinden sich in der Quelle. Sie sollten sich nicht darauf verlassen, dass diese Gründe universelle Wahrheit sind, da es möglicherweise eine zukünftige Version von Android gibt, die ihre Entscheidungen anders trifft.

Answer 2

Par für den Kurs, ich sehe! Ich sehe wertvolle Informationen, vermischt mit teuren Fehlinformationen. Nein, die Online-Dokumente spezifizieren NICHT alle genau, unter welchen Umständen der Prozess beendet wird. Dies ist beabsichtigt, da es ohne vorherige Ankündigung geändert werden kann. Sicher, der häufigste Grund für den Aufruf von onDestroy() ist, dass das System nicht mehr genügend Arbeitsspeicher hat, was bei neueren Telefonen weniger üblich ist (da sie so viel Speicher haben). Aber es gibt keine Garantie dafür, dass dies der einzige Grund dafür ist, dass es aufgerufen wird.

Aber der "Vertrag" zwischen Android und den Entwicklern ist, dass, wenn Sie die Regeln befolgen, die erforderlichen Lifecycle-Callbacks implementieren, wenn sie benötigt werden, dann wird es funktionieren, und Sie müssen nicht genau wissen, unter welchen Umständen onStop(), onSaveInstanceState() und onDestroy() werden aufgerufen.

Jetzt im Gegensatz zu Google, werde ich zugeben, dass der Wortlaut des Vertrags ist in einigen Punkten vage. Dies liegt daran, dass sie unter anderen, weniger wichtigen Gründen Begriffe verwenden, die eine branchenübliche Bedeutung haben, wie "Vordergrund", aber sie verwenden sie in leicht veränderten Sinnen. Und die Veränderung wird entweder nie erklärt oder nur an dunklen Orten erklärt. Es hilft auch nicht, dass das Diagramm "die Pfade zeigt, die eine Aktivität zwischen Zuständen einnehmen kann", aber nicht zeigt, dass onDestroy() oft aufgerufen werden kann, auch wenn der Übergang von "Angenommen" zu "Angehalten" umgangen wird. Der Text beschreibt diese Möglichkeit jedoch eindeutig.

Aus diesem Grund ist das Lesen des Application Lifecycle-Abschnitts von "Application Fundamentals" leider nicht genug. Stattdessen muss man auch das Javadoc für jeden der Callbacks unter dem für Activity lesen, sowie den Abschnitt "Application Fundamentals" zu Processes.

Danach ist es enorm hilfreich, Log.d-Anweisungen in jedem der Callbacks zu platzieren und die Logcat-Ausgabe zu beobachten, während Sie Ihre Anwendung durch den Lebenszyklus durchlaufen. Aber selbst dann sollten Sie sich nicht darauf verlassen, dass Lebenszyklus-Ereignisse in der Reihenfolge auftreten, die Sie in logcat sehen, es sei denn, Sie finden eine Begründung dafür in einer der oben genannten Online-Dokumente.