Leistung auswerten

Verwenden Sie Simpleperf um die Leistung eines Geräts zu bewerten. Simpleperf ist ein natives Tool zum Erstellen von Profilen, und native Prozesse unter Android. Verwenden Sie CPU-Profiler um die CPU-Auslastung und die Thread-Aktivität der App in Echtzeit zu prüfen.

Es gibt zwei für Nutzer sichtbare Leistungsindikatoren:

  • Vorhersehbare, wahrnehmbare Leistung. Hat die nutzende Person Frames auf der Benutzeroberfläche fallen oder konstant mit 60 fps rendern? Wird Audio wiedergegeben ohne Artefakte oder Hervorhebungen? Wie lange dauert es, bis der Nutzer das Gerät berührt Bildschirm und der Effekt, der auf dem Display angezeigt wird?
  • Zeitaufwand für längere Vorgänge (z. B. Apps öffnen).

Die erste ist auffälliger als die zweite. Nutzer bemerken in der Regel Verzögerung Sie können aber nur dann eine App-Startzeit von 500 ms im Vergleich zu 600 ms unterscheiden, es sei denn, zwei Geräte nebeneinander. Die Berührungslatenz ist sofort auffällig und trägt wesentlich zur Wahrnehmung eines Geräts bei.

Daher ist bei einem schnellen Gerät die UI-Pipeline das Wichtigste in System entkoppelt, was nicht notwendig ist, um die UI-Pipeline funktionsfähig zu halten. Dieses bedeutet, dass die UI-Pipeline alle anderen nicht erforderlichen Vorgänge vorzeitig beenden sollte. für eine flüssige UI. Um eine flüssige Benutzeroberfläche, Hintergrundsynchronisierung, Benachrichtigungszustellung und ähnliche Vorgänge müssen verzögert werden, wenn UI-Arbeiten ausgeführt werden können. Es ist die Leistung längerer Vorgänge (HDR+ Laufzeit, App-Starts usw.), um für eine flüssige Benutzeroberfläche zu sorgen.

Kapazität im Vergleich zu Jitter

Unter Berücksichtigung der Geräteleistung, Kapazität und Jitter sind zwei sinnvolle Metriken.

Kapazität

Die Kapazität ist die Gesamtmenge einer Ressource, die dem Gerät über eine gewisse Zeit verstreichen lassen. Dies können CPU-Ressourcen, GPU-Ressourcen, E/A-Ressourcen, Netzwerkressourcen, Arbeitsspeicherbandbreite oder einen ähnlichen Messwert. Bei der Untersuchung Leistung des gesamten Systems abstrahiert, kann es hilfreich sein, und von einem einzelnen Messwert ausgehen, der die Leistung bestimmt (insbesondere bei der neuen Gerät durchgeführt werden, da die Arbeitslasten, die auf diesem Gerät ausgeführt werden, wahrscheinlich behoben werden können.

Die Kapazität eines Systems hängt von den online verfügbaren Rechenressourcen ab. Das Ändern der CPU-/GPU-Frequenz ist das wichtigste Mittel zum Ändern der Kapazität. z. B. die Online-Änderung der CPU-Kerne. Entsprechend gilt: Die Kapazität eines Systems entspricht dem Stromverbrauch. ändern Kapazität führt immer zu einer ähnlichen Änderung des Stromverbrauchs.

Welche Kapazität zu einem bestimmten Zeitpunkt benötigt wird, hängt stark vom ausgeführte App. Daher kann die Plattform wenig unternehmen, um die die für eine bestimmte Arbeitslast benötigte Kapazität. Die Mittel dafür sind auf Laufzeitverbesserungen (Android-Framework, ART, Bionic, GPU-Compiler/Treiber, Kernel).

Jitter

Während die erforderliche Kapazität für eine Arbeitslast leicht zu erkennen ist, ist Jitter nebulantes Konzept. Für eine gute Einführung in Jitter als Hindernis der Schnelligkeit siehe DIE FALL DER FEHLENDEN LEISTUNG DES SUPERCOMPUTERS: OPTIMIERTE LEISTUNG IM DIE 8.192 PROZESSOREN VON ASCl Q. Es soll untersucht werden, warum der ASCI Der Q Supercomputer hat seine erwartete Leistung nicht erreicht und ist eine großartige Optimierung großer Systeme.)

Auf dieser Seite wird mit dem Begriff Jitter beschrieben, was in der Q-Papier von ASCI genannt wird. Rauschen erkennen. Jitter ist ein zufälliges Systemverhalten, davon abgelenkt werden. Es ist oft eine Arbeit, die ausgeführt werden muss, aber nicht strikt die eine Ausführung zu einem bestimmten Zeitpunkt bewirken. Weil es ist es äußerst schwierig, das Vorhandensein von Jitter für einen Arbeitsbelastung. Es ist auch äußerst schwierig, nachzuweisen, dass eine bekannte Quelle der Jitter war die Ursache eines Leistungsproblems. Die am häufigsten verwendeten Tools die zur Diagnose der Ursachen von Jitter (wie Tracing oder Logging) verwendet werden, ihren eigenen Jitter.

Quellen des Jitters bei realen Android-Implementierungen umfassen:

  • Verzögerung des Planers
  • Handler unterbrechen
  • Treibercode wird zu lange ausgeführt, vorzeitiges Beenden und Unterbrechungen sind deaktiviert
  • Traditionsreiche Softairs
  • Sperrkonflikt (App, Framework, Kernel-Treiber, Binder Lock, Mmap) Schloss)
  • Konflikt mit Dateideskriptoren, bei dem ein Thread mit niedriger Priorität die Sperre für eine und verhindert, dass ein Thread mit hoher Priorität ausgeführt wird.
  • Ausführen von UI-kritischen Code in Arbeitswarteschlangen, wo er verzögert werden könnte
  • Inaktive CPU-Übergänge
  • Protokollierung
  • E/A-Verzögerungen
  • Unnötige Prozesserstellung (z. B. CONNECTIVITY_CHANGE-Broadcasts)
  • Seiten-Cache-Pflanzen aufgrund von unzureichendem kostenlosen Speicher

Die erforderliche Zeit für einen bestimmten Jitter-Zeitraum kann nimmt die Kapazität ab. z. B. wenn ein Fahrer deaktiviert ist, während auf einen Lesevorgang von einer anderen Seite des i2c-Busses aus unabhängig davon, ob die CPU mit 384 MHz oder 2 GHz arbeitet. Steigerung ist die Kapazität keine praktikable Lösung zur Verbesserung der Leistung, wenn der Jitter beteiligt sind. Daher verbessern sich schnellere Prozessoren in der Regel die Leistung bei Jitter-Grenzen zu reduzieren.

Und schließlich liegt der Jitter im Gegensatz zur Kapazität fast vollständig im Bereich des Systemanbieter.

Arbeitsspeicherverbrauch

Der Arbeitsspeicherverbrauch wird üblicherweise für eine schlechte Leistung verantwortlich. Während des Verbrauchs selbst ist kein Leistungsproblem, sondern kann wenig Arbeitsspeicher-Killer-Overhead, Dienstneustarts und Seiten-Cache-Frashing. Sinkend Arbeitsspeichernutzung die direkten Ursachen für schlechte Leistung vermeiden, aber es gibt kann es sich um weitere gezielte Verbesserungen handeln, mit denen diese Ursachen ebenfalls vermieden werden (z. B. Das Framework anheften, um zu verhindern, dass aus einer Paginierung bei einer Paginierung kurz danach).

Analysieren der anfänglichen Geräteleistung

Sie beginnen mit einem funktionierenden, aber leistungsschwachen System und versuchen, das Verhalten des Systems durch die Betrachtung einzelner Fälle von für den Nutzer sichtbaren schlechten Leistung ist keine solide Strategie. Weil eine schlechte Leistung meist nicht leicht zu reproduzieren (d. h. Jitter) oder ein App-Problem verursacht. Viele Variablen im gesamten System verhindern, dass diese Strategie effektiv ist. Als kann es leicht passieren, dass die Ursachen falsch identifiziert und kleinere Verbesserungen vorgenommen werden, während systemische Möglichkeiten zur Verbesserung der Leistung im gesamten System fehlen.

Gehen Sie stattdessen wie folgt vor, wenn Sie eine neue Gerät:

  1. Startet das System auf die Benutzeroberfläche, auf der alle Treiber ausgeführt werden und einige grundlegende Einstellungen des Frequenzreglers (wenn Sie die Einstellungen des Frequenzreglers ändern, wiederholen Sie alle Schritte unten).
  2. Achten Sie darauf, dass der Kernel den Tracepoint sched_blocked_reason unterstützt sowie anderer Tracepoints in der Display-Pipeline, die angeben, wann der Frame an das Display gesendet wird.
  3. lange Traces der gesamten UI-Pipeline erfassen (vom Empfang von Eingaben über einen IRQ) bis zum endgültigen Scan), während eine einfache und konsistente Arbeitslast ausgeführt wird (z. B. UIBench oder den Balltest in TouchLatenz.
  4. Die in der Light- und konsistenten Version erkannten Frame-Einbrüche wurden behoben. Arbeitsbelastung.
  5. Wiederholen Sie die Schritte 3 bis 4, bis Sie mindestens 20 Sekunden lang keine Frames verworfen haben. auf einmal ansehen.
  6. Fahren Sie mit anderen für den Nutzer sichtbaren Verzögerungsquellen fort.

Weitere einfache Dinge, die du zu Beginn der Gerätenutzung tun kannst:

  • Achten Sie darauf, dass Ihr Kernel die sched_blocked_reason Tracepoint-Patch. Dieser Tracepoint ist mit der Kategorie „Zeitplan“ aktiviert in Systrace und stellt die für den Ruhemodus verantwortliche Funktion bereit, wenn diese und wechselt dann in den unterbrechungsfreien Ruhemodus. Sie ist wichtig für die Leistungsanalyse. da unterbrechungsfreier Schlaf häufiger Indikator für Jitter ist.
  • Achten Sie darauf, dass Sie genügend Tracing für die GPU- und Anzeigepipelines haben. An Qualcomm-SoCs von Qualcomm aktiviert haben, werden Tracepoints folgendermaßen aktiviert:
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    Diese Ereignisse bleiben aktiviert, wenn Sie Systrace ausführen, sodass Sie zusätzliche Informationen im Trace über die Anzeigepipeline (MDSS) im mdss_fb0 Abschnitt. Bei Qualcomm-SOCs sehen Sie keine weiteren Informationen zur GPU in der Systrace-Standardansicht, aber die Ergebnisse sind im Trace selbst vorhanden ist (Details finden Sie unter Verstehen, systrace.

    Diese Art von Display-Tracing sollte ein einzelnes Ereignis enthalten, zeigt an, dass ein Frame an den Bildschirm geliefert wurde. Anschließend können Sie können feststellen, ob Sie Ihre Frame Time erfolgreich erreicht haben. wenn Ereignis Xn weniger als 16,7 ms nach Ereignis Xn-1 auftritt (bei einer 60-Hz-Anzeige) dann wissen Sie, dass Sie keine Verzögerung hatten. Sollte Ihr Sicherheitscenter diese Signale nicht bereitstellen, mit dem Zulieferunternehmen zusammenarbeiten, um sie zu erhalten. Die Behebung von Jitter ist ohne ein deutliches Zeichen für den Abschluss des Frames.

Synthetische Benchmarks verwenden

Synthetische Benchmarks sind nützlich, um die grundlegende Funktionalität eines Geräts sicherzustellen. vorhanden ist. Benchmarks jedoch als Proxy für das wahrgenommene Gerät behandeln nicht nützlich ist.

Basierend auf Erfahrungen mit SOCs, Unterschiede beim synthetischen Benchmark der Leistung zwischen SOCs nicht mit einem ähnlichen Unterschied zwischen wahrnehmbare UI-Leistung (Anzahl der verworfenen Frames, Frame im 99. Perzentil) Uhrzeit usw.). Synthetische Benchmarks sind reine Kapazitäts-Benchmarks. Jitter die gemessene Leistung dieser Benchmarks nur durch Stehlen der Zeit die Funktionsweise der Benchmark. Daher sind synthetische Benchmarkwerte als Messwert für die vom Nutzer wahrgenommene Leistung irrelevant.

Nehmen wir zwei SOCs, die Benchmark X ausführen, die 1.000 Frames der Benutzeroberfläche und gibt die gesamte Renderingzeit an (niedrigere Punktzahl ist besser).

  • SOC 1 rendert jeden Frame der Benchmark X in 10 ms und bewertet 10.000.
  • SOC 2 rendert 99% der Frames in 1 ms, aber 1% der Frames in 100 ms und Werte 19.900, eine deutlich bessere Punktzahl.

Wenn der Benchmark Aufschluss über die tatsächliche Leistung der Benutzeroberfläche gibt, wäre SOC 2 unbrauchbar. Bei einer Aktualisierungsrate von 60 Hz hat SOC 2 jedes Mal einen ruckeligen Frame. 1,5 Sekunden des Betriebs. Gleichzeitig wird SOC 1 (das laut Benchmark X gemessene langsamere Sicherheitscenter) fließend.

Fehlerberichte verwenden

Fehlerberichte sind manchmal bei Leistungsanalysen nützlich, sind so komplex, dass sie selten zur Behebung sporadischer Verzögerungen geeignet sind. Sie geben vielleicht Aufschluss darüber, was das System zu einem bestimmten Zeitpunkt besonders, wenn es sich um einen App-Übergang handelte (bei dem eines Fehlerberichts). Fehlerberichte können auch anzeigen, wenn etwas im Allgemeinen ist falsch mit dem System, das seine effektive Kapazität reduzieren könnte (z. B. Drosselung oder Speicherfragmentierung).

TouchLatenz verwenden

Einige Beispiele für unerwünschtes Verhalten sind die bevorzugte regelmäßige Arbeitslast für Pixel und Pixel XL. Erhältlich unter frameworks/base/tests/TouchLatency und hat zwei Modi: Berührungslatenz und den hüpfenden Ball. Um den Modus zu wechseln, klicken Sie auf die Schaltfläche oben rechts Ecke).

Der hüpfende Balltest ist genau so einfach, wie es aussieht: Ein Ball springt um den Bildschirm herum, unabhängig von Benutzereingaben. Üblicherweise sind es auch der bei Weitem schwierigste Test ist, aber je näher er ohne Frames auslassen, desto besser wird Ihr Gerät. Die Ein hüpfendes Balltestverfahren ist schwierig, da es ein triviales, aber absolut konsistentes Ergebnis ist. Arbeitslast, die mit einem sehr niedrigen Takt ausgeführt wird (dafür wird angenommen, dass das Gerät eine Häufigkeit hat, Gouverneur; Wenn das Gerät stattdessen mit festen Uhren betrieben wird, fahren Sie mit der CPU/GPU beim ersten Ausführen des hüpfenden Balltests auf fast das Minimum). Wenn das System ins Stocken gerät und die Uhren näher an den Leerlauf kommen, wird die erforderliche CPU/GPU zunimmt. Sie können den Ball beobachten, auch verpasste Frames in systrace sehen können.

Da die Arbeitslast so konsistent ist, können Sie die meisten Jitter viel leichter als bei den meisten für den Nutzer sichtbaren Arbeitslasten, während jedes verpasste Frames auf dem System statt auf der Benutzeroberfläche zu erstellen. Die niedrigeren Uhren verstärken den Effekt des Jitters, indem sie ist es wahrscheinlicher, dass ein Bild durch Jitter einen verworfenen Frame verursacht. Daher Die Berührungslatenz liegt bei 60 fps, desto geringer ist die Wahrscheinlichkeit, zu sporadischen, schwer zu reproduzierenden Verzögerungen in größeren Apps.

Da Jitter häufig (aber nicht immer) unabhängig von der Taktgeschwindigkeit ist, sollten Sie einen Test verwenden, wird aus folgenden Gründen mit sehr niedrigen Takten ausgeführt, um den Jitter zu diagnostizieren:

  • Nicht der gesamte Jitter ist unabhängig von der Taktgeschwindigkeit. verbrauchen viele Quellen nur CPU .
  • Der Gouverneur sollte die durchschnittliche Frame Time nahe der Frist bis zum Zeit, die nicht mit UI-Elementen verbracht wird, kann das Budget indem Sie einen Frame ziehen.