Windows Dev Center

App-Lebenszyklus

In diesem Thema wird der Lebenszyklus einer Windows-Runtime-App von der Bereitstellung bis zu ihrer Entfernung beschrieben. Wenn Sie Apps richtig starten, 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 werden diese Status und Ereignisse beschrieben. Weitere Informationen zu den einzelnen Statusübergängen und dazu, wie die App darauf reagieren sollte, finden Sie in der Referenz zur ApplicationExecutionState-Enumeration.

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

Bereitstellung

Damit eine App aktiviert werden kann, muss sie zunächst bereitgestellt werden. Die grundlegende Bereitstellung erfolgt entweder, wenn ein Benutzer Ihre App installiert oder wenn Sie Visual Studio zum lokalen Erstellen und Ausführen der App während der Entwicklungs- und Testphase verwenden. Weitere Informationen hierzu und zu erweiterten Bereitstellungsszenarien finden Sie unter App-Pakete und -Bereitstellung.

Starten einer App

Eine App wird immer dann gestartet, wenn sie vom Benutzer aktiviert wird und sich der App-Prozess zuvor im Status NotRunning befand. Eine App kann den Status NotRunning aufweisen, weil sie noch nie gestartet wurde, weil sie ausgeführt wurde und dann abgestürzt ist oder weil sie angehalten, dann aber nicht im Arbeitsspeicher vorgehalten werden konnte und vom System beendet wurde.

Beim Start einer App zeigt Windows einen Begrüßungsbildschirm für die App an. Informationen zum Konfigurieren dieses Begrüßungsbildschirms finden Sie unter „Hinzufügen eines Begrüßungsbildschirms“ (HTML oder XAML).

Während der Begrüßungsbildschirm angezeigt wird, sollte durch den App-Code sichergestellt werden, dass ihre Benutzeroberfläche dem Benutzer jederzeit angezeigt werden kann. Die Hauptaufgaben der App sind die Registrierung von Ereignishandlern und die Einrichtung einer angepassten Benutzeroberfläche, die die App zum Laden der ersten Seite benötigt. Diese Aufgaben sollten nur einige Sekunden dauern. Wenn eine App Daten aus dem Netzwerk anfordern oder große Datenmengen von einem Datenträger abrufen muss, sollten diese Aktivitäten außerhalb der Aktivierung abgeschlossen werden. Eine App kann ihre eigene angepasste Ladebenutzeroberfläche oder einen erweiterten Begrüßungsbildschirm verwenden, während auf den Abschluss dieser Vorgänge mit langer Ausführungszeit gewartet wird. Weitere Informationen finden Sie unter „So wird's gemacht: Erweitern des Begrüßungsbildschirms“ (HTML oder XAML) und im Begrüßungsbildschirmbeispiel. Nach Abschluss der App-Aktivierung wechselt die App in den Status Running, und der Begrüßungsbildschirm (und alle zugehörigen Ressourcen und Objekte) werden 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 finden Sie unter „So wird's gemacht: Aktivieren einer App“ (HTML oder XAML).

Aktivieren einer App

Eine App kann vom Benutzer durch verschiedene Verträge und Erweiterungen aktiviert werden. Ihre App muss sich für den Empfang des WinJS activated-Ereignisses (HTML) registrieren oder die OnActivated-Methode überschreiben, um an der Aktivierung teilzunehmen. (Für HTML stellt WebUIApplication.activated ein weiteres Ereignis dar, das zur Aktivierung behandelt werden kann.)

Der Aktivierungscode der App kann testen, warum die App aktiviert wurde und ob sie bereits den Status Running aufweist. Apps können mithilfe eines der folgenden Aktivierungstypen aktiviert werden:

Activation type Beschreibung
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.

 

Für Windows 8.1 und höher erstellte Apps können durch einen der oben genannten oder durch die folgenden Aktivierungstypen 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 von Windows aus verschiedenen Gründen beendet werden, nachdem sie 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 (HTML) oder einen Application.OnActivated-Rückruf (XAML), und der Benutzer sieht den Begrüßungsbildschirm der App, bis die App aktiviert wurde. Mit diesem Ereignis können Sie bestimmen, ob die App ihre Daten wiederherstellen muss, die beim letzten Anhalten der App gespeichert wurden, oder ob Sie die Standarddaten der App laden müssen. Da der Begrüßungsbildschirm bereits geladen ist, kann der App-Code Verarbeitungsleistung investieren, um diese Aufgabe ohne bemerkbare Verzögerung für den Benutzer zu erledigen. Allerdings gelten die zuvor geäußerten Bedenken zu Vorgängen mit langer Ausführungszeit auch beim Neustarten oder Fortsetzen der Ausführung. Die activated/OnActivated-Ereignisdaten enthalten eine PreviousExecutionState-Eigenschaft, an der Sie erkennen, in welchem Status sich die App vor der Aktivierung befunden hat. Diese Eigenschaft entspricht einem der Werte aus der ApplicationExecutionState-Enumeration:

Grund für BeendigungWert der PreviousExecutionState-EigenschaftAuszuführende Aktion
Beendet vom System (beispielsweise aufgrund von Ressourceneinschränkungen)Terminated Sitzungsdaten wiederherstellen
Von Benutzer geschlossen oder durch Benutzerprozess beendetClosedByUser Mit Standarddaten starten
Unerwartet beendet, oder App wurde während der aktuellen Benutzersitzung nicht ausgeführtNotRunningMit Standarddaten starten

 

Hinweis  Aktuelle Benutzersitzung basiert auf Windows-Anmeldung. Solange sich der aktuelle Benutzer nicht explizit abgemeldet oder das System heruntergefahren hat oder Windows nicht aus einem anderen Grund neu gestartet wurde, bleibt die aktuelle Benutzersitzung unabhängig von bestimmten Ereignissen – wie Sperrbildschirmauthentifizierung, Benutzerwechsel usw. – bestehen.

PreviousExecutionState könnte auch den Wert Running oder Suspended aufweisen. In diesen Fällen wurde die App zuvor jedoch nicht beendet, und Sie müssen sich keine Gedanken über die Wiederherstellung von Daten machen.

Hinweis  

Wenn Sie sich mit dem Administratorkonto des Computers anmelden, können Sie keine Windows-Runtime-Apps aktivieren.

Weitere Informationen finden Sie unter App-Erweiterungen.

OnActivated im Vergleich zu bestimmten Aktivierungen in einer XAML-App

Für das XAML-Aktivierungsmodell und die Application-Klasse stellt die OnActivated-Methode das Instrument zur Behandlung aller möglichen Aktivierungstypen dar. Üblicherweise werden die meistverwendeten Aktivierungstypen jedoch mit unterschiedlichen Methoden behandelt, und OnActivated wird nur als Fallbackmethode für weniger verbreitete Aktivierungstypen verwendet. Beispielsweise verfügt Application über eine OnLaunched-Methode, die als Rückruf aufgerufen wird, sobald ActivationKind gleich Launch ist. Dies ist die typische Aktivierung für die meisten Apps. Es gibt 6 weitere On*-Methoden für spezifische Aktivierungen: OnCachedFileUpdaterActivated, OnFileActivated, OnFileOpenPickerActivated, OnFileSavePickerActivated, OnSearchActivated, OnShareTargetActivated. Startvorlagen für eine XAML-App verfügen über eine Implementierung für OnLaunched und einen Handler für Suspending. Beide weisen integrierte Methoden aus der in jeder Vorlage vordefinierten SuspensionManager-Klasse auf. Eine Funktionsbeschreibung zu SuspensionManager gehört nicht zum Inhalt dieses Themas. Weitere Informationen finden Sie unter C#-, VB- und C++-Projektvorlagen für Apps.

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 angehalten, wenn der Benutzer die App verlässt.

Wenn der Benutzer eine App in den Hintergrund verlagert, wird von Windows einige Sekunden abgewartet, ob der Benutzer sofort wieder zurück zur App wechselt. Wenn der Benutzer nicht innerhalb dieses Zeitfensters zurückkehrt, wird die App von Windows angehalten.

Wenn eine App einen Ereignishandler für das WinJS checkpoint-Ereignis (für HTML) oder das Application.Suspending-Ereignis (für XAML) registriert hat, wird dieser Code unmittelbar vor dem Anhalten der App aufgerufen. Sie können relevante App- und Benutzerdaten mithilfe des Ereignishandlers speichern. Es wird empfohlen, dafür die Anwendungsdaten-APIs zu verwenden, da diese garantiert abgeschlossen werden, bevor die App den Status Suspended annimmt. Weitere Informationen finden Sie unter Zugreifen auf App-Daten mit der Windows-Runtime. Sie sollten auch exklusive Ressourcen und Dateihandles freigeben, damit andere Apps darauf zugreifen können, während sie von Ihrer App nicht verwendet werden.

Im Allgemeinen sollte die App beim Behandeln des Anhalteereignisses sofort ihren Status speichern und ihre exklusiven Ressourcen und Dateihandles freigeben. Außerdem sollte die Ausführung des Codes maximal eine Sekunde dauern. 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 von Windows in 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 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. Da Apps nicht einzeln darüber benachrichtigt werden, dass sie beendet werden, besteht die einzige Möglichkeit, App-Daten zu speichern, während des Anhaltens. Wenn eine App feststellt, dass sie nach dem Beenden aktiviert wird, sollte sie die beim Anhalten gespeicherten Anwendungsdaten laden, damit sie wie vor dem Anhalten funktioniert.

In einigen Situationen muss eine App weiter ausgeführt werden, damit Hintergrundaufgaben abgeschlossen werden. Beispielsweise kann Ihre App weiterhin Sound im Hintergrund wiedergeben. Weitere Informationen finden Sie unter „So wird's gemacht: Wiedergeben von Audio im Hintergrund“ (HTML oder XAML). Hintergrundübertragungen werden ebenfalls fortgesetzt, selbst wenn die App angehalten oder sogar beendet wurde. Weitere Informationen finden Sie unter „So wird's gemacht: Herunterladen einer Datei“ (HTML oder XAML).

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

Beispielcode finden Sie unter „So wird's gemacht: Anhalten einer App“ (HTML oder XAML).

Sichtbarkeit einer App

Wenn der Benutzer von Ihrer App zu einer anderen App wechselt, ist Ihre App nicht mehr sichtbar, verbleibt aber weiterhin im Status Running, bis sie von Windows angehalten werden kann. Wenn der Benutzer Ihre App verlässt, sie jedoch wieder aktiviert oder zu ihr zurückkehrt, bevor sie angehalten werden konnte, bleibt sie im Status Running.

Die App empfängt kein Aktivierungsereignis, wenn sich die Sichtbarkeit der App ändert, da die App noch ausgeführt wird. Windows wechselt je nach Bedarf einfach zwischen Apps. Falls eine App eine Aktion ausführen muss, wenn der Benutzer die App verlässt und zurückkehrt, kann sie das visibilitychange-Ereignis (für HTML) oder Window.VisibilityChanged-Ereignis (für XAML) behandeln.

Das Sichtbarkeitsereignis wird nicht mit den Ereignissen zum Anhalten/Fortsetzen oder Aktivieren 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. Es gehen keine App-Daten verloren, solange 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 WebUIApplication.resuming-Ereignis (HTML) oder Application.Resuming-Ereignis (XAML) registriert hat, wird dieser beim Fortsetzen der App aus dem Status Suspended aufgerufen. Sie können die App-Inhalte und -Daten mithilfe dieses Ereignishandlers aktualisieren.

Hinweis  

In HTML-Apps muss resuming normalerweise nicht speziell behandelt werden, weil activated unter denselben Bedingungen ausgelöst wird. Mithilfe der ActivationKind-Angabe aus den activated-Ereignisdaten können Sie bestimmen, ob die App fortgesetzt wird. Dieses Muster wird in der Datei default.js veranschaulicht, die zum Starten von Projektvorlagen verwendet wird.

Wenn eine angehaltene App für die Teilnahme an einem App-Vertrag oder einer Erweiterung aktiviert wird, empfängt sie zunächst das Resuming-Ereignis und dann das 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 unter „So wird's gemacht: Fortsetzen einer App“ (HTML oder XAML).

Hinweis  In Windows Phone Store-Apps wird OnLaunched für eine XAML-App 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, sondern können die Verwaltung Windows überlassen. Unter Windows können Benutzer Apps jedoch mit der Geste zum Schließen 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, beendet und in den Status NotRunning versetzt.

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

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 ApplicationView.TerminateAppOnFinalViewClose-Eigenschaft geschlossen wird.

Wenn eine App einen Ereignishandler für das 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 Windows oder den Benutzer beendet wurde. Wenn sich die App je nachdem, ob sie durch den Benutzer oder Windows geschlossen wurde, anders verhalten soll, können Sie mithilfe des Aktivierungsereignishandlers ermitteln, ob die App durch den Benutzer oder Windows beendet wurde. Informationen finden Sie in den Beschreibungen zum Status ClosedByUser und Terminated in der Referenz zur ApplicationExecutionState-Enumeration. Beachten Sie, dass ClosedByUser bei Windows 8-Apps u. U. anders als bei Windows 8.1-Apps behandelt wird.

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 System wie ein Absturz der App 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 Seite „Qualität“ Ihrer App im Dashboard einsehen.

Wenn der Benutzer eine App nach einem Absturz aktiviert, empfängt ihr Aktivierungsereignishandler den ApplicationExecutionState-Wert NotRunning, und es sollten die ursprüngliche Benutzeroberfläche und die ursprünglichen Daten der App angezeigt werden. Nach einem Absturz sollten Sie die App-Daten, die Sie für Resuming verwendet hätten, nicht routinemäßig mit Suspended verwenden, da diese Daten beschädigt sein können. Weitere Informationen finden Sie unter Richtlinien für das Anhalten und Fortsetzen von Apps.

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, die an allgemeinen Speicherorten, z. B. in Dateien in der Dokument- oder Bildbibliothek, gespeichert wurden.

App-Lebenszyklus und Visual Studio-Projektvorlagen

Für HTML- oder XAML-Apps wird grundlegender, für den App-Lebenszyklus relevanter Code in den Visual Studio-Startprojektvorlagen bereitgestellt. Die Basis-App ist bereits in der Lage, die Startaktivierung zu behandeln und die primäre UI anzuzeigen, bevor Sie eigenen Code hinzugefügt haben. Weitere Informationen finden Sie unter JavaScript-Projektvorlagen für Store-Apps oder C#-, VB- und C++-Projektvorlagen für Apps.

Wichtige APIs für den App-Lebenszyklus

Verwandte Themen

Richtlinien für das Anhalten und Fortsetzen von Apps
Beispiel zum Aktivieren, Fortsetzen und Anhalten einer App (JavaScript)

 

 

Anzeigen:
© 2015 Microsoft