App-Lebenszyklus (Windows Store-Apps)
Hier finden Sie Informationen zum Lebenszyklus einer Windows Store-App – angefangen bei ihrer Bereitstellung bis hin zu dem Zeitpunkt, an dem sie wieder entfernt wird. Wenn Sie Apps mithilfe von Windows ordnungsgemäß unterbrechen und fortsetzen, bieten Sie Ihren Kunden den höchstmöglichen Grad an Benutzerfreundlichkeit für Ihre App.
Bereitstellen einer App
Benutzer erwerben die App im Windows Store in Form eines App-Pakets. Die Dateierweiterung dieser App-Pakete lautet .appx. Jedes Paket enthält ein Manifest und die Dateien, die die App bilden. Das Paketmanifest beschreibt die App und wird von Windows beim Installieren und Entfernen der App verwendet.
Im Paketmanifest kann auch angegeben sein, ob die App programmgesteuerten Zugriff auf geschützte Ressourcen oder verbundene Geräte erfordert. Benutzer können sich darauf verlassen, dass die App nicht auf diese Systemressourcen oder die Dateien in ihren Bibliotheken zugreifen kann, wenn sie den Zugriff nicht genehmigen. Informationen finden Sie unter Deklaration der App-Funktionen.
Weitere Informationen finden Sie unter App-Pakete und -Bereitstellung.
App-Ausführungsstatus
In dieser Abbildung sind die Übergänge zwischen den App-Ausführungsstatus dargestellt. In den nächsten Abschnitten auf dieser Seite werden diese Status und Ereignisse beschrieben. Weitere Details darüber, wann die einzelnen Übergangsstatus auftreten und wie die App darauf reagieren sollte, finden Sie in den Dokumenten zur ApplicationExecutionState-Enumeration.
Starten einer App
Eine App wird gestartet, wenn der Benutzer sie aktiviert, aber der Prozess den Status NotRunning aufweist, da die App gerade erst bereitgestellt wurde, da sie abgestürzt ist oder weil sie angehalten und nicht im Arbeitsspeicher beibehalten wurde.
Beim Start einer App wird von Windows ein Begrüßungsbildschirm für die App angezeigt. Informationen zum Konfigurieren dieses Begrüßungsbildschirms finden Sie unter Hinzufügen eines Begrüßungsbildschirms.
Während der Begrüßungsbildschirm angezeigt wird, sollte von der App sichergestellt werden, dass ihre Benutzeroberfläche dem Benutzer jederzeit angezeigt werden kann. Die Hauptaufgaben der App sind die Registrierung von Ereignishandlern und die Einrichtung benutzerdefinierter UI, die die App zum Laden benötigt. Diese Aufgaben sollten nur einige Sekunden dauern. Wenn eine App Daten aus dem Netzwerk anfordern oder große Mengen an Daten von einem Datenträger abrufen muss, sollten diese Aktivitäten außerhalb der Aktivierung abgeschlossen werden. Eine App kann ihre eigene benutzerdefinierte geladene UI oder einen erweiterten Begrüßungsbildschirm verwenden, während auf den Abschluss dieser lange ausgeführten Vorgänge gewartet wird. Weitere Details finden Sie in der Dokumentation zum erweiterten Begrüßungsbildschirm und im Begrüßungsbildschirmbeispiel. Nach der vollständigen Aktivierung der App gelangt sie in den Status Running, und der Begrüßungsbildschirm wird ausgeblendet. Typische Arten der Aktivierung einer App sind das Anzeigen eines Fensters, die Rückkehr vom Aktivierungshandler und das Beenden einer Verzögerung. Weitere Informationen:
Aktivieren einer App
Eine App kann vom Benutzer durch verschiedene Verträge und Erweiterungen aktiviert werden. Für die Teilnahme an der Aktivierung muss sich die App registrieren, um das Activated | activated-Ereignis empfangen zu können. Der Aktivierungsereignishandler der App kann testen, warum die App aktiviert wurde und ob sie bereits den Status Running aufwies. Apps können auf die folgenden Arten aktiviert werden.
| Aktivierungstyp | Beschreibung |
|---|---|
| Zwischengespeicherte Datei | Der Benutzer möchte eine Datei speichern, für die die App eine Inhaltsverwaltung bereitstellt. |
| Kamera | Der Benutzer möchte Fotos oder Videos mit einer verbundenen Kamera aufnehmen. |
| Kontaktauswahl | Der Benutzer möchte Kontakte auswählen. |
| Gerät | Der Benutzer möchte, dass die App die automatische Wiedergabe verarbeitet. |
| Datei | Die App eines Benutzers hat eine Datei gestartet, und die App ist für die Behandlung des entsprechenden Dateityps registriert. |
| Dateiöffnungsauswahl | Der Benutzer möchte Dateien oder Ordner auswählen, die von der App bereitgestellt werden. |
| Dateispeicherungsauswahl | Der Benutzer möchte eine Datei speichern und hat die App ausgewählt. |
| Start | Der Benutzer hat die App gestartet oder auf eine Inhaltskachel getippt. |
| Druckaufgabe | Der Benutzer möchte, dass die App Druckaufgaben verarbeitet. |
| Protokoll | Die App eines Benutzers hat eine URL aufgerufen, und die App ist für die Behandlung des entsprechenden Protokolls registriert. |
| Suche | Der Benutzer möchte mit der App eine Suche ausführen. |
| Freigabeziel | Der Benutzer hat die App als Ziel für einen Freigabevorgang ausgewählt. |
Die App kann die Aktivierung verwenden, um zuvor gespeicherte Daten wiederherzustellen, falls die App von Windows beendet wird und der Benutzer sie anschließend neu startet. Die App kann von Windows beendet werden, nachdem sie aus verschiedenen Gründen angehalten wurde. Der Benutzer kann die App manuell schließen oder sich abmelden, oder die Systemressourcen werden knapp. Wenn der Benutzer die App startet, nachdem sie von Windows beendet wurde, empfängt die App ein activated-Ereignis, und der Benutzer sieht den Begrüßungsbildschirm der App, bis die App aktiviert wurde. Mit diesem Ereignis können Sie bestimmen, ob ihre Anwendung die Daten wiederherstellen muss, die beim letzten Anhalten der App gespeichert wurden, oder ob Sie die Standarddaten der App laden müssen. Die activated-Ereignisargumente enthalten eine PreviousExecutionState-Eigenschaft, die Ihnen mitteilt, welchen Status die App vor der Aktivierung aufwies. Diese Eigenschaft ist einer der Werte aus der ApplicationExecutionState-Enumeration. In der nachfolgenden Tabelle sind die Möglichkeiten zusammengefasst:
| Grund für Beendigung | Wert der PreviousExecutionState-Eigenschaft | Auszuführende Aktion |
|---|---|---|
| Beendet vom System (beispielsweise aufgrund von Ressourceneinschränkungen) | Terminated | Sitzungsdaten wiederherstellen |
| Vom Benutzer beendet | ClosedByUser | Mit Standarddaten starten |
| Unerwartet beendet oder App wurde seit dem Start der Sitzung des Benutzers nicht ausgeführt | NotRunning | Mit Standarddaten starten |
PreviousExecutionState könnte auch den Wert "Running" oder "Suspended" aufweisen, aber in diesen Fällen wurde die App zuvor nicht beendet, und Sie müssen Sie keine Gedanken über das Wiederherstellen von Daten machen.
Beachten Sie, dass Sie keine Windows Store-Apps aktivieren können, wenn Sie sich mit dem Administratorkonto des Computers anmelden.
Weitere Informationen finden Sie unter App-Erweiterungen.
Anhalten einer App
Apps können angehalten werden, wenn der Benutzer die App verlässt oder Windows in den Stromsparmodus wechselt. Die Ausführung der meisten Apps wird beendet, wenn der Benutzer die App verlässt.
Wenn der Benutzer eine App in den Hintergrund bringt, wird von Windows einige Sekunden abgewartet, ob der Benutzer sofort wieder zurück zu der App wechselt. Wechselt der Benutzer nicht zurück, wird die App durch Windows angehalten.
Wenn eine App einen Ereignishandler für das Suspending | suspending-Ereignis registriert hat, wird dieser direkt vor dem Anhalten der App aufgerufen. Sie können relevante App- und Benutzerdaten mithilfe des Ereignishandlers im beständigen Speicher speichern. Es wird empfohlen, dafür die Anwendungsdaten-APIs zu verwenden, da diese garantiert angehalten werden, bevor die App den Status Suspended annimmt. Weitere Informationen finden Sie unter Anwendungsdaten. Sie sollten auch exklusive Ressourcen und Dateihandles freigeben, damit andere Apps darauf zugreifen können, wenn Ihre App sie nicht verwendet.
Eine App sollte ihren Status ganz allgemein sofort im Ereignishandler speichern und ihre exklusiven Ressourcen und Dateihandles freigeben, wenn das Anhalteereignis empfangen wird, und die Daten grundsätzlich in weniger als einer Sekunde speichern. Kehrt eine App nicht innerhalb von 5 Sekunden vom Anhalteereignis zurück, wird die App durch Windows aufgrund der Annahme beendet, dass die App nicht mehr reagiert.
Von Windows wird versucht, die größtmögliche Anzahl angehaltener Apps im Arbeitsspeicher beizubehalten. Dadurch wird sichergestellt, dass Benutzer schnell und zuverlässig zwischen angehaltenen Apps hin und her wechseln können. Sollten jedoch nicht ausreichend Ressourcen verfügbar sein, um die App im Speicher zu halten, kann die App von Windows beendet werden. Beachten Sie, dass Apps nicht über das Beenden benachrichtigt werden. App-Daten können also ausschließlich beim Anhalten einer App gespeichert werden. Wenn eine App ermittelt, dass sie nach dem Beenden aktiviert wird, sollte sie die beim Anhalten gespeicherten Anwendungsdaten laden, damit die App wie zum Zeitpunkt des Anhaltens angezeigt wird.
Einige Apps müssen weiterhin ausgeführt werden, um Hintergrundaufgaben abzuschließen. Die App kann weiterhin Audio im Hintergrund wiedergeben. Weitere Informationen finden Sie unter Schnellstart: Hinzufügen von Audio in einer Windows Store-App. Hintergrundübertragungen werden fortgesetzt, selbst wenn die App angehalten oder beendet wurde. Weitere Informationen finden Sie unter Schnellstart: Herunterladen von Dateien.
Entsprechende Richtlinien finden Sie unter Richtlinien für das Anhalten und Fortsetzen von Apps.
Beispielcode finden Sie in folgenden Artikeln:
Sichtbarkeit einer App
Wenn der Benutzer von Ihrer App zu einer anderen App wechselt, ist Ihre App nicht mehr sichtbar, sie verbleibt aber weiterhin im Ausführungsstatus, bis sie von Windows angehalten werden kann (für etwa 10 Sekunden). Wenn der Benutzer Ihre App verlässt, Ihre App jedoch aktiviert oder zu ihr zurückkehrt, bevor sie von Windows angehalten werden konnte, wird der Ausführungsstatus nicht beendet.
Die App empfängt kein Aktivierungsereignis, wenn sich die Sichtbarkeit der App ändert, da die App noch ausgeführt wird. Von Windows wird je nach Bedarf zwischen den Apps hin und her gewechselt. Wenn die App eine Aktion ausführen muss, während der Benutzer die App verlässt oder zu ihr zurückkehrt, kann sie das Ereignis VisibilityChanged | msvisibilitychange verarbeiten.
Das Sichtbarkeitsereignis wird nicht mit den Fortsetzungs- oder Aktivierungsereignissen serialisiert. Gehen Sie nicht davon aus, dass diese Ereignisse in einer bestimmten Reihenfolge auftreten.
Fortsetzen einer App
Eine angehaltene App wird fortgesetzt, wenn der Benutzer zu ihr wechselt oder der Stromsparmodus für Windows beendet wird.
Eine Aufzählung der Status, die die App aufweisen kann, wenn sie fortgesetzt wird, finden Sie unter ApplicationExecutionState. Wenn eine App aus dem Status Suspended fortgesetzt wird, nimmt sie den Status Running an und wird an dem Punkt fortgesetzt, an dem sie zuvor angehalten wurde. Anwendungsdaten gehen nicht verloren, da sie im Arbeitsspeicher gespeichert wurden. Daher müssen die meisten Apps keine Aktionen ausführen, wenn sie fortgesetzt werden. Möglicherweise hat sich die App jedoch mehrere Stunden oder sogar Tage im angehaltenen Status befunden. Wenn Inhalte oder Netzwerkverbindungen der App inzwischen veraltet sind, sollten diese bei der Fortsetzung daher aktualisiert werden. Wenn eine App einen Ereignishandler für das Resuming | resuming-Ereignis registriert hat, wird dieser beim Fortsetzen der App aus dem Status Suspended aufgerufen. Sie können die Inhalte mithilfe dieses Ereignishandlers aktualisieren.
Wenn eine angehaltene App für die Beteiligung an einem App-Vertrag oder einer Erweiterung aktiviert wird, empfängt sie zunächst das Resuming | resuming-Ereignis und dann das Activated | activated-Ereignis.
Angehaltene Apps empfangen keine Netzwerkereignisse, für deren Empfang sie registriert sind. Diese Ereignisse werden nicht in die Warteschlange gestellt, sondern einfach verpasst. Apps sollten beim Fortsetzen daher den Netzwerkstatus prüfen.
Entsprechende Richtlinien finden Sie unter Richtlinien für das Anhalten und Fortsetzen von Apps.
Beispielcode finden Sie in folgenden Artikeln:
Schließen einer App
Im Allgemeinen müssen Benutzer Apps nicht schließen, sie können dies durch Windows erledigen lassen. Benutzer können Apps jedoch mit der Schließgeste oder durch Drücken von ALT+F4 schließen. Sie können keine UI in die App einfügen, mit der der Benutzer die App schließen kann. Andernfalls besteht sie den Store-Zertifizierungsvorgang nicht.
Es gibt kein spezielles Ereignis zum Angeben, dass der Benutzer eine App geschlossen hat. Nachdem eine App durch den Benutzer geschlossen wurde, wird sie angehalten und beendet und nimmt innerhalb von 10 Sekunden den Status NotRunning an. Wenn eine App einen Ereignishandler für das Suspending | suspending-Ereignis registriert hat, wird dieses aufgerufen, sobald die App angehalten wird. Sie können relevante Anwendungs- und Benutzerdaten mithilfe dieses Ereignishandlers im beständigen Speicher speichern.
Sie sollten festlegen, wie sich die App verhält, wenn sie nach dem Schließen durch den Benutzer wieder aktiviert wird. Möglicherweise ist es für Sie unerheblich, ob die App durch Windows oder den Benutzer beendet wurde. Wenn die App sich je nachdem, ob sie durch den Benutzer oder Windows beendet wurde, anders verhalten soll, kann vom Aktivierungsereignishandler ermittelt werden, ob die App durch den Benutzer oder Windows beendet wurde. Beschreibungen zu den Status ClosedByUser und Terminated finden Sie in den Dokumenten für die ApplicationExecutionState-Enumeration.
Apps sollten sich nur programmgesteuert selbst schließen, wenn dies unbedingt erforderlich ist. Wenn eine App beispielsweise einen Speicherverlust erkennt, kann sie sich selbst schließen, um die Sicherheit der persönlichen Daten des Benutzers zu wahren. Wenn Sie eine App programmgesteuert schließen, wird dies von Windows wie ein App-Absturz behandelt.
App-Absturz
Apps müssen die Systemabsturzerfahrung befolgen, die einfach nur aus der Rückkehr zum Startbildschirm besteht. Mit der Systemabsturzerfahrung sollen Benutzer möglichst schnell wieder das tun können, was sie vor dem Absturz getan haben. Daher sollten Sie kein Warndialogfeld und keine anderen Benachrichtigungen bereitstellen, da dies für den Benutzer eine Verzögerung bedeutet. Das Verschwinden der App dürfte dem Benutzer schon deutlich gemacht haben, dass etwas schief gelaufen ist.
Wenn die App abstürzt, nicht mehr reagiert oder eine Ausnahme generiert, wird der Benutzer von Windows um Zustimmung gebeten, dass ein Problembericht an Microsoft gesendet wird. Microsoft stellt Ihnen einige der Fehlerdaten im Problembericht bereit, mit denen Sie Ihre App verbessern können. Sie können diese Daten auf der Qualitätsseite Ihrer App in Ihrem Dashboard im Windows Dev Center für Windows Store-Apps einsehen. (Beachten Sie, dass Sie Apps erst übermitteln bzw. Daten Ihrer Apps erst anzeigen können, wenn der Windows Store für allgemeine Übermittlungen geöffnet ist.)
Wenn der Benutzer eine App nach einem Absturz aktiviert, empfängt ihr Ereignishandler einen ApplicationExecutionState-Wert NotRunning, und es sollten einfach die ursprüngliche Benutzeroberfläche und die ursprünglichen Daten der App angezeigt werden.
Entfernen einer App
Löscht ein Benutzer eine App, wird die App mit allen zugehörigen lokalen Daten entfernt. Das Entfernen von Apps hat keine Folgen für die Benutzerdaten wie Dateien in der Dokument- oder der Bildbibliothek.
Programmierschnittstellen für den App-Lebenszyklus
- Namespace Windows.ApplicationModel
- Namespace Windows.ApplicationModel.Activation
- Namespace Windows.ApplicationModel.Core
- Namespace Windows.UI.WebUI
- Klasse Windows.UI.Xaml.Application
- Klasse Windows.UI.Xaml.Window
- Namespace WinJS.Application
Verwandte Themen
- Richtlinien für das Anhalten und Fortsetzen von Apps
- Beispiele
- Beispiel zum Aktivieren, Unterbrechen und Fortsetzen der App mit WinRT
