Georg fährt extra nach Berlin um Steve Ballmer zu treffen

31 Tage Mango | Tag #24: Laufzeitanalyse

Dieser Artikel ist Tag #24 der Serie 31 Tage Mango von Jeff Blankenburg.

Der Originalartikel befindet sich hier: Day #24: Performance Analysis.

Dieser Artikel wurde in der Originalserie von Gastautor Chris Koenig geschrieben. Bei Twitter kann Chris unter @chriskoenig erreicht werden.

Das Betriebsverhalten ist eine wichtige Eigenschaft jeder Anwendung, besonders aber bei Anwendungen, die auf ressourcenbeschränkten, netzabhängigen mobilen Geräten laufen. Als Anwender sieht man relativ leicht, wenn eine Anwendung „langsam“ läuft – nicht so leicht ist es, festzustellen, warum die Anwendung sich so verhält. Änderungen am Source Code zu machen, ohne dass man die Ursachen des schlechten Laufzeitverhaltens wirklich verstanden hat, kann zu unnötigem Mehraufwand führen und das Problem sogar verschlimmern.

Also was machen? Seit der Veröffentlichung von Windows Phone Mango können wir den Gründen für schlechtes Laufzeitverhalten leicht auf die Spur kommen – bis runter zur einzelnen Methode. Hierfür verwenden wir das Werkzeug Windows Phone Profiler. Sie können das neue Windows Phone Profiler Werkzeug verwenden, um Probleme im Laufzeitverhalten zu identifizieren. Derartige Probleme können zum Beispiel Hauptspeicherverbrauch, Komplexität des Visual Trees, Dauer des Anwendungsstarts oder lang laufende Operationen sein.

Um die Leistungsanalyse zu starten, öffnen Sie Ihr Windows Phone Projekt im Visual Studio und wählen Sie „Start Windows Phone Performance Analysis“ aus dem Debug Menü oder drücken Sie Alt-F1:

Achtung: Verwechseln Sie den Windows Phone Profiler nicht mit dem .NET Profiler, welcher ebenfalls im Debug Menü unter „Start performance analysis (Alt-F2)“ zu finden ist.

Als erstes werden Sie gefragt, was für eine Art von Analyse Sie durchführen möchten. Wenn Sie sich nicht ganz sicher sind, dass es sich um ein Speicherproblem handelt, sollten Sie die Execution Analysis starten:

Wenn Sie das Link „Launch Application“ klicken, wird die Anwendung entweder im Emulator oder auf dem echten Gerät gestartet. Dabei wird automatisch der Analysecode hinzugefügt. Sobald die Anwendung gestartet ist, führen Sie diejenigen Funktionen der Anwendung aus, die am ressourcenhungrigsten sind oder die Ihre Anwender am häufigsten verwenden werden. Während Sie die Anwendung benutzen, werden vom Visual Studio automatisch Leistungsdaten eingesammelt und aufgezeichnet.

Sobald Sie Ihren Testlauf abgeschlossen haben, wechseln Sie zurück ins Visual Studio und klicken auf das Link „Stop Profiling“:

Jetzt wird das Visual Studio alle aufgezeichneten Leistungsdaten in eine .SAP Datei speichern und diese zu Ihrem Projekt hinzufügen. Der Dateiname beinhaltet den Namen des Projekts und den Zeitpunkt des Tests (z.B. DatabaseForMango_2011_11_14_17_59_27.sap). Diese Aufzeichnung kann sofort oder später betrachtet werden. In der Hauptansicht der Ergebnisse sehen Sie die verschiedenen Diagramme, die zur Verfügung stehen. Die Diagramme repräsentieren eine Reihe verschiedener Messungen, die übereinander angezeigt werden um einen zeitlichen Verlauf der Leistung Ihrer Anwendung darzustellen.

Von oben nach unten zeigen die Diagramme:

  • Bildfrequenz – Dies zeigt die aufgezeichnete Bildfrequenz. Niedrige Werte hier sind mögliche Problemstellen und sollten etwas näher untersucht werden.
  • CPU Auslastung % – Zeigt die CPU Auslastung für verschiedene Bereiche der Anwendung
    • Grüne Balken repräsentieren den UI Thread – dieser verdient besondere Aufmerksamkeit, da eine hohe Auslastung des UI Threads die Benutzeroberfläche ins Stocken bringt. Jeder Wert über 50% ist ein potenzieller Problembereich.
    • Blaue Balken repräsentieren Anwendungsthreads – das schließt selbst erstellte Background-Threads und den Composition Thread ein. Je mehr hier und nicht auf dem UI Thread stattfindet, umso besser.
    • Graue Balken repräsentieren Systemthreads – dies sind Threads, die NICHT Teil Ihrer Anwendung sind. Sie repräsentieren Dinge wie Background Tasks, usw.
    • Weiße Balken repräsentieren Threads im Leerlauf – z.B. der „System Idle Process“, den man auch aus dem Windows Task Manager kennt. Da dieser Wert mit der freien CPU Kapazität korrespondiert, bedeuten höhere Werte hier eine flüssigere Benutzeroberfläche.
  • Speicherverbrauch in MB – Wenn Sie hier zu irgendeinem Zeitpunkt mehr als 90 MB verbrauchen, führen Sie den anderen Test aus – 90 MB sind das Maximum für eine erfolgreiche Zertifizierung im Marketplace.
  • Storyboards – Ein „S“ wird immer dann angezeigt, wenn ein Storyboard gestartet wurde.
    • Rot repräsentiert auf der CPU ausgeführte Storyboards (da sie auf der CPU ausgeführt werden, haben diese direkt einen schlechten Einfluss auf die Leistungsfähigkeit der Benutzerschnittstelle)
    • Lila repräsentiert auf der GPU ausgeführte Storyboards (diese sind gut, da sie auf dem Compositor Thread ausgeführt werden und keinen direkten Einfluss auf das Verhalten der Benutzerschnittstelle haben).
  • Laden von Bildern – Ein „I“ wird immer dann angezeigt, wenn ein Bild in den Speicher geladen wurde.
  • Garbage Collection Events – Ein „G“ wird immer dann angezeigt, wenn der Garbage Collector gelaufen ist.

Um Details zu den Daten hinter den Diagrammen zu sehen, benutzen Sie die Maus und wählen Sie den Bereich, den Sie näher untersuchen möchten. Im unteren Bereich, der „Detailed Performance Analysis“, werden Warnungen und informative Nachrichten angezeigt, die auf mögliche Probleme im ausgewählten Bereich hinweisen:

In dem Bild oben sehen sie zwei Warnungen im Zusammenhang mit der Bildfrequenz. Die erste Warnung im Bild oben enthält beispielsweise die folgende Information:

Warning: Very low frame rate potentially caused by a high layout cost.

Total layout time (0.35 seconds) is high. Element System.Windows.Controls.ScrollViewer : ScrollViewer took the most time in layout and is contributing to the low frame rate. This could be because CPU-bound animations are causing layout updates. Go to the Performance Warnings menu in the navigation toolbar and select the Frames view. Sort the frames by clicking the CPU Time column header and select the frames with the highest CPU time. From the Frames view, select the Visual Tree option and identify visual System.Windows.Controls.ScrollViewer : ScrollViewer in the tree.

Diese Warnung bezieht sich auf eine niedrige Bildwiederholfrequenz im Zusammenhang mit dem Aufbau des Layouts im ScrollViewer. Die vorgeschlagene Aktion ist die Wahl der Frames Ansicht im Performance Warnings Menü. Wenn Sie den Bereich Detailed Performance genauer ansehen, sehen Sie direkt neben dem Eintrag Performance Warnings einen Button für ein pop-up Menü, durch welches Sie „tiefer graben“ können. Wenn Sie die Option „Frames“ wählen, werden Sie etwa folgendes sehen:

Die Liste der ausgewählten einzelnen Frames offenbart, dass ziemlich viele davon eine CPU Auslastung deutlich über 50% haben – in unserem Fall sogar einer mit über 80%. Wenn wir diesen Frame auswählen und dann zurück zum Navigationsmenü neben dem Eintrag Frames von gerade eben, sehen wir, dass wir für diesen Frame noch mehr Details ansehen können. Wählen Sie die einzelnen Einträge aus dem Menü, um mehr Details zu den Vorgängen in diesem Frame zu bekommen. Wenn Sie beispielsweise die Option Functions wählen, bekommen Sie die aufgerufenen Methoden Ihrer Anwendung angezeigt (mit Verknüpfungen direkt zurück in den betreffenden Source Code). Sie können sich auch den Visual Tree, Elementtypen und Cache Updates ansehen. Die Fehlermeldungen (zusammen mit den Tipps für das weitere Vorgehen) und die Möglichkeit, auf der Suche nach Problemen in die Tiefen der Anwendung vorzustoßen, geben Ihnen die Möglichkeit, potenzielle Problemfelder zu entdecken und zu beseitigen, bevor Sie die Anwendung zur Zertifizierung im Marketplace einreichen.

Jetzt, wo Sie gesehen haben, wie das Werkzeug funktioniert, sind hier noch ein paar Tipps um schneller zu einer schnelleren Anwendung zu kommen:

  • Fangen Sie mit den Execution Performance Tests an um zu sehen, ob es mögliche Speicherengpässe gibt. Dies würden Sie im Speicherverbrauchsdiagramm erkennen. Wenn Sie Phasen während der Laufzeit der Anwendung haben, in denen diese mehr als 90 MB Speicher verbraucht, starten Sie den zweiten Test welcher sich speziell auf Speicherprobleme konzentriert. Sie werden feststellen, dass alle anderen Probleme im Laufzeitverhalten normalerweise mit dem ersten Test diagnostiziert werden können. Den zweiten brauchen Sie nur, wenn die Daten im ersten Test diesen speziellen Test rechtfertigen.
  • Vergessen Sie nicht, Fast Application Switching, Tombstoning und den entsprechenden Aktivierungsprozess zu testen. Das sind wichtige Bereiche Ihrer Anwendung. Um das Tombstoning in Ihrer Anwendung zu erzwingen, gehen Sie in die Eigenschaften des Projekts und aktivieren Sie auf dem Reiter Debug die Checkbox „Tombstone upon deactivation while debugging“. Andernfalls wird Ihre Anwendung normal das Fast Application Switching nutzen.
  • Machen Sie die Leistungsanalyse immer auf einem realen Gerät – die Leistung des Emulators ist nicht vergleichbar mit der Leistung eines tatsächlichen Geräts. Ein echtes Windows Phone Gerät hat wesentlich beschränktere Ressourcen als ein normaler Entwicklungs-PC. Speicher- und Geschwindigkeitsprobleme sind also auf einem echten Gerät wahrscheinlicher als im Emulator. Die Ausführung der Tests auf einem echten Gerät funktioniert genau so wie das Debuggen auf einem echten Gerät. Ändern Sie einfach den Deployment Target von „Windows Phone Emulator“ auf „Windows Phone Device“ oben in der Visual Studio Toolbar.

Zusammenfassung

Hier sind einige Links zu weiteren Quellen zur Windows Phone Leistungsanalyse:

Morgen wird Gary Johnson über Background Agents schreiben. Wir werden sehen, wie wir dieses neue Feature in Windows Phone 7.5 nutzen können, um Code auszuführen auch wenn die Anwendung nicht läuft.

Bis dahin!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.