Freigeben über


Leistungsplanung

Benutzer erwarten, dass ihre Apps reaktionsfähig bleiben, eine natürliche Benutzererfahrung bieten und den Akku nicht entladen. Technisch gesehen ist die Leistung eine nicht funktionale Anforderung, aber die Behandlung der Leistung als Feature hilft Ihnen, die Erwartungen Ihrer Benutzer zu erfüllen. Die Festlegung von Zielen und Die Messung sind wichtige Faktoren. Ermitteln Sie, welche Szenarien leistungskritisch sind; definieren Sie, was eine gute Leistung bedeutet. Messen Sie dann früh und oft genug während des gesamten Lebenszyklus Ihres Projekts, um sicher zu sein, dass Sie Ihre Ziele erreichen werden.

Angeben von Zielen

Die Benutzererfahrung ist eine einfache Möglichkeit, um eine gute Leistung zu definieren. Die Startzeit einer App kann die Wahrnehmung der Leistung eines Benutzers beeinflussen. Ein Benutzer kann eine App-Startzeit von weniger als einer Sekunde als hervorragend betrachten, weniger als 5 Sekunden gut sein und mehr als 5 Sekunden schlecht sein.

Andere Metriken haben weniger offensichtliche Auswirkungen auf die Benutzererfahrung, z. B. Arbeitsspeicher. Die Wahrscheinlichkeit, dass eine App beendet wird, während sie angehalten oder inaktiv ist, steigt mit der Von der aktiven App verwendeten Arbeitsspeichermenge. Es ist eine allgemeine Regel, dass eine hohe Speicherauslastung die Erfahrung für alle Apps auf dem System beeinträchtigt, sodass ein Ziel für die Speicherauslastung angemessen ist. Berücksichtigen Sie die grobe Größe Ihrer App, die von Benutzern wahrgenommen wird: klein, mittel oder groß. Erwartungen an die Leistung korrelieren mit dieser Wahrnehmung. Zum Beispiel möchten Sie möglicherweise eine kleine App, die nicht viele Medieninhalte verwendet, um weniger als 100 MB Arbeitsspeicher zu verbrauchen.

Es ist besser, ein erstes Ziel festzulegen und es später zu überarbeiten, als überhaupt kein Ziel zu haben. Die Leistungsziele Ihrer App sollten spezifisch und messbar sein, und sie sollten in drei Kategorien fallen: wie lange es dauert, bis Benutzer oder die App Aufgaben ausführen (Zeit); die Rate und Kontinuität, mit der sich die App als Reaktion auf benutzerinteraktion (Flüssigkeit) neu gezeichnet hat; und wie gut die App Systemressourcen spart, einschließlich Akkuleistung (Effizienz).

Uhrzeit

Denken Sie an die zulässigen Bereiche der verstrichenen Zeit (Interaktionsklassen), die Benutzer benötigen, um ihre Aufgaben in Ihrer App abzuschließen. Für jede Interaktionsklasse weisen Sie eine Bezeichnung, eine wahrgenommene Benutzerstimmung und ideale und maximale Dauer zu. Hier sind einige Vorschläge.

Bezeichnung der Interaktionsklasse Benutzerwahrnehmung Ideal Höchstwert Beispiele
Schnell Minimal spürbare Verzögerung 100 Millisekunden 200 Millisekunden App-Leiste aufrufen; eine Taste drücken (erste Aktion)
Typisch Schnell, aber nicht rasch 300 Millisekunden 500 Millisekunden Größe ändern; Semantischer Zoom
Ansprechbar Nicht schnell, aber reaktionsfähig 500 Millisekunden 1 Sekunde Wechseln Sie zu einer anderen Seite; setzen Sie die App aus dem Ruhezustand fort
Abschießen Wettbewerbserfahrung 1 Sekunde 3 Sekunden Starten Sie die App zum ersten Mal oder nachdem sie zuvor beendet wurde
Stetig Fühlt sich nicht mehr reaktionsfähig 500 Millisekunden 5 Sekunden Herunterladen einer Datei aus dem Internet
Gefangene Person Lang; Benutzer könnten absteigen 500 Millisekunden 10 Sekunden Installieren mehrerer Apps aus dem Store

 

Sie können nun den Leistungsszenarien Ihrer App Interaktionsklassen zuweisen. Sie können die zeitpunktbezogene Referenz der App, einen Teil der Benutzererfahrung und eine Interaktionsklasse jedem Szenario zuweisen. Hier sind einige Vorschläge für eine Beispiel-App für Lebensmittel und Restaurants.

SzenarioZeitpunktBenutzerfreundlichkeitInteraktionsklasse
Navigieren zur Rezeptseite Erste AntwortSeitenübergangsanimation gestartetSchnell (100-200 Millisekunden)
AnsprechbarZutatenliste geladen; keine BilderReaktionsfähig (500 Millisekunden - 1 Sekunde)
Vollständig sichtbarAlle Inhalte geladen; Bilder angezeigtFortlaufend (500 Millisekunden - 5 Sekunden)
Nach Rezept suchenErste AntwortSchaltfläche "Suchen" geklicktSchnell (100 - 200 Millisekunden)
Vollständig sichtbarListe der angezeigten lokalen RezepttitelTypisch (300 - 500 Millisekunden)

Wenn Sie Liveinhalte anzeigen, sollten Sie auch die Ziele zur Aktualität der Inhalte berücksichtigen. Ist das Ziel, Inhalte alle paar Sekunden zu aktualisieren? Oder ist das Aktualisieren von Inhalten alle paar Minuten, alle paar Stunden oder sogar einmal pro Tag eine akzeptable Benutzererfahrung?

Mit den angegebenen Zielen können Sie Ihre App jetzt besser testen, analysieren und optimieren.

Flüssigkeit

Bestimmte messbare Ziele für die Benutzerfreundlichkeit Ihrer App könnten Folgendes umfassen:

  • Es werden keine Stopps und Starts des Bildschirms neu gezeichnet (Störungen).
  • Animationen werden mit 60 Frames pro Sekunde (FPS) gerendert.
  • Wenn ein Benutzer scrollt, zeigt die App 3-6 Seiten Inhalt pro Sekunde an.

Effizienz

Zu den spezifischen messbaren Effizienzzielen für Ihre App gehören u. U.:

  • Für den Prozess Ihrer App liegt der CPU-Prozentsatz bei oder unter N- und die Speicherauslastung in MB liegt bei oder unter M- zu jeder Zeit.
  • Wenn die App inaktiv ist, sind N und M für den Prozess Ihrer App null.
  • Ihre App kann aktiv für X Stunden beim Akkubetrieb verwendet werden; wenn Ihre App inaktiv ist, behält das Gerät seine Ladung für Y Stunden bei.

Gestalten Sie Ihre App für Leistung

Sie können jetzt Ihre Leistungsziele verwenden, um den Entwurf Ihrer App zu beeinflussen. Wenn Sie die Beispiel-App für Lebensmittel und Restaurants verwenden, können Sie nach dem Navigieren zum Rezept zur Rezeptseite auswählen, dass Sie Elemente inkrementell aktualisieren möchten, damit der Name des Rezepts zuerst gerendert wird, das Anzeigen der Zutaten verzögert wird und das Anzeigen von Bildern weiter verzögert wird. Dadurch bleibt die Reaktionsfähigkeit und eine dynamische Benutzeroberfläche während des Schwenkens/Bildlaufs erhalten, wobei das Rendering in voller Genauigkeit erfolgt, nachdem sich die Interaktion auf ein Tempo verlangsamt hat, mit dem der UI-Thread aufholen kann. Hier sind einige andere Aspekte zu berücksichtigen.

BENUTZEROBERFLÄCHE

  • Maximieren Sie die Analyse- und Ladezeit und Speichereffizienz für jede Seite der Benutzeroberfläche Ihrer App (insbesondere die erste Seite), indem Sie Ihr XAML-Markupoptimieren. Kurz gesagt: Verzögern Sie das Laden der Benutzeroberfläche und des Codes, bis sie benötigt wird.
  • Für ListView und GridView; machen Sie alle Elemente gleich groß und Verwenden Sie möglichst viele ListView- und GridView-Optimierungstechniken.
  • Deklarieren Sie die Benutzeroberfläche in Form von Markup, das das Framework in Blöcken laden und wiederverwenden kann, anstatt sie im Code zwingend zu erstellen.
  • Verzögern Sie das Erstellen von UI-Elementen, bis der Benutzer sie benötigt. Siehe das Attribut x:Load.
  • Bevorzugen Sie Designübergänge und Animationen gegenüber Storyboard-Animationen. Weitere Informationen finden Sie unter Animationsübersicht. Denken Sie daran, dass Storyboardanimationen konstante Aktualisierungen auf dem Bildschirm erfordern und die CPU- und Grafikpipeline aktiv halten. Um den Akku zu erhalten, werden keine Animationen ausgeführt, wenn der Benutzer nicht mit der App interagiert.
  • Bilder, die Sie laden, sollten in einer für die Ansicht geeigneten Größe geladen werden, in der Sie es präsentieren, und zwar mithilfe der GetThumbnailAsync--Methode.

CPU, Arbeitsspeicher und Leistung

  • Planen Sie weniger wichtige Arbeiten, um sie auf Threads und/oder Kernen mit niedriger Priorität ausführen zu lassen. Siehe Asynchrone Programmierung, die eigenschaft Dispatcher und die CoreDispatcher Klasse.
  • Minimieren Sie den Speicherbedarf Ihrer App, indem Sie teure Ressourcen (z. B. Medien) beim Anhalten freigeben.
  • Minimieren Sie den Arbeitssatz Ihres Codes.
  • Vermeiden Sie Speicherverluste, indem Sie die Registrierung von Ereignishandlern aufheben und Referenzen auf UI-Elemente, wann immer möglich, entfernen.
  • Im Interesse der Akkulebensdauer sollten Sie sparsam damit umgehen, wie oft Sie Daten abrufen, einen Sensor abfragen oder Tasks auf der CPU einplanen, wenn sie im Leerlauf ist.

Datenzugriff

  • Wenn möglich, Inhalte vorab abrufen. Informationen zum automatischen Vorabrufen finden Sie in der ContentPrefetcher Klasse. Informationen zum manuellen Vorabrufen finden Sie unter dem Windows.ApplicationModel.Background Namespace und der MaintenanceTrigger Klasse.
  • Speichern Sie nach Möglichkeit Inhalte zwischen, deren Zugriff kostenintensiv ist. Siehe die Eigenschaften LocalFolder und LocalSettings.
  • Zeigen Sie bei Cachefehlern so schnell wie möglich eine Platzhalterbenutzeroberfläche an, die angibt, dass die App weiterhin Inhalte lädt. Übergang von Platzhalter zu echten Inhalten auf eine Weise, die für den Benutzer nicht unangenehm ist. Ändern Sie beispielsweise nicht die Position von Inhalten unter dem Finger oder Mauszeiger des Benutzers, wenn die App Liveinhalte lädt.

App starten und fortsetzen

Adaptive Benutzeroberfläche und Ausrichtung

  • Verwenden Sie die VisualStateManager Klasse.
  • Erledigen Sie nur die erforderliche Arbeit sofort und verschieben Sie intensive App-Arbeiten auf später – Ihre App hat zwischen 200 und 800 Millisekunden, um die Arbeit abzuschließen, bevor der Benutzer die Benutzeroberfläche Ihrer App in einem beschnittenen Zustand sieht.

Mit Ihren leistungsbezogenen Designs können Sie mit dem Programmieren Ihrer App beginnen.

Instrument zur Leistungsbewertung

Fügen Sie beim Programmieren Code hinzu, der Nachrichten und Ereignisse an bestimmten Stellen protokolliert, während die App ausgeführt wird. Wenn Sie Ihre App später testen, können Sie Profilerstellungstools wie Windows Performance Recorder und Windows Performance Analyzer verwenden (beide sind im Windows Performance Toolkitenthalten), um einen Bericht über die Leistung Ihrer App zu erstellen und anzuzeigen. In diesem Bericht können Sie nach diesen Nachrichten und Ereignissen suchen, damit Sie die Ergebnisse des Berichts einfacher analysieren können.

Die Universelle Windows-Plattform (UWP) stellt Protokollierungs-APIs bereit, die von Ereignisablaufverfolgung für Windows (ETW)unterstützt werden und zusammen eine umfassende Lösung für die Ereignisprotokollierung und -nachverfolgung bieten. Die APIs, die Teil des Windows.Foundation.Diagnostics Namespace sind, beinhalten die Klassen FileLoggingSession, LoggingActivity, LoggingChannelund LoggingSession.

Um eine Nachricht in dem Bericht an einem bestimmten Punkt zu protokollieren, während die App ausgeführt wird, erstellen Sie ein LoggingChannel--Objekt, und rufen Sie dann die LogMessage--Methode des Objekts auf, wie hier gezeigt.

// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here' s my logged message.");

// ...

Um Start- und Stoppereignisse über einen Zeitraum hinweg im Bericht zu protokollieren, während die App läuft, erstellen Sie ein LoggingActivity--Objekt und rufen Sie dann den LoggingActivity-Konstruktor des Objekts auf.

// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...

Siehe auch das Protokollierungsbeispiel.

Wenn Ihre App instrumentiert ist, können Sie deren Leistung testen und messen.

Testen und Messen im Hinblick auf Leistungsziele

Teil Ihres Leistungsplans besteht darin, die Punkte während der Entwicklung zu definieren, in denen Sie die Leistung messen. Dies dient verschiedenen Zwecken, je nachdem, ob Sie während der Prototypenphase, Entwicklung oder Bereitstellung messen. Die Messung der Leistung in den frühen Phasen der Prototyperstellung kann enorm wertvoll sein, daher empfehlen wir, dies zu tun, sobald Sie Code haben, der sinnvolle Arbeit leistet. Frühe Messungen geben Ihnen eine gute Vorstellung davon, wo sich die wichtigen Kosten in Ihrer App befinden, und helfen Ihnen bei der Entscheidung über das Design. Dies führt zu leistungsstarken und skalierungsstarken Apps. Es ist im Allgemeinen teurer, Entwürfe später als früher zu ändern. Das Messen der Leistung spät im Produktzyklus kann zu Last-Minute-Hacks und schlechter Leistung führen.

Verwenden Sie diese Techniken und Tools, um zu testen, wie Ihre App ihren ursprünglichen Leistungszielen entspricht.

  • Testen Sie eine breite Palette von Hardwarekonfigurationen, einschließlich All-in-One- und Desktop-PCs, Laptops, Ultrabooks, Tablets und anderen mobilen Geräten.
  • Testen Sie gegen eine Vielzahl von Bildschirmgrößen. Während größere Bildschirmgrößen viel mehr Inhalt anzeigen können, kann das Hinzufügen all dieses zusätzlichen Inhalts die Leistung negativ beeinflussen.
  • Entfernen Sie so viele Testvariablen wie möglich.
    • Deaktivieren Sie Hintergrund-Apps auf dem Testgerät. Wählen Sie dazu im Startmenü in Windows Einstellungen>Personalisierung>Sperrbildschirmaus. Wählen Sie jede aktive App aus und entscheiden Sie sich für Keine.
    • Kompilieren Sie Ihre App in systemeigenem Code, indem Sie sie in der Releasekonfiguration erstellen, bevor Sie sie auf dem Testgerät bereitstellen.
    • Um sicherzustellen, dass sich die automatische Wartung nicht auf die Leistung des Testgeräts auswirkt, lösen Sie es manuell aus, und warten Sie, bis es abgeschlossen ist. Suchen Sie im Startmenü von Windows nach Sicherheit und Wartung. Wählen Sie im Bereich Wartung unter Automatische WartungWartung starten aus, und warten Sie, bis sich der Status von Wartung in Bearbeitungändert.
    • Führen Sie die App mehrmals aus, um zufällige Testvariablen zu beseitigen und konsistente Messungen zu gewährleisten.
  • Testen Sie die Verfügbarkeit reduzierter Energie. Das Gerät Ihrer Benutzer hat möglicherweise deutlich weniger Leistung als Ihr Entwicklungscomputer. Windows wurde unter Berücksichtigung von Geräten mit geringem Stromverbrauch entwickelt, z. B. mobilen Geräten. Apps, die auf der Plattform ausgeführt werden, sollten sicherstellen, dass sie auf diesen Geräten gut funktionieren. Als grobe Faustregel können Sie erwarten, dass ein Gerät mit geringem Stromverbrauch etwa mit einem Viertel der Geschwindigkeit eines Desktopcomputers arbeitet, und richten Sie Ihre Ziele entsprechend aus.
  • Verwenden Sie eine Kombination aus Tools wie Microsoft Visual Studio und Windows Performance Analyzer, um die App-Leistung zu messen. Visual Studio wurde entwickelt, um App-fokussierte Analysen bereitzustellen, z. B. Quellcodeverknüpfungen. Windows Performance Analyzer wurde entwickelt, um systemorientierte Analysen bereitzustellen, wie Systeminformationen, Informationen zu Touch-Manipulationsereignissen sowie Kosten für Datenträger-Eingabe/Ausgabe (I/O) und Grafikverarbeitungseinheit (GPU). Beide Tools bieten Ablaufverfolgungserfassung und -export und können freigegebene und post mortem-Ablaufverfolgungen erneut öffnen.
  • Bevor Sie Ihre App zur Zertifizierung an den Store übermitteln, sollten Sie unbedingt die leistungsbezogenen Testfälle in Ihre Testpläne integrieren, wie im Abschnitt "Leistungstests" des Zertifizierungskits für Windows-Apps und im Abschnitt "Leistung und Stabilität" von UWP-App-Testfällenbeschrieben.

Weitere Informationen finden Sie in diesen Ressourcen und Profilerstellungstools.

Reagieren auf die Leistungstestergebnisse

Ermitteln Sie nach der Analyse der Leistungstestergebnisse, ob Änderungen erforderlich sind, z. B.:

  • Sollten Sie Ihre App-Entwurfsentscheidungen ändern oder Ihren Code optimieren?
  • Sollten Sie eine der Instrumentierungen im Code hinzufügen, entfernen oder ändern?
  • Sollten Sie Ihre Leistungsziele überarbeiten?

Wenn Änderungen erforderlich sind, nehmen Sie sie vor, und kehren Sie dann zu Instrumentierung oder Tests zurück, und wiederholen Sie sie.

Optimierung

Optimieren Sie nur die leistungskritischen Codepfade in Ihrer App: diejenigen, für die die meiste Zeit aufgewendet wird. Die Profilerstellung zeigt Ihnen, welche. Häufig besteht ein Kompromiss zwischen der Erstellung von Software, die bewährten Entwurfspraktiken folgt, und dem Schreiben von Code, der bei der höchsten Optimierung ausgeführt wird. Es ist in der Regel besser, Die Produktivität von Entwicklern und ein gutes Softwaredesign in Bereichen zu priorisieren, in denen die Leistung keine Rolle spielt.