Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Fensterübergänge mit Winscope erfassen

Winscope ist ein Webtool, mit dem Nutzer die Status verschiedener Systemdienste während und nach Animationen und Übergängen aufzeichnen, wiedergeben und analysieren können. Winscope zeichnet alle relevanten Systemdienststatus in einer Tracedatei auf. Mit der Winscope-Benutzeroberfläche und der Tracedatei können Sie den Status dieser Dienste für jeden Animationsframe mit oder ohne Bildschirmaufzeichnung prüfen, indem Sie die Übergänge wiedergeben, schrittweise durchlaufen und debuggen.

Unterstützte Traces

Mit Winscope können Sie verschiedene Traces oder Sequenzen von Systemdienststatus erfassen und visuell darstellen. Sie können diese Traces für bestimmte Anwendungsfälle konfigurieren, von geringem Overhead bis hin zu hoher Ausführlichkeit. Die folgenden Traces werden von Winscope unterstützt:

EventLog:Erfassen Sie den Systemdiagnose-Ereignisdatensatz mit EventLog. In Winscope werden diese Informationen nur verwendet, um CUJ-Markierungen zu identifizieren und anzuzeigen.
IME:Trace-Ereignisse aus der IME-Pipeline (Input Method Editor), einschließlich IMS, IMMS und IME-Client.
Eingabe:Trace-Eingabeereignisse aus verschiedenen Teilen der Pipeline für Eingabeereignisse.
ProtoLog:ProtoLog-Meldungen von Systemdiensten und dem Code von Systemdiensten, die in Clientprozessen ausgeführt werden, erfassen.
Bildschirmaufzeichnung:Erstellen Sie eine Bildschirmaufzeichnung zusammen mit den Traces.
Shell-Übergänge:Hier werden Systemdetails zu Fenster- und Aktivitätsübergängen aufgezeichnet.
SurfaceFlinger:Erfasst SurfaceFlinger-Traces mit Informationen zu Oberflächen (Layern) wie Position, Puffer und Zusammensetzung.
Transaktionen:Verfolgen Sie die Menge der atomaren Änderungen, die SurfaceFlinger für die Komposition über SurfaceControl empfangen hat.
ViewCapture:Erfasst eine Reihe von Eigenschaften aller Ansichten aus System-Windows, die ViewCapture unterstützen, z. B. System-UI und Launcher.
Window Manager:Der Trace Window Manager enthält Statusinformationen zu Fenstern, einschließlich Eingabe- und Fokusereignissen, Bildschirmausrichtung, Übergängen, Animationen, Positionierung und Transformationen.

Unterstützte Dumps

Mit Winscope können Status-Dumps erfasst und angezeigt werden. Das sind Snapshots des Gerätestatus, die zu bestimmten, vom Nutzer definierten Zeitpunkten aufgenommen werden. Im Gegensatz zu Traces, die während der Gerätenutzung kontinuierlich erfasst werden und sich auf die Leistung auswirken können, werden Dumps nur zu diesen benutzerdefinierten Zeitpunkten erstellt. So wird sichergestellt, dass Leistung und Ausführlichkeit nicht beeinträchtigt werden. So lässt sich der Gerätestatus zu bestimmten Zeitpunkten gezielter und effizienter analysieren. Die folgenden Dumps werden von Winscope unterstützt:

Window Manager:Gibt den Status eines einzelnen Fenstermanagers aus.
SurfaceFlinger:Einen einzelnen SurfaceFlinger-Snapshot ausgeben.
Screenshot:Erstellen Sie einen Screenshot zusammen mit den Dumps.

Ressourcen

Informationen zum Erstellen und Ausführen von Winscope finden Sie unter Winscope ausführen.

Informationen zum Erfassen von Traces finden Sie unter Traces erfassen.

Informationen zum Laden von Traces über die Winscope-Web-UI finden Sie unter Traces laden.

Informationen zum Analysieren von Traces finden Sie unter Traces analysieren.

Beispiele

Im folgenden Beispiel wird beschrieben, wie Sie einen fehlgeschlagenen Flimmertest und einen von einem Nutzer gemeldeten Fehler beheben.

Flimmertest fehlgeschlagen

In diesem Beispiel wird gezeigt, wie Sie mit Winscope einen fehlgeschlagenen Flimmertest debuggen.

Testfehler untersuchen

Führen Sie die folgenden Schritte aus, um den Fehlertyp zu ermitteln und die Fehlermeldung des Tests zu prüfen.

Ermitteln Sie den Problemtyp anhand des Test- und Klassennamens.

Test- und Kursname:
```
FlickerTestsNotification com.android.server.wm.flicker.notification.OpenAppFromLockscreenNotificationColdTest#appLayerBecomesVisible[ROTATION_0_GESTURAL_NAV]
```
Art des Problems:
- Der CUJ bezieht sich auf das Starten einer App über eine Benachrichtigung auf dem Sperrbildschirm (OpenAppFromLockscreenNotificationColdTest).
- Im Test wird erwartet, dass die App sichtbar wird (#appLayerBecomesVisible).

Sehen Sie sich die Fehlermeldung des Tests an. Sie enthält umfassende Informationen zum Fehler, darunter:

Ein Vergleich zwischen dem erwarteten und dem tatsächlich sichtbaren Ergebnis
Zeitstempel, die helfen, den Zeitpunkt des Fehlers zu ermitteln
Der Name des Artefakts oder der Datei, die mit dem Fehler verknüpft ist
Zusätzliche Kontextinformationen, die für das Verständnis und die Fehlerbehebung des Fehlers relevant sind

android.tools.flicker.subject.exceptions.IncorrectVisibilityException: com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity# should be visible

Where?
    Timestamp(UNIX=2024-05-10T11:04:14.227572545(1715339054227572545ns), UPTIME=37m21s184ms79178ns(2241184079178ns), ELAPSED=0ns)

What?
    Expected: com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#
    Actual: [e636ecd com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3457: Buffer is empty, Visible region calculated by Composition Engine is empty, com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3458: Visible region calculated by Composition Engine is empty]

Other information
    Artifact: FAIL__OpenAppFromLockscreenNotificationColdTest_ROTATION_0_GESTURAL_NAV.zip

Check the test run artifacts for trace files

    at android.tools.flicker.subject.layers.LayerTraceEntrySubject.isVisible(LayerTraceEntrySubject.kt:187)
    at android.tools.flicker.subject.layers.LayersTraceSubject$isVisible$1$1.invoke(LayersTraceSubject.kt:151)
    at android.tools.flicker.subject.layers.LayersTraceSubject$isVisible$1$1.invoke(LayersTraceSubject.kt:150)
    at android.tools.flicker.assertions.NamedAssertion.invoke(NamedAssertion.kt:32)
    at android.tools.flicker.assertions.CompoundAssertion.invoke(CompoundAssertion.kt:42)
    at android.tools.flicker.assertions.AssertionsChecker.test(AssertionsChecker.kt:79)
    at android.tools.flicker.subject.FlickerTraceSubject.forAllEntries(FlickerTraceSubject.kt:59)
    at android.tools.flicker.assertions.AssertionDataFactory$createTraceAssertion$closedAssertion$1.invoke(AssertionDataFactory.kt:46)
    at android.tools.flicker.assertions.AssertionDataFactory$createTraceAssertion$closedAssertion$1.invoke(AssertionDataFactory.kt:43)
    at android.tools.flicker.assertions.AssertionDataImpl.checkAssertion(AssertionDataImpl.kt:33)
    at android.tools.flicker.assertions.ReaderAssertionRunner.doRunAssertion(ReaderAssertionRunner.kt:35)
    at android.tools.flicker.assertions.ReaderAssertionRunner.runAssertion(ReaderAssertionRunner.kt:29)
    at android.tools.flicker.assertions.BaseAssertionRunner.runAssertion(BaseAssertionRunner.kt:36)
    at android.tools.flicker.legacy.LegacyFlickerTest.doProcess(LegacyFlickerTest.kt:59)
    at android.tools.flicker.assertions.BaseFlickerTest.assertLayers(BaseFlickerTest.kt:89)
    at com.android.server.wm.flicker.notification.OpenAppTransition.appLayerBecomesVisible_coldStart(OpenAppTransition.kt:51)
    at com.android.server.wm.flicker.notification.OpenAppFromNotificationColdTest.appLayerBecomesVisible(OpenAppFromNotificationColdTest.kt:64)

Diese Beispielausgabe gibt Folgendes an:

Das Problem tritt bei 2024-05-10T11:04:14.227572545 auf.
NotificationActivity sollte sichtbar sein, ist es aber nicht.
Der Name der Artefaktdatei, die die Traces für das Debugging enthält, ist FAIL__OpenAppFromLockscreenNotificationColdTest_ROTATION_0_GESTURAL_NAV.

Fehler beheben

So ermitteln Sie die Ursache des Flackerns:

Laden Sie die Tracedateien herunter und laden Sie sie in Winscope. Winscope wird mit automatisch ausgewählter SurfaceFlinger-Trace geöffnet:

Abbildung 1: Winscope-Landingpage mit SurfaceFlinger-Ansicht.
Rufen Sie den Zeitstempel auf, an dem das Problem auftritt, indem Sie den Zeitstempel aus der Fehlermeldung kopieren und in das Zeitstempelfeld einfügen. Sie können entweder den Zeitstempel im für Menschen lesbaren Format (2024-05-10T11:04:14.227572545) kopieren und in das erste Feld einfügen oder den Zeitstempel in Nanosekunden (1715339054227572545ns) kopieren und in das zweite Feld einfügen.

Abbildung 2: Dialogfeld „Zeitstempel“
Drücke den Linkspfeil, um zum vorherigen Frame zu gelangen. In diesem Zustand wird die NotificationActivity-App im Video richtig angezeigt. Sowohl die App als auch der Begrüßungsbildschirm sind sichtbar, was durch die grünen Rechtecke in der 3D-Ansicht und den V-Chip auf den Hierarchieelementen angezeigt wird.

Die Namen der App- und Splash-Screens sind:
```
com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3458`

Splash Screen com.android.server.wm.flicker.testapp#3453
```
Das bedeutet, dass die App gerade gestartet wurde, als der Bildschirm schwarz wurde, und dass dieses Ereignis während des App-Starts auftritt, da der Splash-Screen noch sichtbar ist:

Abbildung 3: Beim Start der App.
Drücken Sie die Rechtspfeiltaste, um zum nächsten Frame zurückzukehren, in dem das Flackern auftritt. In der Rechteckansicht wird das NotificationShade anstelle der App auf dem Bildschirm angezeigt. In diesem Frame werden die folgenden Oberflächen angezeigt:
- Dekor-Overlays für den Bildschirm (oben und unten)
- Navigationsleiste
- Zeigerposition (aus der Bildschirmaufzeichnung)
  
  Abbildung 4: Flimmeraktivität.
Wählen Sie die App-Aktivität in der Hierarchieansicht aus. Wenn Sie sie nicht finden, deaktivieren Sie Nur V anzeigen und sehen Sie sich die Property-Ansicht an.

Der Name der App-Oberfläche lautet:
```
com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3458`
```
Abbildung 5: App-Properties

Obwohl die App-Aktivität auf „Sichtbar“ und „Undurchsichtig“ festgelegt ist, wird die Oberfläche aufgrund eines Invisible due to: null visible region-Fehlers nicht angezeigt. Das passiert, weil während der Komposition eine andere undurchsichtige Oberfläche davor platziert wurde. Diese Hypothese beruht darauf, dass sich das Rechteck NotificationShade in der 3D-Ansicht vor dem Rechteck NotificationActivity befindet und das sichtbare (grüne) Rechteck NotificationShade möglicherweise die ausgewählte Ebene ist.
Um diese Hypothese zu bestätigen, wählen Sie die sichtbare NotificationShade-Oberfläche im aktuellen Frame aus und prüfen Sie ihre Eigenschaften. Die Flags sind auf OPAQUE|ENABLE_BACKPRESSURE (0x102) gesetzt. Der Name der NotificationShade-Oberfläche lautet NotificationShade#3447. Drücken Sie dann den linken Pfeil, um zum vorherigen Frame (vor dem Flackern) zurückzukehren und die Eigenschaften der NotificationShade-Oberfläche noch einmal zu prüfen. Beachten Sie, dass die Oberfläche anstelle von OPAQUE nur das Flag ENABLE_BACKPRESSURE (0x100) hat. So wird bestätigt, dass NotificationShade undurchsichtig wird, bevor der App-Start vollständig abgeschlossen ist. Da NotificationShade vor NotificationActivity steht, wird die App nicht angezeigt. Das NotificationShade ist schwarz, daher wird der Bildschirm kurz schwarz, was das Flackern verursacht.
Ermitteln Sie im Code, warum das NotificationShade zu früh undurchsichtig wird.

Von Nutzern gemeldeter Fehler

Von Nutzern gemeldete Fehler sind oft schwer zu beheben, da es an detaillierten Informationen mangelt. Im Gegensatz zu Fehlern im Flimmertest, die bestimmte Zeitstempel, Elementdetails und Bildschirmaufzeichnungen enthalten, enthalten von Nutzern gemeldete Fehler in der Regel nur eine kurze Beschreibung des Problems.

In unserer Fallstudie sind die einzigen Informationen der Titel Bildschirm flackerte beim erneuten Öffnen der App im Splitscreen und ein ungefähres Zeitstempel von 18.04.2024, 15:51 Uhr GMT-04:00.

So beheben Sie einen von einem Nutzer gemeldeten Fehler:

Laden Sie die Trace-Datei in Winscope. Winscope wird geöffnet und SurfaceFlinger ist automatisch ausgewählt.

Abbildung 6 Winscope-Landingpage mit SurfaceFlinger-Ansicht.
Rufen Sie den vom Nutzer gemeldeten ungefähren Zeitstempel auf, in diesem Fall 3:50 PM GMT-04:00, indem Sie 15:50:00 in das Feld für den für Menschen lesbaren Zeitstempel eingeben.

Abbildung 7. Dialogfeld „Zeitstempel“
Mit der Ansicht „Rechtecke“ können Sie ermitteln, was auf dem Bildschirm gezeichnet wurde. Mit dem Schieberegler Drehung können Sie die Perspektive der Rechtecke ändern. Wenn Sie in der Hierarchieansicht Nur V anzeigen und Flach markieren, sind das Hintergrundbild, das Overlay für die Bildschirmdekoration, das Letterbox-Format, der Launcher, die Kontakte und die Dialer-Oberflächen sichtbar.

Die Paketnamen sind:
- Launcher: com.google.android.apps.nexuslauncher/com.google.android.apps.nexuslauncher.NexusLauncherActivity#40602
- Kontakte: com.google.android.contacts/com.android.contacts.activities.PeopleActivity#40565
- Wählhilfe: com.google.android.dialer/com.google.android.dialer.extensions.GoogleDialtactsActivity#40564
Neben den sichtbaren Oberflächen (grüne Rechtecke) wird ein graues Rechteck mit dem Namen Unbekanntes Display angezeigt, das die Oberfläche des Displaybereichs darstellt. Um die Sichtbarkeit zu verbessern, klicken Sie neben der ScreenDecorHwcOverlay#64-Oberfläche auf das , um das entsprechende Rechteck auszublenden und die dahinterliegenden Oberflächen sichtbar zu machen. Wir entfernen das Overlay für die Analyse, da es für den Nutzer nicht sichtbar ist und nicht als flackernde Animation gemeldet würde.

Abbildung 8. Nutzerbericht
Nachdem Sie die Oberflächen identifiziert haben, die im Splitscreen-Modus verwendet werden, können Sie mit dem Transitions-Trace verschiedene Nutzeraktionen durchgehen und das Flimmern finden. Klicken Sie in Winscope auf den Tab Transitions (Übergänge), um die Liste der ausgeführten Übergänge zu visualisieren:

Abbildung 9. Übergänge

Der Übergang, der während dieses Frames abgespielt wird, ist blau hervorgehoben. In diesem Fall enthalten die Übergangs-Flags TRANSIT_FLAG_IS_RECENTS, was darauf hinweist, dass der Nutzer den Bildschirm „Zuletzt verwendet“ aufruft.
Klicken Sie in der Spalte Dispatch Time (Versandzeit) auf den Link (in diesem Fall 2024-04-18, 15:50:57.205), um zu diesem Zeitpunkt zu wechseln und die Rechtecke auf dem Tab Surface Flinger zu prüfen. Bestätigen Sie die Richtigkeit des Gerätestatus während der Umstellung, indem Sie mit der Rechtspfeiltaste durch die Umstellung gehen und die Rechtecke beobachten.

Der Launcher wird um 15:50:57.278 angezeigt, die Animation beginnt aber erst später. Das Hintergrundbild ist bereits sichtbar, da zwischen den Apps im Split-Screen-Modus nichts gezeichnet wird (Teiler). Ein Frame früher (15:50:57.212) ist der Hintergrund nicht sichtbar und die Trennlinie wird angezeigt. So sieht der Splitscreen aus, wenn keine Animation erfolgt.

Abbildung 10. Bildschirm vor dem Flackern.
Wenn Sie sich die nächste Überblendung ansehen möchten, klicken Sie direkt auf die Zeitachse. SurfaceFlinger-Zustände werden durch eine Reihe hellblauer Blöcke dargestellt. Übergänge werden durch eine Reihe rosa Blöcke dargestellt.

Abbildung 11. Ende des ersten Übergangs.

Klicken Sie in der Zeile „SurfaceFlinger“ auf die Startposition des nächsten Übergangs. In Abbildung 11 wird die vertikale Position des Cursors durch die dünne blaue Linie angegeben. Der hellblaue Hintergrund der SurfaceFlinger-Zeile zeigt die horizontale Position an. Gehen Sie mit der Rechtspfeiltaste durch den Übergang, um zu sehen, ob ein Flackern auftritt. Prüfen Sie, ob das Gerät für diese Umstellung korrekt aussieht.

Hinweis :Wenn Sie auf die Zeitachsenzeile eines Traces klicken, wird sie aktiv. Das bedeutet, dass Sie nur Einträge in diesem Trace mit den Pfeiltasten nach links oder rechts erreichen können. Klicken Sie hier auf die Zeile „SurfaceFlinger“, um die SurfaceFlinger-Status durchzugehen.
Überspringen Sie den nächsten Übergang, da er sehr kurz ist und es daher unwahrscheinlich ist, dass er ein Flackern enthält. Klicken Sie stattdessen in der SurfaceFlinger-Zeile auf die Zeitachse an der Startposition des nächsten längeren Übergangs, wie im folgenden Bild durch den Cursor angegeben.

Abbildung 12. Ende des zweiten Übergangs.

Achten Sie während dieser Umstellung bei 15:51:13.239 darauf, dass sich die Splash Screen-Ebenen für beide Apps, die Kontakte und den Dialer auf derselben Seite des Displays befinden:

Abbildung 13. Ladebildschirme
Gib an, welche App auf der falschen Seite angezeigt wird. Fügen Sie ein Lesezeichen für Ihre aktuelle Position hinzu, indem Sie neben dem Eingabefeld ns auf das Flaggensymbol klicken. So können Sie später leichter zu diesem Frame zurückkehren.

Abbildung 14. Lesezeichen hinzufügen.
Klicken Sie direkt auf die Zeitachse, um zu einem Frame am Ende des Übergangs zu wechseln, z. B. zu 15:51:13.859. Hier sind die beiden Apps in ihrer endgültigen Position zu sehen: Der Dialer befindet sich links und die Kontakte rechts.

Abbildung 15. Finaler Splitscreen
Klicken Sie in der Zeitachse auf das Lesezeichen, um zum Frame mit dem Flackern zurückzukehren.

Abbildung 16: Zeitachse mit Lesezeichen.

Beide Apps befinden sich rechts, was darauf hindeutet, dass sich der Drehregler in der falschen Position befindet.
Klicken Sie auf den Startbildschirm des Wählers, um die zugehörigen Eigenschaften aufzurufen. Sehen Sie sich insbesondere die Transformationseigenschaften in der kuratierten Ansicht Eigenschaften an.

Abbildung 17. Transformationseigenschaften.

Die berechnete Transformation wird auf diese Ebene angewendet, aber nicht als diese Ebene festgelegt. Die berechneten und angeforderten Spalten haben unterschiedliche Werte. Das bedeutet, dass die Transformation von einer übergeordneten Oberfläche übernommen wird.
Deaktivieren Sie in der hierarchischen Ansicht die Option Flat, um den gesamten Hierarchiebaum aufzurufen. Gehen Sie dann zu den übergeordneten Knoten der App-Oberfläche, bis die Transformationen Calculated und Requested identisch sind. Die Transformation wird dann auf der Surface(name=Task=7934)/@0x1941191_transition-leash#40670-Oberfläche angefordert.
Prüfen Sie, wann die Transformation zum ersten Mal festgelegt wurde und welchen Wert sie hatte. Sie können die kuratierten Eigenschaften minimieren, indem Sie auf das Symbol neben dem Titel klicken:

Abbildung 18. Minimieren Sie die kuratierten Properties.
Wählen Sie in der Ansicht Proto Dump die Option Diff-Anzeige aus, um die Eigenschaften hervorzuheben, die in diesem Frame geändert werden. Geben Sie transform in das Textsuchfeld ein, um die Eigenschaften zu filtern:

Abbildung 19. Unterschied anzeigen

Die Transformation wird in diesem Frame für transition-leash von IDENTITY auf SCALE|TRANSLATE|ROT_270 festgelegt.

Diese Informationen zeigen, dass das Flackern aufgetreten ist, als die Transformation auf die Animationsleine der Dialer-Split-Screen-App angewendet wurde.

Abbildung 20. Identifizierung des Flackerns.
Ermitteln Sie im Code, warum diese Transformation auf die Splitscreen-Übergangsleine festgelegt ist.