Sonderausgabe 2015 zu Windows 10

Band 30, Nummer 11

Dieser Artikel wurde maschinell übersetzt.

Lebenszyklus von Apps – Apps mit Hintergrundaufgaben und erweiterter Ausführung aktiv halten

Durch Shawn Henry | Windows-2015

Es verwendet, um die Lebensdauer einer Anwendung einfach war. Wenn ein Benutzer eine Anwendung gestartet, es könnte wild auf dem System ausgeführt: Ressourcen verbrauchen, etwa Windows und es ohne Berücksichtigung von anderen freut sich im Allgemeinen durchführen. Heute sind die Dinge komplizierter. In einer Welt Mobile erste sind apps auf einem definierten Anwendungslebenszyklus beschränkt. Dieser Lebenszyklus gibt an, wenn eine Anwendung kann ausgeführt werden und in den meisten Fällen das nicht, wenn die Anwendung das aktuelle Element nicht der Benutzer tut, darf er wurde nicht ausgeführt.

In den meisten Fällen ist dies gut – Benutzer wissen, dass eine Anwendung nicht Energie verbrauchen oder zehrendem Leistung. Für apps wird das Betriebssystem erzwingen was immer sinnvoll, wurde Applikationen stabilen Ruhezustand bei aktiven eingeben. Dies ist besonders wichtig, da das Anwendungsmodell in der universelle Windows-Plattform (UWP) von der niedrigsten End-Geräte wie Mobiltelefone und Geräte Internet der Dinge (IoT), zu den leistungsstärksten Desktops und Xboxes zu skalieren muss.

Für komplexe apps kann das moderne Anwendungsmodell restriktiv scheinen auf den ersten jedoch wie in diesem Artikel beschrieben wird, stehen einige Möglichkeiten, die Anwendung das Feld erweitern und Ausführen von Aufgaben und Übermitteln von Benachrichtigungen, auch nicht im Vordergrund.

Anwendungslebenszyklus

In herkömmlichen Win32 und .NET Desktopentwicklung apps sind in der Regel in zwei Zuständen: "wird ausgeführt" oder "wird nicht ausgeführt" und in den meisten Fällen sie ausgeführt. Dies mag offensichtlich, aber stellen Sie sich ein Instant messaging-Anwendung wie Skype oder eine Musik-app wie Spotify: der Benutzer wird gestartet, eine Aktion (Senden einer Nachricht oder Suchen nach Musik), dann erlischt und etwas anderes. Während der gesamten Zeit, Skype befindet sich im Hintergrund warten auf Nachrichten kommen und Spotify Musikwiedergabe verfolgt. Dies steht im Gegensatz zu moderne apps (z. B. Windows-apps basierend auf der UWP), die verbringen Großteil ihrer Zeit im Status ausgeführt wird.

Windows-apps werden immer in einem von drei Zuständen: ausgeführt, angehalten oder wird nicht ausgeführt, siehe Abbildung 1. Wenn ein Benutzer eine Windows-Anwendung gestartet wird, z. B. durch Klicken auf eine Kachel im Startmenü die app aktiviert ist, und wechselt in den ausgeführten Status. Solange der Benutzer mit der Anwendung interagiert, bleibt es ausgeführt. Wenn der Benutzer die app navigiert oder minimiert, wird eine angehaltene Ereignis ausgelöst. Dies ist eine Gelegenheit für die app jeden Zustand zu serialisieren, die für benötigen möglicherweise fortgesetzt oder erneut aktiviert werden, wie z. B. die aktuelle Seite der Anwendung oder teilweise ausgefüllte Formulardaten. Wenn eine app im angehaltenen Zustand ist, den Prozess sowie die Threads werden von Windows angehalten und können nicht ausgeführt werden. Wenn der Benutzer wieder an die app navigiert, Anwendungsthreads nicht fixiert werden und die Anwendung fortgesetzt wird, ausgeführt.

Der Lebenszyklus der Windows-Anwendung
Abbildung 1: des Lebenszyklus der Windows-Anwendung

Ist eine Anwendung in den Ruhezustand, aber der Ressourcen (in der Regel Speicher), sind erforderlich, für andere Zwecke, z. B. das Ausführen einer anderen Anwendung, wird die Anwendung in den nicht ausgeführten Status verschoben.

Aus Sicht Ausführung der Anwendung ist der Unterschied zwischen der angehaltene und nicht ausgeführt, ob die Anwendung im Speicher bleiben darf. Wenn eine Anwendung lediglich angehalten wird, seine Ausführung ist fixiert, aber alle Zustandsinformationen verbleibt im Arbeitsspeicher. Wenn eine Anwendung nicht ausgeführt wird, wird es aus dem Speicher entfernt. Da kein Ereignis ausgelöst wird, wenn eine app von verschoben angehalten wird, nicht ausgeführt wird, ist es wichtig, damit eine Anwendung serialisiert alle Informationen über den Zustand aus dem Speicher benötigt, für den Fall, dass es erneut aktiviert wird, nicht ausgeführt.

Abbildung 2 veranschaulicht die Verwendung von Ressourcen wie Applikationen Übergang über den Lebenszyklus Vorgänge. Wenn eine Anwendung aktiviert ist, beginnt es in der Regel erreicht eine relativ stabil Ausschlag Speicher verbraucht. Wenn eine Anwendung angehalten wird, ausfällt sein Speicherverbrauch in der Regel – Puffer und verwendeten Ressourcen werden freigegeben, und CPU-Auslastung wird auf Null (vom Betriebssystem erzwungen). Beim Verschieben von einer Anwendung zwischen angehalten wird, nicht ausgeführt werden Arbeitsspeicher und CPU-Nutzung NULL ist, erneut vom Betriebssystem erzwungen werden.

Der Lebenszyklus der Anwendung und der Ressourcenverwendung
Abbildung 2: der Lebenszyklus der Anwendung und der Ressourcenverwendung

Für viele Desktopsysteme mit viel RAM und großen Auslagerungsdateien, ist es nicht üblich, aber nicht unmöglich – ist sehr viel häufiger auf Mobile und andere Geräte mit eingeschränkten Ressourcen eine Anwendung aus dem Speicher, aber dieser Übergang entfernt werden soll. Aus diesem Grund ist es wichtig, Ihre UWP-app auf einer Vielzahl von Geräten zu testen. Mit Visual Studio geliefert wird Windows-Emulator kann für diese extrem hilfreich sein. Sie ermöglicht Entwicklern Zielgeräte mit als kleine 512MB Arbeitsspeicher.

Erweiterte Ausführung

Anwendungslebenszyklus beschriebenen ist effizient – apps sind nicht die Ressourcen beanspruchen, wenn sie nicht verwendet werden – aber das Ergebnis in einem Szenario, in welche eine app benötigt kann nicht durchgeführt werden, kann. Beispielsweise ist bei einer Social oder Kommunikation app ein typischer Anwendungsfall anmelden und eine Reihe von Cloud-Daten (Kontakte, Feeds, Unterhaltungen usw.) zu synchronisieren. Mit den grundlegenden Anwendungslebenszyklus wie beschrieben, müsste Herunterladen von Kontakten, der Benutzer die app öffnen und im Vordergrund die ganze Zeit beibehalten! Ein weiteres Beispiel ist ein Navigations- oder Fitness-Anwendung, die den Standort eines Benutzers verfolgt werden müssen. Sobald der Benutzer zu einer anderen app gewechselt, oder setzen Sie das Gerät in ihrer Tasche, würde dies nicht mehr funktionsfähig. Es muss einen Mechanismus, um zu ermöglichen, ein bisschen länger ausgeführt werden.

Der universelle Windows-Plattform Konzept das der erweiterten Ausführung bei diesen Szenarios helfen. Es gibt zwei Fälle, in denen erweiterte Ausführung verwendet werden können:

  1. Jederzeit während der Ausführung der regulären im Vordergrund, während die Anwendung ausgeführt wird.
  2. Nachdem die Anwendung ein Ereignis zum Anhalten erhalten hat (das Betriebssystem ist, verschieben Sie die app in den angehaltenen Zustand) in die Anwendung anhalten-Ereignishandler.

Der Code für diese beiden Fälle ist identisch, aber die Anwendung unterscheidet sich in den einzelnen. Im ersten Fall bleibt die Anwendung in den Ausführungsstatus, selbst bei Eintreten ein Ereignisses, das normalerweise die Unterbrechung auslöst (z. B. der Benutzer die Anwendung verlassen). Die Anwendung erhalten nie ein Ereignis zum Anhalten, während die Ausführung-Erweiterung ausgeführt wird. Die Erweiterung verworfen wird, wird die Anwendung für die Unterbrechung wieder.

Mit dem zweiten Fall wenn die Anwendung in den Ruhezustand wechselt bleibt anhalten Status für den Zeitraum der Erweiterung. Sobald die Erweiterung abgelaufen ist, wird die Anwendung den angehaltenen Zustand ohne weitere Benachrichtigung.

Abbildung 3 veranschaulicht, wie erweiterte Ausführung den Uspending Zustand einer Anwendung zu erweitern. Zuerst wird eine neue ExtendedExecutionSession erstellt und mit einen Grund und eine Beschreibung angegeben. Zuweisen des korrekten Ressourcensatzes für die Anwendung (die Menge von Arbeitsspeicher, CPU und Ausführungszeit zulässige ist) und verfügbar zu machen Informationen über den Benutzer Programme im Hintergrund ausgeführten, werden diese beiden Eigenschaften verwendet. Die Anwendung dann nimmt einen Revocation-Ereignishandler, der aufgerufen wird, wenn Windows nicht mehr die Erweiterung, z. B. unterstützt, wenn eine andere Aufgabe mit hoher Priorität, z. B. eine Anwendung im Vordergrund oder ein VoIP-Anruf die Ressourcen benötigt. Schließlich die Anwendung fordert die Erweiterung und, falls erfolgreich, beginnt seine Save Vorgang. Wenn die Erweiterung verweigert wird, führt die Anwendung einen Vorgang anhalten, als ob sie die Erweiterung an, wie eine reguläre Aussetzung Ereignis empfangen hadn't.

Abbildung 3 erweitert die Ausführung im OnSuspending-Handler

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
  var deferral = e.SuspendingOperation.GetDeferral();
  using (var session = new ExtendedExecutionSession())
  {
    session.Reason = ExtendedExecutionReason.SavingData;
    session.Description = "Upload Data";
    session.Revoked += session_Revoked;
    var result = await session.RequestExtensionAsync();
    if (result == ExtendedExecutionResult.Denied)
    {
      UploadBasicData();
    }
    // Upload Data
    var completionTime = await UploadDataAsync(session);
  }
  deferral.Complete();
}

Abbildung 4 zeigt die Auswirkung, dies für den Lebenszyklus der app hat, vergleichen sie Abbildung 2. Wenn eine Anwendung ein Ereignis Unterbrechung erhält, beginnt oder serialisieren Ressourcen freizugeben. Wenn die app feststellt, dass sie mehr Zeit benötigt, und nimmt eine Erweiterung, bleibt es im Status "angehalten", bis die Erweiterung aufgehoben wird.

Ressourcenverwendung während der Ausführung der erweiterten
Abbildung 4 Ressourcenverwendung während der Ausführung der erweiterten

Wie bereits erwähnt, für den Fall, dass Sie 2, Ausführung Schlüsseldateien nicht nur in der Handler für die Unterbrechung angefordert wird; Es kann jederzeit angefordert werden, während die Anwendung ausgeführt wird. Dies ist nützlich, wenn die Anwendung im Voraus bekannt, sie benötigen ist, um weiter im Hintergrund ausgeführt wird wie bei der zuvor erwähnten Navigations-app. Der Code ist mit dem vorherigen Beispiel sehr ähnlich, und sehen Sie in Abbildung 5.

Abbildung 5: Erweiterte Ausführung während der normalen Ausführung

private async void StartTbTNavigationSession()
{
  using (var session = new ExtendedExecutionSession())
  {
    session.Reason = ExtendedExecutionReason.LocationTracking;
    session.Description = "Turn By Turn Navigation";
    session.Revoked += session_Revoked;
    var result = await session.RequestExtensionAsync();
    if (result == ExtendedExecutionResult.Denied
    {
      ShowUserWarning("Background location tracking not available");
    }
    // Do Navigation
    var completionTime = await DoNavigationSessionAsync(session);
  }
}

Abbildung 6 des Anwendungslebenszyklus für dieses Szenario veranschaulicht. In diesem Fall ist es sehr ähnlich. der Unterschied besteht darin, dass wenn die Erweiterung für die Ausführung gesperrt wird, die Anwendung wahrscheinlich schnell über den angehaltenen Zustand in den nicht ausgeführten Status wechseln kann. Dies geschieht, da in diesem Fall in der Regel die Erweiterung aufgrund knapper, eine Situation, die nur verringert werden kann, indem Sie die Freigabe von Ressourcen aufgehoben wird (die die app aus dem Arbeitsspeicher entfernt wird,).

Ressourcenverwendung während der Ausführung der erweiterten
Abbildung 6 Ressourcenverwendung während der Ausführung der erweiterten

Hintergrundaufgaben

Es gibt eine andere Möglichkeit, eine Anwendung im Hintergrund ausgeführt werden kann, und, die als Hintergrundtask ist. Hintergrundaufgaben sind separate Komponenten in einer Anwendung, die die IBackgroundTask-Schnittstelle implementieren. Diese Komponenten können ohne aufwändige Benutzeroberflächen-Frameworks ausgeführt werden und (obwohl sie auch prozessintern mit der primären ausführbaren Anwendung ausgeführt werden können) in der Regel in einem separaten Prozess ausgeführt.

Eine Hintergrundtask wird ausgeführt, wenn es sich bei der zugeordnete Trigger ausgelöst wird. Ein Trigger ist eine Systemereignis, das ausgelöst werden kann, und aktivieren eine app, selbst wenn die app nicht ausgeführt wird. Beispielsweise kann die TimeTrigger mit einem bestimmten Zeitraum (z. B. alle 30 Minuten) generiert werden, in diesem Fall würde die Anwendung im Hintergrundtask aktivieren, alle 30 Minuten, wenn der Trigger ausgelöst wird. Es gibt viele Triggertypen von Windows, einschließlich dieser Hintergrund Triggertypen unterstützt: TimeTrigger, "pushnotificationtrigger", LocationTrigger, ContactStoreNotificationTrigger, BluetoothLEAdvertisementWatcherTrigger, UserPresent, InternetAvailable und PowerStateChange.

Eine Hintergrundaufgabe ist drei Schritte: Die Komponente muss erstellt werden, und klicken Sie dann im Anwendungsmanifest deklariert und dann zur Laufzeit registriert werden.

Hintergrundaufgaben werden in der Regel in separate Windows-Runtime (WinRT) Komponente-Projekte in der gleichen Projektmappe wie das UI-Projekt implementiert. Dadurch wird die Hintergrundaufgabe in einem separaten Prozess, reduzieren den Aufwand von der Komponente erforderlichen Speicher aktiviert werden. Zeigt eine einfache Implementierung einer IBackgroundTask Abbildung 7. IBackgroundTask ist eine einfache Benutzeroberfläche, die nur eine Methode definiert ausführen. Dies ist die Methode, die aufgerufen wird, wenn die Hintergrundaufgabe Trigger ausgelöst wird. Der Parameter der Methode nur ist ein IBackgroundTaskInstance-Objekt, das über die Aktivierung (z. B. die Nutzlast einer zugeordneten Pushbenachrichtigung oder die Aktion, die durch eine Popupbenachrichtigung verwendet) und Ereignishandler behandeln Lebenszyklusereignisse wie z. B. Abbruch enthält. Die Run-Methode abgeschlossen ist, wird die Hintergrundaufgabe beendet. Wie in der zuvor gezeigten Aussetzung-Handler aus diesem Grund ist es wichtig, das Rückstellung-Objekt (auch aus der IBackgroundTaskInstance hängenden) verwendet wird, wenn Ihr Code asynchron ist.

Abbildung 7: eine BackgroundTask-Implementierung

public sealed class TimerTask : IBackgroundTask
{
  public void Run(IBackgroundTaskInstance taskInstance)
  {
    var deferral = taskInstance.GetDeferral();
    taskInstance.Canceled += TaskInstance_Canceled;
    await ShowToastAsync("Hello from Background Task");
    deferral.Complete();
  }
  private void TaskInstance_Canceled(IBackgroundTaskInstance sender,
    BackgroundTaskCancellationReason reason)
  {
    // Handle cancellation
    deferral.Complete();
  }
}

Im Anwendungsmanifest muss auch die Hintergrundaufgabe registriert werden. Diese Registrierung teilt Windows den Triggertyp, den Einstiegspunkt und der ausführbaren Datei gehostet des Tasks wie folgt:

<Extensions>
  <Extension Category="windows.backgroundTasks" EntryPoint="BackgroundTasks.TimerTask">
    <BackgroundTasks>
      <Task Type="timer" />
    </BackgroundTasks>
  </Extension>

Dies kann auch ohne den Einstieg in XML mit der manifest-Designer in Visual Studio enthaltenen erfolgen.

Schließlich die Aufgabe muss auch zur Laufzeit registriert werden, und dies sehen Sie in Abbildung 8. Hier verwenden Sie das BackgroundTaskBuilder-Objekt, registrieren Sie die Aufgabe mit einer TimeTrigger, die alle 30 Minuten ausgelöst werden, wenn im Internet verfügbar ist. Dies ist der ideale Typ des Triggers für allgemeine Operationen wie Aktualisierung einer Kachel oder kleine Datenmengen in regelmäßigen Abständen zu synchronisieren.

Abbildung 8 Hintergrund Task-Registrierung

private void RegisterBackgroundTasks()
{
  BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
  builder.Name = "Background Test Class";
  builder.TaskEntryPoint = "BackgroundTaskLibrary.TestClass";
  IBackgroundTrigger trigger = new TimeTrigger(30, true);
  builder.SetTrigger(trigger);
  IBackgroundCondition condition =
    new SystemCondition(SystemConditionType.InternetAvailable);
  builder.AddCondition(condition);
  IBackgroundTaskRegistration task = builder.Register();
  task.Progress += new BackgroundTaskProgressEventHandler(task_Progress);
  task.Completed += new BackgroundTaskCompletedEventHandler(task_Completed);
}

Der größte Vorteil von Hintergrundaufgaben kann auch ihre schädlich sein: Da Hintergrundaufgaben, die im Hintergrund (wenn der Benutzer möglicherweise etwas Wichtiges, im Vordergrund tut oder das Gerät in den Standbymodus ist) ausgeführt werden, sind sie stark eingeschränkt Menge an Arbeitsspeicher und CPU-Zeit, die sie verwenden können. Z. B. Hintergrundtask registriert Abbildung 8 wird nur für 30 Sekunden ausgeführt und kann nicht mehr als 16MB des Arbeitsspeichers auf Geräten mit 512MB Arbeitsspeicher; nutzen die Speicherbereiche Skalieren mit der Menge an Arbeitsspeicher auf dem Gerät. Beim Entwickeln und Implementieren von Hintergrundaufgaben, ist es wichtig, dies zu berücksichtigen. Hintergrundaufgaben sollten auf einer Vielzahl von Geräten, insbesondere preisgünstige Geräte getestet werden, bevor Sie eine Anwendung veröffentlichen. Es gibt ein paar andere Dinge ebenfalls beachtet werden:

  • Wenn der Akku Bildschirmschoner verfügbar und aktiviert ist (in der Regel bei der Akku unter einen bestimmten Schwellenwert der Kosten), werden verhindert, dass Hintergrundaufgaben ausführen, bis der Akku hinter den Akku Bildschirmschoner Schwellenwert Rudermaschinenraums ist.
  • In früheren Versionen von Windows Applications "auf die Sperre angeheftet werden muss", bevor sie wurden im Hintergrund und in einigen Fällen ausführen dürfen gab es eine maximale Anzahl von Hintergrundaufgaben, die registrierte, Gerät Wide werden konnte. Dies ist nicht mehr der Fall in Windows 10, aber eine app muss immer aufrufen, BackgroundExecutionManger.RequestAcessAsync zum Deklarieren von seiner Absicht, die im Hintergrund ausgeführt.

Ein besserer Ansatz zur Synchronisierung kontaktieren

Es gibt viele Hintergrundvorgänge abgeschlossen werden können, die mit einer längeren Ausführung oder Hintergrundaufgaben. In der Regel ist es besser, verwenden Sie wenn möglich Hintergrundaufgaben, zuverlässige und effizienter sind.

Z. B. das erwähnte Szenario – Synchronisieren von Daten beim ersten einer Anwendung Start – kann auch sein, und eine effizientere mit einer Hintergrundaufgabe, in diesem Fall mithilfe eines Triggers, der neuen Windows-10: die Anwendung Trigger.

ApplicationTrigger (z. B. DeviceUseTrigger) gehört eine Sonderklasse von Triggern, die direkt von der Vordergrund-Teil der Anwendung ausgelöst werden. Dies erfolgt durch explizites Aufrufen von RequestAsync für die Triggerobjekt. ApplicationTrigger eignet sich besonders für Szenarien, in denen die Anwendung benötigt, einen Vorgang im Vordergrund starten, die Ausführung im Hintergrund fortgesetzt werden soll, wenn die Anwendung nicht mehr im Vordergrund ist und Operation nicht eng gekoppelt mit den Vordergrund abhängig. Die folgenden zeigt ein Beispiel für eine Aufgabe ApplicationTrigger, die in den meisten Fällen anstelle von erweiterten Ausführung verwendet werden kann:

var appTrigger = new ApplicationTrigger();
var backgroundTaskBuilder = new BackgroundTaskBuilder();
backgroundTaskBuilder.Name = "App Task";
backgroundTaskBuilder.TaskEntryPoint = typeof(AppTask).FullName;
backgroundTaskBuilder.SetTrigger(appTrigger);
backgroundTaskBuilder.Register();
var result = await appTrigger.RequestAsync();

Nachbereitung

Dieser Artikel bietet eine Übersicht über die Ausführung der Anwendung Lebenszyklus und Hintergrund in Windows 10 und führt ein paar neue Mechanismen, mit denen apps im Hintergrund ausgeführt: Erweiterte Aufgaben ausführen und Hintergrund. Hintergrundaufgaben sind eine bessere Wahl für Low-End und eingeschränktem Arbeitsspeicher-Geräte (z. B. Mobiltelefone), während der Ausführung von erweiterten für High-End-Geräten (z. B. in desktop-PCs) besser geeignet ist.


Shawn Henryist leitender Programmmanager im Team universelle Windows-Plattform. Sie erreichen ihn auf Twitter: @shawnhenry.

Dank den folgenden technischen Experten von Microsoft für die Überprüfung dieses Artikels: Anis Mohammed Khaja Mohideen und Sheikh Abdul Hadi
Abdul Hadi Sheikh ist Softwareentwickler im Team universelle Windows-Plattform

Anis Mohammed Khaja Mohideen ist Senior-Softwareentwickler universelle Windows Platform-Team