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
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Winscope ist ein Webtool, mit dem Nutzer den Status mehrerer 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, durchgehen und beheben.

Unterstützte Traces

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

Ereignisprotokoll:Erfassen Sie den Systemdiagnoseereignis-Eintrag mit EventLog. In Winscope werden diese Informationen nur verwendet, um CUJ-Markierungen zu identifizieren und anzuzeigen.
IME:Hier werden Ereignisse aus der IME-Pipeline (Input Method Editor) erfasst, einschließlich IMS, IMMS und IME-Client.
Eingabe:Eingabeereignisse aus verschiedenen Teilen der Eingabeereignispipeline erfassen.
ProtoLog: ProtoLog-Nachrichten von Systemdiensten und dem Code von Systemdiensten erfassen, die in Clientprozessen ausgeführt werden.
Bildschirmaufzeichnung:Erfassen Sie neben den Aufzeichnungen auch eine Bildschirmaufzeichnung.
Shell-Übergänge:Hier werden Systemdetails zu Fenster- und Aktivitätsübergängen aufgezeichnet.
SurfaceFlinger:Erfassen von SurfaceFlinger-Traces mit Informationen zu Oberflächen (Ebenen), z. B. Position, Puffer und Zusammensetzung.
Transaktionen:Hier können Sie die atomaren Änderungen nachverfolgen, die von SurfaceFlinger mit SurfaceControl für die Zusammensetzung empfangen wurden.
ViewCapture:Hiermit können Sie eine Reihe von Eigenschaften aller Ansichten von Systemfenstern erfassen, die ViewCapture unterstützen, z. B. die System-UI und den Launcher.
Fenstermanager: Fenstermanager-Status mit Details zu Fenstern, einschließlich Eingabe- und Fokusereignissen, Bildschirmausrichtung, Übergängen, Animationen, Positionierung und Transformationen.

Unterstützte Dumps

Winscope kann Statusdumps erfassen und anzeigen. Das sind Snapshots des Gerätestatus, die zu bestimmten vom Nutzer definierten Zeitpunkten aufgenommen werden. Im Gegensatz zu Protokollen, die während der Gerätenutzung kontinuierlich erfasst werden und die Leistung beeinträchtigen können, werden Dumps nur zu diesen benutzerdefinierten Zeitpunkten erstellt. So wird sichergestellt, dass Leistung und Detaillierung nicht beeinträchtigt werden. So ist eine gezieltere und effizientere Analyse des Gerätestatus zu bestimmten Zeitpunkten möglich. Die folgenden Dumps werden von Winscope unterstützt:

Fenstermanager:Dump eines einzelnen Fenstermanager-Status.
SurfaceFlinger:Dumpt einen einzelnen SurfaceFlinger-Snapshot.
Screenshot:Erstellen Sie neben den Dumps einen Screenshot.

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-Benutzeroberfläche finden Sie unter Traces laden.

Informationen zum Analysieren von Traces finden Sie unter Traces analysieren.

Beispiele

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

Fehler beim Flimmerntest

In diesem Beispiel wird gezeigt, wie Sie mit Winscope einen Fehler beim Flimmerntest beheben.

Testfehler untersuchen

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

Legen Sie den Problemtyp anhand des Test- und Klassennamens fest.

Name des Tests und der Klasse:
```
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 Sperrbildschirmbenachrichtigung (OpenAppFromLockscreenNotificationColdTest).
- Im Test wird davon ausgegangen, dass die App sichtbar wird (#appLayerBecomesVisible).

Prüfen Sie die Fehlermeldung zum Test, die umfassende Informationen zum Fehler enthält, 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 Behebung 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)

Dieses Beispiel für eine Ausgabe 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 Protokolle zur Fehlerbehebung enthält, ist FAIL__OpenAppFromLockscreenNotificationColdTest_ROTATION_0_GESTURAL_NAV.

Fehler beheben

So ermitteln Sie die Ursache des Flimmerns:

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

Abbildung 1: Winscope-Landingpage mit SurfaceFlinger-Ansicht
Rufen Sie den Zeitstempel auf, zu dem das Problem auftritt, indem Sie den Zeitstempel aus der Ausnahmemeldung in das Zeitstempelfeld kopieren und einfügen. Sie können den Zeitstempel entweder im 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 für Zeitstempel
Drücken Sie die Taste mit dem Linkspfeil, um zum vorherigen Frame zu wechseln. In diesem Zustand wird die App „NotificationActivity“ im Video korrekt angezeigt. Sowohl die App- als auch die Begrüßungsbildschirmoberflächen sind sichtbar, was durch die grünen Rechtecke in der 3D-Ansicht und den Chip V auf den Hierarchieelementen angezeigt wird.

Die Namen der App- und Startbildschirmoberfläche lauten:
```
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 gestartet wurde, als das Display schwarz wurde, und dass dieses Ereignis während des App-Starts auftritt, da der Startbildschirm noch sichtbar ist:

Abbildung 3: Beim Starten der App
Drücke die rechte Pfeiltasten, um zum nächsten Frame zurückzukehren, in dem das Flimmern auftritt. In der Ansicht „Rectangles“ (Rechtecke) wird anstelle der App das NotificationShade angezeigt. In diesem Frame sind die folgenden Oberflächen zu sehen:
- Bildschirmdekor-Overlays (oben und unten)
- Navigationsleiste
- Zeigerposition (aus der Bildschirmaufzeichnung)
  
  Abbildung 4: Flimmern
Wählen Sie in der Hierarchieansicht die App-Aktivität aus. Wenn Sie sie nicht finden können, deaktivieren Sie die Option Nur V anzeigen und sehen Sie sich dann 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

Die App-Aktivität ist zwar auf „sichtbar“ und „undurchsichtig“ gesetzt, die Oberfläche wird aber aufgrund eines Invisible due to: null visible region-Fehlers nicht angezeigt. Das liegt daran, dass beim Zusammenstellen des Bildes eine weitere opake Oberfläche davor platziert wurde. Diese Hypothese ergibt sich daraus, 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 überprüfen, wählen Sie die sichtbare NotificationShade Flä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 als Nächstes den linken Pfeil, um zum vorherigen Frame (vor dem Flimmern) zurückzukehren, und prüfen Sie noch einmal die Eigenschaften der NotificationShade-Oberfläche. Beachten Sie, dass die Oberfläche nicht OPAQUE, sondern nur das Flag ENABLE_BACKPRESSURE (0x100) hat. Das bestätigt, dass NotificationShade undurchsichtig wird, bevor der App-Start vollständig abgeschlossen ist. Da das NotificationShade vor dem NotificationActivity steht, wird die App nicht angezeigt. Da das NotificationShade schwarz ist, wird der Bildschirm kurzzeitig schwarz, was zu Flimmern führt.
Ermitteln Sie im Code, warum das NotificationShade zu früh undurchsichtig wird.

Von Nutzern gemeldeter Fehler

Von Nutzern gemeldete Fehler können schwierig zu beheben sein, da oft detaillierte Informationen fehlen. Im Gegensatz zu Fehlern bei Flickertests, die bestimmte Zeitstempel, Elementdetails und Bildschirmaufzeichnungen enthalten, umfassen von Nutzern gemeldete Fehler in der Regel nur eine kurze Beschreibung des Problems.

In unserer Fallstudie sind nur der Titel Bildschirm flackert beim Wiederöffnen der App aus dem Splitscreen und ein ungefährer Zeitstempel 18. April 2024, 15:51 Uhr (GMT-04:00) angegeben.

So beheben Sie einen von Nutzern gemeldeten Fehler:

Laden Sie die Tracedatei in Winscope. Winscope wird mit automatisch ausgewählter SurfaceFlinger-Oberfläche geöffnet.

Abbildung 6 Winscope-Landingpage mit SurfaceFlinger-Ansicht
Rufe den ungefähren Zeitstempel auf, den der Nutzer angegeben hat, in diesem Fall 3:50 PM GMT-04:00. Gib dazu 15:50:00 in das für Menschen lesbare Feld für den Zeitstempel ein.

Abbildung 7. Dialogfeld für Zeitstempel
In der Ansicht „Rechtecke“ sehen Sie, was auf dem Bildschirm gezeichnet wurde. Mit dem Schieberegler Drehung können Sie die Perspektive der Rechtecke ändern, um eine bessere Ansicht zu erhalten. Wenn Sie in der Ansicht Hierarchie die Optionen Nur V anzeigen und Flach markieren, sind der Hintergrund, das Bildschirmdekor-Overlay, der Letterbox-Effekt, der Launcher, die Kontaktoberfläche und die Oberfläche des Telefonbuchs 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
- Telefon: com.google.android.dialer/com.google.android.dialer.extensions.GoogleDialtactsActivity#40564
Zusätzlich zu den sichtbaren Oberflächen (grüne Rechtecke) wird ein grauer Rechteck, der die Oberfläche des Anzeigebereichs darstellt, mit dem Namen Unbekanntes Display angezeigt. Wenn Sie die Sichtbarkeit verbessern möchten, klicken Sie neben der Oberfläche ScreenDecorHwcOverlay#64 auf das Dreipunkt-Menü , um das entsprechende Rechteck auszublenden und die Oberflächen dahinter 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 wird.

Abbildung 8. Nutzerbericht
Nachdem Sie ermittelt haben, welche Oberflächen in der Splitscreen-Ansicht verwendet werden, können Sie mithilfe der Transitions-Aufzeichnung verschiedene Nutzeraktionen durchgehen und das Flimmern finden. Klicken Sie in Winscope auf den Tab Übergänge, um eine Liste der abgespielten Übergänge aufzurufen:

Abbildung 9. Übergänge

Der während dieses Frames abgespielte Übergang ist blau hervorgehoben. In diesem Fall enthält die Flags für den Übergang TRANSIT_FLAG_IS_RECENTS, was bedeutet, dass der Nutzer den Bildschirm „Letzte“ aufruft.
Klicken Sie in der Spalte Dispatch Time (in diesem Fall 2024-04-18, 15:50:57.205) auf den Link, um zu diesem Zeitpunkt zu gelangen und die Rechtecke auf dem Tab Surface Flinger zu überprüfen. Prüfen Sie während des Übergangs, ob der Gerätestatus korrekt ist. Gehen Sie dazu mit der rechten Richtungstaste durch den Übergang und beobachten Sie die Rechtecke.

Der Launcher wird um 15:50:57.278 angezeigt, die Animation startet aber nicht. Der Hintergrund ist bereits sichtbar, da zwischen den Apps im Splitscreen-Modus nichts gezeichnet wird (Teiler). Ein Frame zuvor (15:50:57.212) ist der Hintergrund nicht sichtbar und die Trennlinie ist zu sehen. So sieht der Splitscreen aus, wenn er nicht animiert wird.

Abbildung 10. Display vor dem Flimmern
Wenn Sie sich die nächste Umstellung ansehen möchten, klicken Sie direkt auf die Zeitleiste. SurfaceFlinger-Zustände werden durch eine Reihe von hellblauen Blöcken dargestellt. Übergänge werden durch eine Reihe rosa Blöcke dargestellt.

Abbildung 11 Ende des ersten Übergangs.

Klicken Sie an der Startposition der nächsten Überleitung auf die Zeile „SurfaceFlinger“. In Abbildung 11 wird die vertikale Position des Cursors durch die dünne blaue Linie angezeigt. Der hellblaue Hintergrund der Zeile „SurfaceFlinger“ zeigt ihre horizontale Position an. Gehen Sie mit dem rechten Pfeil durch den Übergang, um zu sehen, ob es zu einem Flimmern kommt. Prüfen Sie, ob das Gerät für diesen Übergang korrekt aussieht.

Hinweis :Wenn Sie auf die Zeitachsenzeile eines Logs klicken, wird es aktiv. Das bedeutet, dass nur Einträge in diesem Log mit den Pfeiltasten nach links oder rechts erreicht werden können. Klicken Sie hier auf die Zeile „SurfaceFlinger“, um die SurfaceFlinger-Zustände weiter durchzugehen.
Überspringen Sie den nächsten Übergang, da seine Dauer sehr kurz ist und er daher wahrscheinlich nicht flackert. Klicken Sie stattdessen in der Zeile „SurfaceFlinger“ auf die Zeitachse an der Startposition des nächsten längeren Übergangs, wie im folgenden Bild durch den Cursor dargestellt.

Abbildung 12 Ende des zweiten Übergangs.

Achten Sie bei diesem Übergang bei 15:51:13.239 darauf, dass sich die Splash Screen-Ebenen für beide Apps, die Kontakte und den Telefonbereich, auf derselben Seite des Displays befinden:

Abbildung 13 Ladebildschirme
Geben Sie an, welche App sich auf der falschen Seite befindet. Wenn Sie die aktuelle Position als Lesezeichen speichern möchten, klicken Sie neben dem Eingabefeld ns auf das Flaggensymbol. So können Sie später leichter zu diesem Frame zurückkehren.

Abbildung 14. Lesezeichen hinzufügen.
Klicke direkt auf der Zeitleiste auf einen Frame am Ende des Übergangs, z. B. auf 15:51:13.859. Hier sind die beiden Apps jetzt an ihrer endgültigen Position: links die Telefonanruffunktion und rechts die Kontakte:

Abbildung 15. Endgültiger Splitscreen.
Klicke auf das Flag des Lesezeichens in der Zeitleiste, um zum Frame mit dem Flimmern zurückzukehren.

Abbildung 16: Lesezeichenzeitachse

Beide Apps befinden sich rechts, was bedeutet, dass sich der Telefonbereich an der falschen Position befindet.
Klicken Sie auf den Begrüßungsbildschirm des Dialers, um die Eigenschaften aufzurufen. Sehen Sie sich in der Ansicht Properties die Transformationseigenschaften an.

Abbildung 17. Transformieren-Eigenschaften

Die berechnete Transformation wird auf diese Oberfläche angewendet, aber nicht als Ebene festgelegt. Die berechneten und angeforderten Spalten haben unterschiedliche Werte, was darauf hinweist, dass die Transformation von einer übergeordneten Oberfläche übernommen wird.
Heben Sie in der Hierarchieansicht die Auswahl von Flat auf, um den gesamten Hierarchiebaum zu sehen. Gehen Sie zu den übergeordneten Knoten der App-Oberfläche, bis die Transformationen Berechnet und Angefordert übereinstimmen. Die Transformation, die auf der Surface(name=Task=7934)/@0x1941191_transition-leash#40670-Oberfläche angefordert wird, wird angezeigt.
Prüfen Sie, wann die Transformation zum ersten Mal festgelegt wurde und auf welchen Wert. Sie können die ausgewählten Properties minimieren, indem Sie auf das Symbol neben dem Titel klicken:

Abbildung 18 Minimieren Sie die ausgewählten 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 Suchfeld ein, um die Unterkünfte zu filtern:

Abbildung 19 Unterschied anzeigen

In diesem Frame wird die Transformation für die transition-leash von IDENTITY zu SCALE|TRANSLATE|ROT_270 festgelegt.

Diese Informationen zeigen, dass das Flimmern aufgetreten ist, als die Transformation auf die Animation der Leine der Splitscreen-App des Dialers angewendet wurde.

Abbildung 20. Beschreibung des Flimmerns.
Ermitteln Sie im Code, warum diese Transformation auf die Leine für den Splitscreen-Übergang festgelegt ist.