Informationen
Das angeforderte Thema wird unten angezeigt. Es ist jedoch nicht in dieser Bibliothek vorhanden.

App-Lebenszyklus (Windows-Runtime-Apps)

Applies to Windows and Windows Phone

In diesem Thema wird der Lebenszyklus von Apps von der Bereitstellung bis zu ihrer Entfernung beschrieben. Wenn Sie Apps richtig unterbrechen und fortsetzen, bieten Sie Ihren Kunden den höchstmöglichen Grad an Benutzerfreundlichkeit für Ihre App.

App-Ausführungsstatus

In dieser Abbildung sind die Übergänge zwischen den App-Ausführungsstatus dargestellt. In den nächsten Abschnitten dieses Themas 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.

Statusdiagramm mit Übergängen zwischen App-Ausführungsstatus

Starten einer App

Eine App wird immer dann gestartet, wenn sie vom Benutzer aktiviert wird, während der Prozess den Status NotRunning aufweist. Eine App kann sich im nicht ausgeführten Zustand befinden, wenn sie noch nicht gestartet wurde, wenn sie ausgeführt wurde und abgestürzt ist oder wenn sie angehalten, aber nicht im Arbeitsspeicher beibehalten und daher beendet wurde.

Beim Start einer App wird vom Betriebssystem 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.

AktivierungstypBeschreibung
Zwischengespeicherte DateiDer Benutzer möchte eine Datei speichern, für die die App eine Inhaltsverwaltung bereitstellt.
KameraDer Benutzer möchte Fotos oder Videos mit einer verbundenen Kamera aufnehmen.
KontaktauswahlDer Benutzer möchte Kontakte auswählen.
GerätDer Benutzer möchte, dass die App die automatische Wiedergabe verarbeitet.
DateiDie App eines Benutzers hat eine Datei gestartet, und die App ist für die Behandlung des entsprechenden Dateityps registriert.
DateiöffnungsauswahlDer Benutzer möchte Dateien oder Ordner auswählen, die von der App bereitgestellt werden.
DateispeicherungsauswahlDer Benutzer möchte eine Datei speichern und hat die App ausgewählt.
StartDer Benutzer hat die App gestartet oder auf eine Inhaltskachel getippt.
DruckaufgabeDer Benutzer möchte, dass die App Druckaufgaben verarbeitet.
ProtokollDie App eines Benutzers hat eine URL aufgerufen, und die App ist für die Behandlung des entsprechenden Protokolls registriert.
SucheDer Benutzer möchte mit der App eine Suche ausführen.
FreigabezielDer Benutzer hat die App als Ziel für einen Freigabevorgang ausgewählt.

 

Apps, die für Windows 8.1 und höher erstellt werden, können mit diesen Typen ebenfalls aktiviert werden.

Activation type Beschreibung
TerminhinzufügungDer Benutzer möchte dem Kalender einen Termin hinzufügen. Auch unter Windows Phone unterstützt
TerminentfernungDer Benutzer möchte einen Termin aus dem Kalender entfernen. Auch unter Windows Phone unterstützt
TerminersetzungDer Benutzer möchte im Kalender einen Termin ersetzen. Auch unter Windows Phone unterstützt
ZeitrahmenanzeigeDer Benutzer möchte im Kalender einen bestimmten Zeitrahmen anzeigen. Auch unter Windows Phone unterstützt
Anruf an KontaktDer Benutzer möchte einen Kontakt anrufen.
KontaktzuordnungDer Benutzer möchte einen Kontakt zuordnen (seine Position abrufen).
Meldung an KontaktDer Benutzer möchte eine Nachricht an einen Kontakt senden.
Post für KontaktDer Benutzer möchte einen Kontakt posten.
Videoanruf an KontaktDer Benutzer möchte einen Kontakt per Videoanruf anrufen.
SperrbildschirmanrufDer Benutzer möchte einen Anruf über den Sperrbildschirm annehmen.
Eingeschränkter StartDer Benutzer hat Ihre eingeschränkte App gestartet.

 

Windows Phone-App können mit den folgenden Typen aktiviert werden.

Activation type Beschreibung
VoiceCommand Die Anwendung wurde infolge der Ausführung eines Sprachbefehls aktiviert.
PickerReturned Die Anwendung wurde nach dem Abschluss einer Auswahl aktiviert.
WalletAction Die Anwendung wurde zum Ausführen eines Wallet-Vorgangs aktiviert.
PickFileContinuation Die Anwendung wurde aktiviert, nachdem die App für einen Dateiauswahlvorgang angehalten wurde.
PickSaveFileContinuation Die Anwendung wurde aktiviert, nachdem die App für einen Vorgang zur Dateispeicherungsauswahl angehalten wurde.
PickFolderContinuation Die Anwendung wurde aktiviert, nachdem die App für einen Ordnerauswahlvorgang angehalten wurde.
WebAuthenticationBrokerContinuation Die Anwendung wurde aktiviert, nachdem die App für den Vorgang eines Webauthentifizierungsbrokers angehalten wurde.

 

Die App kann die Aktivierung verwenden, um zuvor gespeicherte Daten wiederherzustellen, falls die App vom Betriebssystem beendet wird und der Benutzer sie anschließend neu startet. Die App kann vom Betriebssystem 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 vom Betriebssystem 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 App 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 BeendigungWert der PreviousExecutionState-EigenschaftAuszuführende Aktion
Beendet vom System (beispielsweise aufgrund von Ressourceneinschränkungen)Terminated Sitzungsdaten wiederherstellen
Vom Benutzer beendetClosedByUser Mit Standarddaten starten
Unerwartet beendet oder App wurde seit dem Start der Sitzung des Benutzers nicht ausgeführt NotRunningMit 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.

  • Applies to Windows

Hinweis  

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 das Gerät in den Energiesparmodus wechselt. Die meisten Apps werden nicht mehr ausgeführt, wenn der Benutzer die App verlässt.

Wenn der Benutzer eine App in den Hintergrund verlagert, wird vom Betriebssystem einige Sekunden abgewartet, ob der Benutzer sofort wieder zurück zu der App wechselt. Wechselt der Benutzer nicht zurück, wird die App vom Betriebssystem 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 unter Windows nicht innerhalb von 5 Sekunden bzw. unter Windows Phone nicht innerhalb von 1 bis 10 Sekunden vom Anhalteereignis zurück, wird die App vom Betriebssystem aufgrund der Annahme beendet, dass die App nicht mehr reagiert.

Vom Betriebssystem wird versucht, die größtmögliche Anzahl angehaltener Apps im Arbeitsspeicher beizubehalten. Dadurch wird sichergestellt, dass Benutzer schnell und zuverlässig zwischen angehaltenen Apps wechseln können. Sollten jedoch nicht ausreichend Ressourcen verfügbar sein, um die App im Speicher zu halten, kann die App vom Betriebssystem 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-Runtime-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 (etwa 10 Sekunden), bis sie vom Betriebssystem angehalten werden kann. Wenn der Benutzer Ihre App verlässt, Ihre App jedoch aktiviert oder zu ihr zurückkehrt, bevor sie 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. Vom Betriebssystem wird je nach Bedarf zwischen den Apps gewechselt. Falls eine App eine Aktion ausführen muss, wenn der Benutzer die App verlässt und zurückkehrt, kann sie dafür das VisibilityChanged | msvisibilitychange-Ereignis behandeln.

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 Energiesparmodus für das Gerät 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:

  • Applies to Windows Phone

Hinweis  Unter Windows Phone wird OnLaunched jedes Mal aufgerufen, wenn der Benutzer die App über die Startkachel oder App-Liste startet. Dies ist auch dann der Fall, wenn die App derzeit im Arbeitsspeicher angehalten ist. Unter Windows wird beim Starten einer angehaltenen App über die Startkachel oder die App-Liste diese Methode nicht aufgerufen.

Schließen einer App

Im Allgemeinen müssen Benutzer Apps nicht schließen, sie können dies durch das Betriebssystem erledigen lassen. Unter Windows können Benutzer Apps jedoch mit der Schließgeste oder durch Drücken von ALT+F4 schließen. Unter Windows Phone werden Apps mithilfe der Aufgabenumschaltfunktion geschlossen. 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 sie nimmt innerhalb von 10 Sekunden den Status NotRunning an.

In Windows 8.1 und höher wird eine App nach dem Schließen durch den Benutzer nur vom Bildschirm und aus der Umschaltliste entfernt und nicht beendet.

  • Applies to Windows

Hinweis  Falls Ihre App vom Windows 8-Verhalten "Vom Benutzer geschlossen" (closed-by-user) abhängig ist, können Sie dieses Verhalten in der App aktivieren, wenn Sie dafür das Upgrade auf Windows 8.1 durchführen. Legen Sie zum Aktivieren des Windows 8-Verhaltens "Vom Benutzer geschlossen" die Windows 8.1-App so fest, dass sie beendet wird, wenn das letzte Fenster mit der Windows.UI.ViewManagement.ApplicationView.TerminateAppOnFinalViewClose-Eigenschaft geschlossen wird.

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.

Verhalten "Vom Benutzer geschlossen":  Es ist ratsam festzulegen, wie sich die App verhält, wenn sie nach dem Schließen durch den Benutzer wieder aktiviert wird. Vielleicht ist es für Sie unerheblich, ob die App durch das Betriebssystem oder den Benutzer beendet wurde. Wenn die App sich je nachdem, ob sie durch den Benutzer oder das Betriebssystem beendet wurde, anders verhalten soll, können Sie mithilfe des Aktivierungsereignishandlers ermitteln, ob die App durch den Benutzer oder das Betriebssystem beendet wurde. Beschreibungen zu den Status ClosedByUser und Terminated finden Sie in den Dokumenten für die ApplicationExecutionState-Enumeration.

Wir raten dazu, dass Apps sich selbst nur dann programmgesteuert schließen sollten, wenn dies absolut 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 vom Betriebssystem 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 Dev Center einsehen.

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

Verwandte Themen

Richtlinien für das Anhalten und Fortsetzen von Apps
Beispiele
Beispiel zum Aktivieren, Unterbrechen und Fortsetzen der App mit WinRT

 

 

Anzeigen:
© 2014 Microsoft