Freigeben über

Universelle Windows-Plattform -App-Lebenszyklus (UWP)

  • Artikel

In diesem Thema wird der Lebenszyklus einer Universelle Windows-Plattform-App (UWP) ab dem Zeitpunkt des Startes beschrieben, bis sie geschlossen wird.

Ein bisschen Geschichte

Vor Windows 8 hatten Apps einen einfachen Lebenszyklus. Win32- und .NET-Apps werden entweder ausgeführt oder nicht ausgeführt. Wenn ein Benutzer sie minimiert oder davon abweicht, wird er weiterhin ausgeführt. Dies war gut, bis tragbare Geräte und Energieverwaltung immer wichtiger wurden.

Windows 8 hat ein neues Anwendungsmodell mit UWP-Apps eingeführt. Auf hoher Ebene wurde ein neuer angehaltener Zustand hinzugefügt. Eine UWP-App wird kurz nach dem Minimieren oder Wechseln zu einer anderen App angehalten. Dies bedeutet, dass die Threads der App beendet werden und die App im Arbeitsspeicher verbleibt, es sei denn, das Betriebssystem muss Ressourcen freigeben. Wenn der Benutzer wieder zur App wechselt, kann er schnell in einen ausgeführten Zustand wiederhergestellt werden.

Es gibt verschiedene Möglichkeiten für Apps, die weiterhin ausgeführt werden müssen, wenn sie sich im Hintergrund befinden, z. B. Hintergrundaufgaben, erweiterte Ausführung und ausgeführte Aktivitäten (z. B. die BackgroundMediaEnabled-Funktion, mit der eine App weiterhin Medien im Hintergrund wiedergeben kann). Darüber hinaus können Hintergrundübertragungsvorgänge fortgesetzt werden, auch wenn Ihre App angehalten oder sogar beendet wird. Weitere Informationen finden Sie unter "Herunterladen einer Datei".

Standardmäßig werden Apps, die sich nicht im Vordergrund befinden, angehalten. Dies führt zu Energieeinsparungen und weiteren Ressourcen, die für die App zurzeit im Vordergrund verfügbar sind.

Der angehaltene Zustand fügt neue Anforderungen für Sie als Entwickler hinzu, da das Betriebssystem entscheiden kann, eine angehaltene App zu beenden, um Ressourcen freizugeben. Die beendete App wird weiterhin in der Taskleiste angezeigt. Wenn der Benutzer darauf klickt, muss die App den Zustand wiederherstellen, in dem sie sich befand, bevor sie beendet wurde, da dem Benutzer nicht bekannt ist, dass das System die App geschlossen hat. Sie werden denken, dass es im Hintergrund gewartet hat, während sie andere Dinge gemacht haben und erwarten, dass es sich in demselben Zustand befindet, in dem es war, als sie es verlassen haben. In diesem Thema werden wir uns ansehen, wie dies erreicht wird.

Windows 10, Version 1607, führte zwei weitere App-Modellzustände ein: "Im Vordergrund ausgeführt" und "Im Hintergrund ausgeführt". Wir werden diese zusätzlichen Zustände in den folgenden Abschnitten betrachten.

App-Ausführungsstatus

Diese Abbildung stellt die möglichen App-Modellzustände ab Windows 10, Version 1607, dar. Sehen wir uns den typischen Lebenszyklus einer UWP-App an.

Zustandsdiagramm mit Übergängen zwischen App-Ausführungszuständen

Apps geben die Ausführung im Hintergrundzustand ein, wenn sie gestartet oder aktiviert werden. Wenn die App aufgrund eines Vordergrund-App-Starts in den Vordergrund verschoben werden muss, ruft die App das LeavingBackground-Ereignis ab.

Obwohl "gestartet" und "aktiviert" wie ähnliche Begriffe aussehen können, beziehen sie sich auf unterschiedliche Arten, wie das Betriebssystem Ihre App starten kann. Sehen wir uns zunächst das Starten einer App an.

App-Start

Die OnLaunched-Methode wird aufgerufen, wenn eine App gestartet wird. Es wird ein LaunchActivatedEventArgs-Parameter übergeben, der unter anderem die an die App übergebenen Argumente, den Bezeichner der Kachel, die die App gestartet hat, und den vorherigen Zustand der App bereitstellt.

Rufen Sie den vorherigen Zustand Ihrer App aus LaunchActivatedEventArgs.PreviousExecutionState ab, der einen ApplicationExecutionState zurückgibt. Ihre Werte und die geeigneten Maßnahmen, die aufgrund dieses Zustands zu ergreifen sind, lauten wie folgt:

ApplicationExecutionState Erklärung Auszuführende Aktion
NichtAktiv Eine App kann sich in diesem Zustand befinden, da sie seit dem letzten Neustart des Benutzers oder der Anmeldung nicht gestartet wurde. Sie kann sich auch in diesem Zustand befinden, wenn sie ausgeführt wurde, aber dann abgestürzt ist, oder weil der Benutzer ihn zuvor geschlossen hat. Initialisieren Sie die App so, als ob sie zum ersten Mal in der aktuellen Benutzersitzung ausgeführt wird.
Suspendiert Der Benutzer hat ihre App entweder minimiert oder gewechselt und nicht innerhalb weniger Sekunden wieder dorthin gewechselt. Wenn die App angehalten wurde, blieb der Zustand im Arbeitsspeicher. Sie müssen nur alle Dateihandles oder andere Ressourcen, die Sie beim Anhalten der App freigegeben haben, erneut abrufen.
Beendet Die App wurde zuvor angehalten, wurde aber irgendwann heruntergefahren, da das System Speicher wieder freigeben musste. Stellen Sie den Zustand wieder her, in dem sich die App befand, als der Benutzer davon gewechselt hat.
ClosedByUser Der Benutzer hat die App mit der Schaltfläche "System schließen" oder mit ALT+F4 geschlossen. Wenn der Benutzer die App schließt, wird sie zuerst angehalten und dann beendet. Da die App im Wesentlichen die gleichen Schritte durchlaufen hat, die zum Zustand "Terminated" führen, behandeln Sie dies auf die gleiche Weise wie den Zustand "Terminated".
Wird ausgeführt Die App wurde bereits geöffnet, als der Benutzer versucht hat, sie erneut zu starten. Nichts. Beachten Sie, dass eine andere Instanz Ihrer App nicht gestartet wird. Die bereits ausgeführte Instanz wird einfach aktiviert.

Hinweis

Die aktuelle Benutzersitzung basiert auf der Windows-Anmeldung. Solange der aktuelle Benutzer windows nicht abgemeldet, heruntergefahren oder neu gestartet hat, bleibt die aktuelle Benutzersitzung über Ereignisse wie Sperrbildschirmauthentifizierung, Switch-User usw. erhalten.

Ein wichtiger Umstand ist, dass das Betriebssystem, wenn das Gerät über ausreichende Ressourcen verfügt, häufig verwendete Apps vorab startet, die sich für dieses Verhalten entschieden haben, um die Reaktionsfähigkeit zu optimieren. Apps, die vorab gestartet werden, werden im Hintergrund gestartet und dann schnell angehalten, sodass sie, wenn der Benutzer zu ihnen wechselt, schneller fortgesetzt werden können als das Starten der App.

Aufgrund des Vorabstarts kann die OnLaunched() -Methode der App vom System und nicht vom Benutzer initiiert werden. Da die App im Hintergrund vorab gestartet wird, müssen Sie möglicherweise unterschiedliche Aktionen in OnLaunched()ausführen. Wenn Ihre App z. B. beim Starten die Wiedergabe von Musik startet, wissen sie nicht, wo sie stammen, da die App im Hintergrund vorab gestartet wird. Nachdem Die App im Hintergrund vorab gestartet wurde, folgt ihm ein Aufruf von Application.Suspending. Wenn der Benutzer die App dann startet, wird das Resuming-Ereignis sowie die OnLaunched()- Methode aufgerufen. Weitere Informationen zum Behandeln des Vorabstartszenarios finden Sie unter "Behandeln des Vorabstarts ". Nur Apps, die sich anmelden, werden vorab gestartet.

Windows zeigt einen Begrüßungsbildschirm für die App an, wenn sie gestartet wird. Informationen zum Konfigurieren des Begrüßungsbildschirms finden Sie unter Hinzufügen eines Begrüßungsbildschirms.

Während der Begrüßungsbildschirm angezeigt wird, sollte Ihre App Ereignishandler registrieren und eine benutzerdefinierte Benutzeroberfläche einrichten, die sie für die erste Seite benötigt. Sehen Sie, dass diese Aufgaben, die im Konstruktor der Anwendung ausgeführt werden, und OnLaunched() innerhalb weniger Sekunden abgeschlossen werden, oder das System kann annehmen, dass Ihre App nicht reagiert und beendet wird. Wenn eine App Daten aus dem Netzwerk anfordern oder große Datenmengen vom Datenträger abrufen muss, sollten diese Aktivitäten außerhalb des Startvorgangs abgeschlossen werden. Eine App kann eine eigene benutzerdefinierte Ladebenutzeroberfläche oder einen erweiterten Begrüßungsbildschirm verwenden, während sie auf den Abschluss langer Ausführungsvorgänge wartet. Weitere Informationen finden Sie unter "Anzeigen eines Begrüßungsbildschirms" für mehr Zeit und im Beispiel für den Begrüßungsbildschirm.

Nachdem die App gestartet wurde, wechselt sie in den Zustand "Ausführen ", und der Begrüßungsbildschirm verschwindet, und alle Ressourcen und Objekte des Begrüßungsbildschirms werden gelöscht.

App-Aktivierung

Im Gegensatz zum Starten durch den Benutzer kann eine App vom System aktiviert werden. Eine App kann durch einen Vertrag wie den Freigabevertrag aktiviert werden. Oder es kann aktiviert werden, um ein benutzerdefiniertes URI-Protokoll oder eine Datei mit einer Erweiterung zu behandeln, die Ihre App für die Verarbeitung registriert ist. Eine Liste der Möglichkeiten, wie Ihre App aktiviert werden kann, finden Sie unter ActivationKind.

Die Windows.UI.Xaml.Application-Klasse definiert Methoden, die Sie überschreiben können, um die verschiedenen Möglichkeiten zu behandeln, wie Ihre App aktiviert werden kann. OnActivated kann alle möglichen Aktivierungstypen verarbeiten. Es ist jedoch häufiger, bestimmte Methoden für die Behandlung der am häufigsten verwendeten Aktivierungstypen zu verwenden und OnActivated als Fallbackmethode für die weniger gängigen Aktivierungstypen zu verwenden. Dies sind die zusätzlichen Methoden für bestimmte Aktivierungen:

OnCachedFileUpdaterActivated
OnFileActivated
OnFileOpenPickerActivated OnFileSavePickerActivated
OnSearchActivated
OnShareTargetActivated

Die Ereignisdaten für diese Methoden enthalten die gleiche PreviousExecutionState-Eigenschaft , die wir oben gesehen haben, was Ihnen angibt, in welchem Zustand Sich Ihre App befand, bevor sie aktiviert wurde. Interpretieren Sie den Zustand und die Vorgehensweise auf die gleiche Weise wie oben im Abschnitt " App-Start " beschrieben.

Hinweis : Wenn Sie sich mit dem Administratorkonto des Computers anmelden, können Sie UWP-Apps nicht aktivieren.

Ausführung im Hintergrund

Ab Windows 10, Version 1607, können Apps Hintergrundaufgaben innerhalb desselben Prozesses wie die App selbst ausführen. Weitere Informationen hierzu finden Sie in Hintergrundaktivitäten mit dem Einzelprozessmodell. Wir werden in diesem Artikel nicht in die prozessinterne Hintergrundverarbeitung eingehen, aber wie sich dies auf den App-Lebenszyklus auswirkt, besteht darin, dass zwei neue Ereignisse im Zusammenhang mit der App hinzugefügt wurden, wenn sich Ihre App im Hintergrund befindet. Sie sind: EnteredBackground und LeavingBackground.

Diese Ereignisse geben auch an, ob der Benutzer die Benutzeroberfläche Ihrer App sehen kann.

Die Ausführung im Hintergrund ist der Standardzustand, in dem eine Anwendung gestartet, aktiviert oder fortgesetzt wird. In diesem Zustand ist die Benutzeroberfläche der Anwendung noch nicht sichtbar.

Ausführung im Vordergrund

Die Ausführung im Vordergrund bedeutet, dass die Benutzeroberfläche Ihrer App sichtbar ist.

Das LeavingBackground-Ereignis wird ausgelöst, bevor die Benutzeroberfläche der Anwendung sichtbar ist und bevor sie in den Vordergrundzustand wechselt. Es wird auch ausgelöst, wenn der Benutzer wieder zu Ihrer App wechselt.

Zuvor war der beste Speicherort zum Laden von UI-Ressourcen in den Ereignishandlern "Activated " oder "Resuming ". Jetzt ist LeavingBackground der beste Ort, um zu überprüfen, ob Ihre Benutzeroberfläche bereit ist.

Es ist wichtig, zu überprüfen, ob visuelle Ressourcen zu diesem Zeitpunkt bereit sind, da dies die letzte Möglichkeit ist, Arbeit zu erledigen, bevor Ihre Anwendung für den Benutzer sichtbar ist. Alle Ui-Vorgänge in diesem Ereignishandler sollten schnell abgeschlossen werden, da sie sich auf die Start- und Fortsetzungszeit der Benutzererfahrung auswirkt. LeavingBackground ist die Zeit, um sicherzustellen, dass der erste Frame der Benutzeroberfläche bereit ist. Anschließend sollten Speicher- oder Netzwerkaufrufe mit langer Ausführung asynchron behandelt werden, damit der Ereignishandler zurückgegeben werden kann.

Wenn der Benutzer von Ihrer Anwendung abweicht, wird die Ausführung im Hintergrundzustand von der App erneut ausgeführt.

Erneutes Ausführen des Hintergrundzustands

Das EnteredBackground-Ereignis gibt an, dass Ihre App nicht mehr im Vordergrund sichtbar ist. Auf dem Desktop "EnteredBackground " wird ausgelöst, wenn Ihre App minimiert wird; auf dem Smartphone, wenn Sie zum Startbildschirm oder zu einer anderen App wechseln.

Verringern der Speicherauslastung Ihrer App

Da Ihre App für den Benutzer nicht mehr sichtbar ist, ist dies der beste Ort, um die Arbeit und Animationen des UI-Renderings zu beenden. Sie können LeavingBackground verwenden, um diese Arbeit erneut zu starten.

Wenn Sie im Hintergrund arbeiten werden, ist dies der Ort, an dem Sie sich darauf vorbereiten können. Es empfiehlt sich, "MemoryManager.AppMemoryUsageLevel" zu überprüfen, und verringern Sie bei Bedarf die Menge an Arbeitsspeicher, der von Ihrer App verwendet wird, wenn sie im Hintergrund ausgeführt wird, damit Ihre App nicht vom System beendet wird, um Ressourcen freizugeben.

Weitere Informationen finden Sie unter Verringern der Speicherauslastung, wenn Ihre App in den Hintergrundzustand wechselt.

Speichern des Zustands

Der Anhalteereignishandler ist der beste Ort zum Speichern des App-Zustands. Wenn Sie jedoch im Hintergrund arbeiten (z. B. Audiowiedergabe, Verwendung einer erweiterten Ausführungssitzung oder In-Proc-Hintergrundaufgabe), empfiehlt es sich auch, Ihre Daten asynchron aus dem EnteredBackground-Ereignishandler zu speichern. Dies liegt daran, dass ihre App beendet werden kann, während sie im Hintergrund eine niedrigere Priorität hat. Und da die App in diesem Fall den angehaltenen Zustand nicht durchlaufen hat, gehen Ihre Daten verloren.

Wenn Sie Ihre Daten im EnteredBackground-Ereignishandler speichern, bevor die Hintergrundaktivität beginnt, wird eine gute Benutzererfahrung sichergestellt, wenn der Benutzer Die App wieder in den Vordergrund bringt. Sie können die Anwendungsdaten-APIs verwenden, um Daten und Einstellungen zu speichern. Weitere Informationen finden Sie unter Speichern und Abrufen von Einstellungen und anderen App-Daten.

Nachdem Sie Ihre Daten gespeichert haben, können Sie, wenn Sie die Speicherauslastungsgrenze überschreiten, Ihre Daten aus dem Arbeitsspeicher freigeben, da Sie sie später erneut laden können. Dadurch wird Arbeitsspeicher freigegeben, der von den Ressourcen verwendet werden kann, die für Hintergrundaktivitäten erforderlich sind.

Beachten Sie, dass ihre App, wenn hintergrundaktivitäten ausgeführt werden, von der Ausführung im Hintergrundzustand in den Vordergrundzustand wechseln kann, ohne den angehaltenen Zustand zu erreichen.

Hinweis

Wenn Die App vom Benutzer geschlossen wird, kann das OnSuspending-Ereignis vor dem EnteredBackground-Ereignis ausgelöst werden. In einigen Fällen wird das EnteredBackground-Ereignis möglicherweise nicht ausgelöst, bevor die App beendet wird. Es ist wichtig, Ihre Daten im OnSuspending-Ereignishandler zu speichern.

Asynchrone Arbeit und Verzögerung

Wenn Sie einen asynchronen Aufruf innerhalb des Handlers ausführen, wird das Steuerelement sofort von diesem asynchronen Aufruf zurückgegeben. Dies bedeutet, dass die Ausführung dann vom Ereignishandler zurückgegeben werden kann und ihre App in den nächsten Zustand wechselt, obwohl der asynchrone Aufruf noch nicht abgeschlossen wurde. Verwenden Sie die GetDeferral-Methode für das EnteredBackgroundEventArgs-Objekt, das an den Ereignishandler übergeben wird, um das Anhalten zu verzögern, bis Sie die Complete-Methode für das zurückgegebene Windows.Foundation.Deferral-Objekt aufgerufen haben.

Eine Verzögerung erhöht nicht die Zeitspanne, die Sie zum Ausführen des Codes ausführen müssen, bevor Die App beendet wird. Er verzögert nur die Beendigung, bis entweder die Complete-Methode der Verzögerung aufgerufen wird, oder die Stichtagsübergänge, je nachdem, was zuerst kommt.

Wenn Sie mehr Zeit zum Speichern des Zustands benötigen, untersuchen Sie, wie Sie den Zustand in Phasen speichern können, bevor Ihre App in den Hintergrundzustand wechselt, sodass es in Ihrem OnSuspending-Ereignishandler weniger zu speichern ist. Oder Sie können eine ExtendedExecutionSession anfordern, um mehr Zeit zu erhalten. Es gibt keine Garantie dafür, dass die Anforderung gewährt wird, daher ist es am besten, Wege zu finden, um den Zeitraum zu minimieren, den Sie zum Speichern Ihres Zustands benötigen.

Anhalten der App

Wenn der Benutzer eine App minimiert, wartet Windows einige Sekunden, um zu sehen, ob der Benutzer wieder zu der App wechselt. Wenn sie nicht innerhalb dieses Zeitfensters zurückwechseln und keine erweiterte Ausführung, Hintergrundaufgabe oder aktivitätssponsorierte Ausführung aktiv ist, wird die App von Windows angehalten. Eine App wird auch angehalten, wenn der Sperrbildschirm angezeigt wird, solange keine erweiterte Ausführungssitzung usw. in dieser App aktiv ist.

Wenn eine App angehalten wird, wird das Application.Suspending-Ereignis aufgerufen. Die UWP-Projektvorlagen von Visual Studio bieten einen Handler für dieses Ereignis namens "OnSuspending " in App.xaml.cs. Sie sollten den Code einfügen, um den Anwendungsstatus hier zu speichern.

Sie sollten exklusive Ressourcen und Dateihandles freigeben, damit andere Apps auf sie zugreifen können, während Ihre App angehalten wird. Beispiele für exklusive Ressourcen sind Kameras, E/A-Geräte, externe Geräte und Netzwerkressourcen. Durch die explizite Freigabe exklusiver Ressourcen und Dateihandles kann sichergestellt werden, dass andere Apps während der Angehaltenen App darauf zugreifen können. Wenn die App fortgesetzt wird, sollte sie die exklusiven Ressourcen und Dateihandles erneut abrufen.

Beachten Sie den Stichtag

Um ein schnelles und reaktionsfähiges Gerät sicherzustellen, gibt es ein Limit für die Zeitspanne, die Sie im Anhalteereignishandler ausführen müssen. Es ist für jedes Gerät unterschiedlich, und Sie können herausfinden, was es mit einer Eigenschaft des SuspendingOperation-Objekts namens Stichtag verwendet.

Wie beim EnteredBackground-Ereignishandler , wenn Sie einen asynchronen Aufruf vom Handler ausführen, wird das Steuerelement sofort von diesem asynchronen Aufruf zurückgegeben. Dies bedeutet, dass die Ausführung dann vom Ereignishandler zurückgegeben werden kann, und Ihre App wechselt in den Anhaltezustand, obwohl der asynchrone Aufruf noch nicht abgeschlossen wurde. Verwenden Sie die GetDeferral-Methode für das SuspendingOperation-Objekt (verfügbar über die Ereignisargumente), um die Eingabe des angehaltenen Zustands zu verzögern, bis Sie die Complete-Methode für das zurückgegebene SuspendingDeferral-Objekt aufgerufen haben.

Wenn Sie mehr Zeit benötigen, können Sie eine ExtendedExecutionSession anfordern. Es gibt keine Garantie dafür, dass die Anforderung gewährt wird, daher empfiehlt es sich, Möglichkeiten zu finden, um den Zeitraum zu minimieren, den Sie im Angehaltenen Ereignishandler benötigen.

Beenden der App

Das System versucht, die App und die zugehörigen Daten im Arbeitsspeicher beizubehalten, während sie angehalten ist. Wenn das System jedoch nicht über die Ressourcen verfügt, um ihre App im Arbeitsspeicher zu halten, wird die App beendet. Apps erhalten keine Benachrichtigung darüber, dass sie beendet werden. Die einzige Möglichkeit, die Daten Ihrer App zu speichern, befindet sich in Ihrem OnSuspending-Ereignishandler .

Wenn Ihre App feststellt, dass sie nach dem Beenden aktiviert wurde, sollte sie die gespeicherten Anwendungsdaten laden, damit sich die App in demselben Zustand befindet, in dem sie vor dem Beenden war. Wenn der Benutzer wieder zu einer angehaltenen App wechselt, die beendet wurde, sollte die App die Anwendungsdaten in der OnLaunched-Methode wiederherstellen. Das System benachrichtigt eine App nicht, wenn sie beendet wird. Daher muss Ihre App ihre Anwendungsdaten speichern und exklusive Ressourcen und Dateihandles freigeben, bevor sie angehalten wird, und sie wiederherstellen, wenn die App nach dem Beenden aktiviert wird.

Hinweis zum Debuggen mit Visual Studio: Visual Studio verhindert, dass Windows eine App anhält, die an den Debugger angefügt ist. Dadurch kann der Benutzer die Visual Studio-Debug-UI anzeigen, während die App ausgeführt wird. Wenn Sie eine App debuggen, können Sie sie mithilfe von Visual Studio ein Anhalteereignis senden. Stellen Sie sicher, dass die Symbolleiste "Debugspeicherort " angezeigt wird, und klicken Sie dann auf das Symbol "Anhalten" .

App-Lebenslauf

Eine angehaltene App wird fortgesetzt, wenn der Benutzer zu ihr wechselt oder wenn es sich um die aktive App handelt, wenn das Gerät aus einem Energiesparmodus kommt.

Wenn eine App aus dem Zustand "Angehalten " fortgesetzt wird, wechselt sie in den Zustand "Ausführung im Hintergrund ", und das System stellt die App wieder her, wo sie unterbrochen wurde, sodass sie dem Benutzer so erscheint, als ob sie alle ausgeführt wurde. Im Arbeitsspeicher gespeicherte App-Daten gehen verloren. Daher müssen die meisten Apps den Zustand nicht wiederherstellen, wenn sie fortgesetzt werden, obwohl sie alle Datei- oder Gerätehandles erneut abrufen sollten, die sie beim Anhalten freigegeben haben, und den Zustand wiederherstellen, der beim Anhalten der App explizit freigegeben wurde.

Die App kann stunden- oder tagelang angehalten werden. Wenn Ihre App Inhalte oder Netzwerkverbindungen aufweist, die möglicherweise veraltet sind, sollten diese aktualisiert werden, wenn die App fortgesetzt wird. Wenn eine App einen Ereignishandler für das Application.Resuming-Ereignis registriert hat, wird sie aufgerufen, wenn die App aus dem Zustand "Angehalten " fortgesetzt wird. Sie können Ihre App-Inhalte und -Daten in diesem Ereignishandler aktualisieren.

Wenn eine angehaltene App aktiviert wird, um an einem App-Vertrag oder einer Erweiterung teilzunehmen, empfängt sie zuerst das Resuming-Ereignis und dann das Activated-Ereignis .

Wenn die angehaltene App beendet wurde, gibt es kein Resuming-Ereignis , und stattdessen wird OnLaunched() mit einem ApplicationExecutionState von Terminated aufgerufen. Da Sie den Zustand beim Anhalten der App gespeichert haben, können Sie diesen Zustand während " OnLaunched()" wiederherstellen, sodass die App dem Benutzer so erscheint, als sie von der App weggeschaltet wurde.

Während eine App angehalten wird, empfängt sie keine Netzwerkereignisse, die sie empfangen hat. Diese Netzwerkereignisse werden nicht in die Warteschlange gestellt – sie werden einfach verpasst. Daher sollte Ihre App den Netzwerkstatus testen, wenn sie fortgesetzt wird.

Hinweis : Da das Resuming-Ereignis nicht aus dem UI-Thread ausgelöst wird, muss ein Verteiler verwendet werden, wenn der Code in Ihrem Lebenslaufhandler mit der Benutzeroberfläche kommuniziert. Ein Codebeispiel dazu finden Sie unter Aktualisieren des UI-Threads aus einem Hintergrundthread .

Allgemeine Richtlinien finden Sie unter Richtlinien für das Anhalten und Fortsetzen von Apps.

App schließen

Im Allgemeinen müssen Benutzer keine Apps schließen, sie können windows sie verwalten lassen. Benutzer können eine App jedoch mithilfe der Schließbewegung oder durch Drücken von ALT+F4 oder mithilfe der Aufgabenumschaltung unter Windows Phone schließen.

Es gibt kein Ereignis, das angibt, dass der Benutzer die App geschlossen hat. Wenn eine App vom Benutzer geschlossen wird, wird sie zunächst angehalten, um Ihnen die Möglichkeit zu geben, den Zustand zu speichern. In Windows 8.1 und höher wird die App, nachdem eine App vom Benutzer geschlossen wurde, aus dem Bildschirm entfernt und nicht explizit beendet.

Verhalten durch geschlossener Benutzer: Wenn Ihre App etwas anderes ausführen muss, wenn sie vom Benutzer geschlossen wird als beim Schließen durch Windows, können Sie den Aktivierungsereignishandler verwenden, um zu bestimmen, ob die App vom Benutzer oder von Windows beendet wurde. Weitere Informationen finden Sie in den Beschreibungen von ClosedByUser- und Terminated-Zuständen in der Referenz für die ApplicationExecutionState-Aufzählung.

Es wird empfohlen, apps nicht programmgesteuert zu schließen, es sei denn, es ist unbedingt erforderlich. Wenn eine App beispielsweise einen Speicherverlust erkennt, kann sie sich schließen, um die Sicherheit der persönlichen Daten des Benutzers sicherzustellen.

App-Absturz

Die Systemabsturzerfahrung ist so konzipiert, dass Benutzer so schnell wie möglich wieder auf ihre Aktionen zurückkommen. Sie sollten kein Warndialogfeld oder eine andere Benachrichtigung angeben, da dadurch der Benutzer verzögert wird.

Wenn Ihre App abstürzt, nicht mehr reagiert oder eine Ausnahme generiert, wird ein Problembericht gemäß den Feedback- und Diagnoseeinstellungen des Benutzers an Microsoft gesendet. Weitere Informationen finden Sie unter Diagnose, Feedback und Datenschutz in Windows . Microsoft stellt Ihnen eine Teilmenge der Fehlerdaten im Problembericht bereit, damit Sie sie verwenden können, um Ihre App zu verbessern. Sie können diese Daten auf der Seite "Qualität" Ihrer App im Dashboard anzeigen.

Wenn der Benutzer eine App nach dem Absturz aktiviert, empfängt sein Aktivierungsereignishandler einen ApplicationExecutionState-Wert von NotRunning und sollte die anfängliche Benutzeroberfläche und die ursprünglichen Daten anzeigen. Verwenden Sie nach einem Absturz nicht routinemäßig die App-Daten, die Sie für die Fortsetzung mit "Angehalten " verwendet hätten, da diese Daten beschädigt sein könnten. Weitere Informationen finden Sie unter "Richtlinien für das Anhalten und Fortsetzen von Apps".

Entfernen von Apps

Wenn ein Benutzer Ihre App löscht, wird die App zusammen mit allen lokalen Daten entfernt. Das Entfernen einer App wirkt sich nicht auf die Daten des Benutzers aus, die an allgemeinen Speicherorten wie den Dokument- oder Bildbibliotheken gespeichert wurden.

App-Lebenszyklus und visual Studio-Projektvorlagen

Der grundlegende Code, der für den App-Lebenszyklus relevant ist, wird in den Visual Studio-Projektvorlagen bereitgestellt. Die einfache App behandelt die Startaktivierung, bietet einen Ort, an dem Sie Ihre App-Daten wiederherstellen können, und zeigt die primäre Benutzeroberfläche auch vor dem Hinzufügen eines eigenen Codes an. Weitere Informationen finden Sie unter C#-, VB- und C++-Projektvorlagen für Apps.

Wichtige Anwendungslebenszyklus-APIs