Measure, Layout und Draw mal in Hierarchyviewer (besser) erklärt

8

Ich versuche die Hierarchieansicht zu verstehen.

Also las ich auf developer.android.com die Bedeutung der drei Punkte:

  

Grün: Für diesen Teil der Renderzeit ist diese Ansicht schneller   50% aller View-Objekte in der Struktur. Zum Beispiel ein grüner Punkt für   Die Messzeit bedeutet, dass diese Ansicht eine schnellere Messzeit hat als   50% der View-Objekte in der Struktur.

     

Gelb: Für diesen Teil des   Renderzeit ist diese Ansicht in den langsameren 50% aller View-Objekte in   der Baum. Zum Beispiel bedeutet ein gelber Punkt für die Layout-Zeit   Diese Ansicht hat eine langsamere Layout - Zeit als 50% der View - Objekte in der   Baum.

     

Rot: Für diesen Teil der Renderzeit ist diese Ansicht am langsamsten   einer im Baum. Zum Beispiel bedeutet ein roter Punkt für die Zeit, dass   Diese Ansicht benötigt die meiste Zeit, um alle Ansichtsobjekte in der Ansicht zu zeichnen   Baum.

Wenn ich mich nicht irre, heißt das nicht, dass es immer höchstens 3 Ansichten mit roten Punkten geben sollte (die langsamsten Ansichten für jede Kategorie: Messen, Layout, Zeichnen) und dann die Hälfte der Ansichten gelb und halb Grün.

Zuerst sehe ich mehr als 3 Ansichten mit roten Punkten und ich verstehe nicht warum.

Zweitens sehe ich nicht, wie diese Werte zur Verbesserung der Leistung beitragen können, wenn man bedenkt, dass dies relative Werte sind. Es wird immer die Hälfte der Ansichten schneller sein als die andere Hälfte.

Und in der Baumansicht sehe ich Ansichten mit visibility gone , die eine kleine Zeichenzeit haben. Sollten GONE-Views nicht komplett ignoriert werden?

    
andrei 04.09.2015, 13:16
quelle

1 Antwort

3
  

Wenn ich mich nicht täusche, heißt das nicht, dass es immer an sein sollte   die meisten 3 Ansichten mit roten Punkten

Ihre Logik ist gut, aber das Dokument darf nicht Baum, sondern an einem Knoten sagen. Die tool4s-Funktion des Hierarchie-Viewers, den Sie verwenden, um diese 3 Punkte zu erhalten, ist Profile Node , und dies fängt an, den Baum vom ausgewählten Knoten (der beliebigen Wurzel des Baums) bis zum Ende des Baums zu profilieren.

Jedes View , in einem ViewGroup ( Layouts basieren auf ViewGroup ) das mehr als eine Ansicht enthält, wird die Punkte haben. Im umgekehrten Fall gibt es keine Punkte.

Also wird der Vergleich nur auf einer Knotenebene durchgeführt, nicht für den gesamten Baum, und deshalb können Sie mehr als drei rote Punkte (einen für Maß, einen für das Layout, einen für die Zeichnung) für den gesamten Baum erhalten. aber nicht für einen Knoten.

  

Zweitens sehe ich nicht, wie diese Werte die Leistung verbessern können   wenn man bedenkt, dass dies relative Werte sind. Es wird immer die Hälfte geben   der Ansichten schneller als die andere Hälfte.

Die Punkte helfen Ihnen zu erkennen, welche Ansicht in einer Ansichtsgruppe am langsamsten zu Messen / Layout / Zeichnen ist. Um zu vermeiden, dass der Bildschirm einfriert, muss die Summe einer Operation unter 16,6 ms liegen (Android sollte eine Bildrate von 60 Bildern pro Sekunde beibehalten).

Der rote Punkt gibt Ihnen nur einen Hinweis darauf, welche Ansicht Sie profilieren sollten, aber das bedeutet nicht, dass eine Ansicht nicht optimiert ist, besonders bei einer komplexen Hierarchie mit vielen Kindern.

Auch wenn Sie eine benutzerdefinierte Ansicht erstellen müssen, kann der Hierarchie-Viewer Ihnen helfen, zu wissen, ob Sie ein schnelles Rendering korrekt durchführen.

  

Ich sehe Ansichten mit visibility gone , die eine kleine Zeichenzeit haben.   Sollten GONE-Views nicht komplett ignoriert werden?

A View , dessen Sichtbarkeit auf GONE gesetzt ist, wird nicht durch onMeasure , onLayout und onDraw gehen. Sie können es einfach ausprobieren, wenn Sie ein Widget wie ein TextView erweitern und diese Methoden mit einem Log.d überschreiben, um zu wissen, was passiert.

Aber ich denke, die Zeit beim Zeichnen kommt, weil die Ansicht erstellt wird, dann an das Fenster angehängt wird und schließlich ihre Sichtbarkeit ändert.

Beispiel mit einer TextView. Im ersten Schritt wird das Objekt über den Java-Konstruktor public Text(Context context, AttributeSet attrs){...} ) erstellt, dann wird ein Aufruf zum Anhängen des Fensters mit protected void onAttachedToWindow() {...} ausgeführt und die Sichtbarkeit mit protected void onWindowVisibilityChanged(int visibility) {}

geändert

Wenn Sie jetzt mehr Ihr U.I.-Debuggen möchten, versuchen Sie es mit einem Telefon, bei dem die Option Debug GPU Overdraw in den Entwickleroptionen (nicht auf allen Telefonen) oder im Emulator enthalten ist. Sie können dann sehen, wo die App überzeichnet und dann Ihre Schnittstelle optimiert. Debug GPU Overdraw Walkthrough

    
xiaomi 08.09.2015 17:00
quelle

Tags und Links