Traceview: Was es ist, Android-Tracing- und Profiling-Tool

Was ist Traceview in Android

Traceview ist ein in Android Studio integrierter grafischer Profiler, der Ausführungsspuren von Android-Anwendungsmethoden als Zeitleiste und Aufruftabelle anzeigt. Es ist Teil des Android SDK und über Android Profiler ab Android Studio 3.0 sowie über das Befehlszeilentool dmtracedump verfügbar.

Zweck des Werkzeugs

Die Hauptaufgabe von Traceview besteht darin, Entwicklern zu helfen, Methoden zu finden, die die meiste CPU-Zeit verbrauchen. Im Gegensatz zur einfachen Protokollierung zeichnet Traceview die genaue Ein- und Austrittszeit jeder Methode auf, erstellt ein Call Chart und einen Top-Down-Baum, was eine visuelle Erkennung von Leistungsanomalien ermöglicht. Das Tool ist besonders nützlich beim Profiling des UI-Threads, wo eine Verzögerung von 16 ms zu einem Frame-Drop führt.

Geschichte und Entwicklung

Traceview erschien erstmals in frühen Versionen des Android SDK als eigenständiges Dienstprogramm zum Anzeigen von .trace-Dateien. Mit der Veröffentlichung von Android Studio 3.0 (2017) wurde es Teil des Android Profiler und erhielt eine Integration mit Live-CPU-, Speicher- und Netzwerk-Zeitleisten. Laut Google I/O 2018 entwickelt das Android Studio-Team den Profiler weiter und fügt Unterstützung für nativen Code über systrace und perfetto hinzu. In aktuellen Versionen von Android Studio arbeitet Traceview auf dem Perfetto-Format, behält aber die Abwärtskompatibilität mit dem klassischen .trace-Format bei.

Wie Traceview funktioniert

Traceview erhält Daten vom System Tracing-Mechanismus in der Android Runtime (ART). Wenn eine Anwendung mit aktiviertem Tracing gestartet wird, zeichnet ART die Start- und Endzeitstempel jeder ausgeführten Methode auf, einschließlich Klassenname, Methodenname und Thread-ID.

// Start der Ablaufverfolgung im App-Code
Debug.startMethodTracing("app_trace")

// Kritischer Codeabschnitt für die Profilerstellung
loadHeavyData()

// Stopp der Ablaufverfolgung — Datei auf dem Gerät gespeichert
Debug.stopMethodTracing()

System Tracing arbeitet auf der Ebene der ART-Virtual Machine und zeichnet jeden Methodenaufruf mit Mikrosekunden-Genauigkeit auf. Daten werden in einen Ringpuffer geschrieben, um die Auswirkungen auf die Anwendungsleistung zu minimieren. Nach dem Stoppen des Tracings wird der Puffer in eine .trace-Datei im internen Speicher des Geräts geleert.

.trace-Dateiformat

Eine .trace-Datei enthält einen Header mit der Formatversion und der Startzeit, gefolgt von Datensätzen für jeden Aufruf: Thread-ID, Methoden-ID, Eintrittszeitstempel und Austrittszeitstempel. Android Studio lädt die .trace-Datei automatisch und erstellt zwei Hauptansichten: das Zeitleisten-Panel für die Chronologie und das Profil-Panel für die Aufrufhierarchie. Standardmäßig beträgt die maximale Puffergröße 8 MB, kann aber über Debug.startMethodTracing(filename, maxSize) erhöht werden.

Hauptfunktionen von Traceview

Traceview bietet mehrere komplementäre Datenansichten, die jeweils eine spezifische Aufgabe bei der Leistungsanalyse lösen.

Call Chart (Aufrufdiagramm)

Call Chart ist eine horizontale Zeitleiste, in der jeder Thread als separate Spur angezeigt wird. Methoden werden als farbige Rechtecke dargestellt: Die Breite des Rechtecks ist proportional zur Ausführungszeit, und die Verschachtelung spiegelt die Aufrufhierarchie wider. Wenn eine Methode eine andere Methode aufruft, wird das untergeordnete Rechteck innerhalb des übergeordneten Rechtecks gezeichnet. Diese Visualisierung ermöglicht die sofortige Identifizierung von Operationen, die den Thread blockiert haben.

Top-Down- und Bottom-Up-Bäume

Der Top-Down-Baum zeigt die Ausführungszeit einer Methode einschließlich aller ihrer verschachtelten Aufrufe — Inclusive Time. Der Bottom-Up-Baum hingegen zeigt, welche übergeordneten Methoden eine bestimmte Methode aufgerufen haben — nützlich, um die Quelle einer aufwändigen Operation zu finden. Der Unterschied zwischen Inclusive und Exclusive Time ist entscheidend: Eine Methode kann selbst schnell ausgeführt werden, aber eine langsame untergeordnete Methode aufrufen, und dies ist nur in der Inclusive Time sichtbar.

Suche und Filterung

Traceview unterstützt die Suche nach Methodennamen, Paket oder Klasse. Ergebnisse werden auf der Zeitleiste hervorgehoben und das Profil-Panel zeigt nur Statistiken für die gefundenen Methoden an. Die Filterung nach Threads ist ebenfalls verfügbar — Sie können Hintergrund-Threads ausblenden und sich auf den Haupt- (UI) Thread konzentrieren, wo Verzögerungen am kritischsten sind.

Datenexport

Traceview ermöglicht den Export von Spuren im CSV-Format zur weiteren Analyse in Tabellenkalkulationen oder Diagrammen. In Android Studio können Sie auch ein ausgewähltes Zeitleistenfragment als Bild kopieren — zum Einfügen in Fehlerberichte oder Dokumentationen. Für CI/CD ist der Export im Perfetto-Format über das cmdline-tools-Dienstprogramm verfügbar.

So verwenden Sie Traceview in Android Studio

Profiling über Traceview ist auf zwei Arten verfügbar: über Android Profiler mit Live-Erfassung und über programmatische Debug-API-Aufrufe. Die erste Methode ist für Ad-hoc-Analysen geeignet, die zweite für reproduzierbare Leistungstests.

Erfassung über Android Profiler

Öffnen Sie in Android Studio den Profiler-Tab (View → Tool Windows → Profiler), wählen Sie Ihr Gerät und den Anwendungsprozess aus. Klicken Sie auf das CPU-Segment, wählen Sie dann den Modus „Trace Java Methods“ und klicken Sie auf Record. Nach der Interaktion mit der Anwendung klicken Sie auf Stop — Traceview öffnet automatisch die aufgezeichnete Spur. Die Standardaufzeichnungsdauer ist auf 30 Sekunden begrenzt, aber das Limit kann in den Profiler-Einstellungen geändert werden.

Programmatischer Tracing-Start

Für ein präzises Profiling eines bestimmten Codeabschnitts verwenden Sie Debug.startMethodTracing und Debug.stopMethodTracing. Die Datei wird im externen Speicher der Anwendung unter dem Pfad gespeichert, der von context.getExternalFilesDir(null) zurückgegeben wird. Übertragen Sie nach Abschluss die .trace-Datei über den Android Studio Device Explorer auf Ihren Computer und öffnen Sie sie dann über File → Open in Android Studio.

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

Konfiguration der Tracing-Parameter

Debug.startMethodTracing akzeptiert drei Parameter: den Dateinamen (ohne Erweiterung), die maximale Puffergröße (Standard 8 MB) und Flags. Das Flag TRACE_COUNT_ALLOCS fügt die Zählung von Objektallokationen hinzu — nützlich zum Auffinden von Speicherlecks. Traceview ist nicht für das Profiling von nativem Code geeignet — verwenden Sie SimplePerf oder Perfetto. Für lange Tests (über 30 Sekunden) wird empfohlen, den Puffer über den Parameter maxSize auf 64–128 MB zu erhöhen.

Lesen der Traceview-Zeitleiste

Die Traceview-Zeitleiste besteht aus zwei Bereichen: dem oberen Zeitleistenbereich mit farbigen Aufrufrechtecken und dem unteren Profilbereich mit einer Statistik-Tabelle. Der Zeitleistenbereich zeigt die Thread-Ausführung von links nach rechts, wobei jedes Rechteck ein einzelner Methodenaufruf ist. Die Farben der Rechtecke sind nach Methodentyp codiert: Android-Systemaufrufe (grün), Anwendungsmethoden (blau), Bibliotheksaufrufe (orange).

So lesen Sie das Profil-Panel

Im Profil-Panel ist jede Zeile eine Methode mit Spalten für Inclusive Time, Exclusive Time, Calls + Recur und CPU Time. Sortieren Sie die Tabelle nach Inclusive Time (absteigend), um zuerst die Methoden zu sehen, die insgesamt die meiste Zeit in Anspruch genommen haben. Wenn eine Methode mit hoher Inclusive Time eine niedrige Exclusive Time hat — liegt das Problem in ihren untergeordneten Aufrufen, und Sie müssen den Baum erweitern. Beispielsweise kann ListView.getView aufgrund von Bildladeaufrufen eine hohe Inclusive Time aufweisen.

Identifizierung von Engpässen

Suchen Sie nach Methoden mit ungewöhnlich hoher Real Time aber niedriger CPU Time — dies deutet auf Blockierung hin (E/A-Wartezeit, Netzwerkoperation, Sperrkonflikt). Methoden mit hoher CPU Time erfordern eine Algorithmusoptimierung. Für den UI-Thread muss jede Methode innerhalb von 16 ms abgeschlossen sein — wenn ein Aufruf diesen Schwellenwert überschreitet, verwirft die Anwendung einen Frame und der Benutzer sieht Ruckeln. Nach Google-Empfehlungen sollte die Gesamtzeit aller Aufrufe im UI-Thread pro Frame 8–10 ms nicht überschreiten, um einen Spielraum für Systemoperationen zu lassen.

Traceview vs Systrace: Werkzeugvergleich

Obwohl sowohl Traceview als auch Systrace Android-Tracing-Werkzeuge sind, lösen sie unterschiedliche Aufgaben und werden in verschiedenen Profiling-Phasen eingesetzt. Der Hauptunterschied ist die Detailgenauigkeit: Traceview arbeitet auf der Ebene von Java/Kotlin-Methoden, Systrace auf der Ebene von Systemprozessen (CPU, GPU, Binder, SurfaceFlinger).

In der Praxis ergänzen sich beide Werkzeuge: Zunächst hilft Systrace zu identifizieren, welche Systemkomponente das Problem verursacht (z. B. häufige GC oder Binder-Sperren), dann ermöglicht Traceview einen tieferen Einblick in eine bestimmte Methode innerhalb der Anwendung. In Android Studio sind beide Werkzeuge im Android Profiler vereint — CPU Profiler wählt automatisch den optimalen Aufnahmemodus aus. Auf Geräten mit Android 12+ arbeiten Systrace und Traceview auf Perfetto-Basis und bieten ein einheitliches Datenformat für alle Arten des Profilings.

Codebeispiele mit Traceview

Effektives Profiling erfordert mehr als nur das Starten des Tracings — Sie müssen die Erfassungspunkte richtig platzieren und die Ergebnisse interpretieren. Nachfolgend finden Sie zwei praktische Beispiele: Profiling des RecyclerView-Ladens und Vergleich zweier Algorithmen in einem Leistungstest.

Profiling des RecyclerView-Ladens

Das erste Beispiel ist das Tracing des kritischen Pfads während des Listen-Scrollens. RecyclerView ruft onBindViewHolder für jedes sichtbare Element auf, und wenn diese Methode länger als 16 ms dauert, wird das Scrollen ruckelig. Das Tracing um onBindViewHolder herum zeigt, welche spezifischen Operationen darin Zeit in Anspruch nehmen.

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

Vergleich zweier Algorithmen

Das zweite Beispiel ist ein A/B-Geschwindigkeitstest zweier Implementierungen: Laden von Bildern über Glide versus manuelles BitmapFactory. Diese Spur ermöglicht einen objektiven Vergleich der Inclusive Time beider Strategien und die Auswahl der optimalen. Es ist wichtig, jeden Test auf einem aufgewärmten Gerät (nach 3–5 Zyklen) unter identischen Bedingungen (Hintergrundlast, Temperatur) durchzuführen.

fun compareImageLoadingStrategies() {
    // Test A: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

    // Test B: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

Öffnen Sie nach der Ausführung beide .trace-Dateien in Android Studio und vergleichen Sie die Inclusive Time im Profil-Panel. Wenn Glide für die gleiche Aufgabe eine 3x geringere Inclusive Time zeigt — ist dies eine objektive Grundlage, die Bibliothek zu wählen. Laut Tony John (Glide-Entwickler, 2023) verwendet die Bibliothek Caching und einen Thread-Pool, was bei wiederholten Ladevorgängen einen Gewinn von bis zu 40% bietet.