Instruments — was ist das, Funktionen von Time Profiler und Allocations

Was ist Instruments?

Instruments — ist ein Profiling- und Trace-System, das Teil von Xcode ist und auf der von Sun Microsystems entwickelten DTrace-Technologie basiert. Instruments vereint Dutzende von Profiling-Werkzeugen (Vorlagen) in einer einheitlichen Oberfläche: Wählen Sie einfach eine Vorlage aus, starten Sie die Anwendung über Xcode und beginnen Sie mit der Datenerfassung.

Die Architektur von Instruments basiert auf einem Client-Server-Modell: Ein Agent auf dem Gerät sammelt Daten und überträgt sie über USB an den Mac. Dies minimiert die Auswirkungen des Profilers auf die Anwendungsleistung — Instruments arbeitet hauptsächlich auf der Hostseite. Laut WWDC 2022 beträgt der Overhead des Time Profilers bei einer Abtastrate von 1 ms weniger als 3%.

Instruments unterstützt benutzerdefinierte Vorlagen — der Entwickler kann mehrere Werkzeuge in einer einzigen Profiling-Sitzung kombinieren. Beispielsweise können Sie Time Profiler + Allocations + Leaks gleichzeitig starten und die Korrelation zwischen CPU-Spitzen und Speicherallokationen sehen. Dies ergibt ein ganzheitliches Leistungsbild, das bei isolierter Analyse jeder Komponente nicht verfügbar ist.

Welche Vorlagen sind standardmäßig verfügbar

Xcode wird mit 16 vorinstallierten Instruments-Vorlagen ausgeliefert: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace und andere. Jede Vorlage ist für eine bestimmte Aufgabe optimiert und mit den richtigen Trigger- und Filtereinstellungen vorkonfiguriert.

Time Profiler: CPU-Leistungsanalyse

Time Profiler — ist die am häufigsten verwendete Instruments-Vorlage. Sie basiert auf dem Sampling des Aufrufstapels: Alle 1–10 Millisekunden zeichnet das System den Aufrufstapel aller Threads der Anwendung auf. Nach dem Stoppen der Sitzung summiert Instruments die Samples und zeigt, welche Methoden und Funktionen die meiste Zeit in Anspruch genommen haben. Das Ergebnis wird als Call Tree dargestellt — ein Aufrufbaum, sortiert nach Self Weight.

Die wichtigste Metrik des Time Profilers ist Self Weight (die direkt in der Methode verbrachte Zeit, ohne Aufrufe von Kind-Methoden). Der Self Weight zeigt, welche Funktionen tatsächlich den Prozessor belasten. Der Weight (Gesamtzeit mit Kind-Methoden) kann irreführend sein: Eine Methode mit hohem Weight ruft möglicherweise nur eine andere langsame Methode auf, ist aber selbst schnell.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler zeigt, dass cellForItemAt Self Weight = 40% hat
    // innerhalb davon belegt decodeImage 35% — das ist der Engpass

    func collectionView(
        _ collectionView: UICollectionView,
        cellForItemAt indexPath: IndexPath
    ) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: "ImageCell",
            for: indexPath
        ) as! ImageCell
        // ❌ decodeImage — Engpass (Self Weight = 35%)
        cell.imageView.image = UIImage(contentsOfFile: imagePath)
        return cell
    }
}

Achten Sie bei der Analyse des Time Profilers auf Methoden, die im com.apple.main-thread ausgeführt werden. Wenn der Self Weight im Hauptthread den Schwellenwert von 16 ms pro Frame überschreitet, wird die UI träge. Die Lösung solcher Probleme besteht darin, die Bilddekodierung, Layoutberechnungen und Datenverarbeitung mithilfe von Grand Central Dispatch (GCD) aus dem Hauptthread in einen Hintergrundthread zu verschieben.

So lesen Sie den Call Tree im Time Profiler

Call Tree — ist eine hierarchische Darstellung aller Methodenaufrufe, sortiert nach Self Weight. Die schwerste Methode im Call Tree ist die erste Zeile. Wenn Sie die Zeile erweitern, sehen Sie, welche Kind-Methoden diese Methode aufgerufen hat und wie viel Zeit sie in Anspruch genommen haben. Suchen Sie nach Methoden, bei denen der Self Weight (eigene Zeit) den Weight (Gesamtzeit) deutlich übersteigt — das sind Anzeichen für synchrone Blockierungen und Wartezeiten.

Allocations: Echtzeit-Speicherverfolgung

Allocations — ist ein Werkzeug zur Überwachung aller Speicherallokationen der Anwendung. Es zeigt, welche Objekte, in welcher Anzahl und mit welcher Gesamtgröße zu jedem Zeitpunkt erstellt werden. Anders als der Memory Profiler in Android Studio unterstützt Allocations Heapshot — eine Momentaufnahme lebender Objekte mit der Möglichkeit, zwei Aufnahmen zu vergleichen.

Die Oberfläche von Allocations besteht aus zwei Hauptbereichen: All Allocations (Gesamtstatistik nach Objekttyp) und Call Trees (Aufrufbaum mit Aufschlüsselung nach Methoden, die Objekte erstellen). Verwenden Sie zur Suche nach Lecks die Heapshot-Analyse: Machen Sie eine Aufnahme vor der Ausführung eines Szenarios, führen Sie das Szenario aus, machen Sie eine Aufnahme danach — und vergleichen Sie, welche neuen Objekte im Speicher geblieben sind.

Laut Apple Developer Documentation ist das häufigste durch Allocations entdeckte Leckmuster die übermäßige Erstellung von UIView und CALayer beim Scrollen von Collections. Wenn bei jedem Scrollen die Anzahl der lebenden UIView steigt, die Collection aber Zellen wiederverwendet — werden irgendwo zusätzliche Views erstellt, ohne alte freizugeben. Allocations zeigt den genauen Aufrufstapel, an dem diese Views erstellt werden.

Heapshot-Analyse: Vergleich von Speicheraufnahmen

Heapshot — ist eine Momentaufnahme lebender Objekte in Allocations. Machen Sie einen Heapshot vor der Ausführung des Szenarios, führen Sie das Szenario aus und machen Sie einen zweiten Heapshot. Die Differenz zwischen den Aufnahmen zeigt, welche Objekte erstellt und nicht freigegeben wurden. Das ideale Ergebnis ist nur ein Anstieg temporärer Objekte (Autorelease-Pool). Verwenden Sie für eine genaue Analyse die Kombination Allocations + Leaks in einer Sitzung. Allocations zeigt, welche Objekte nicht freigegeben werden, und Leaks zeigt, warum (welche starke Referenz sie hält). Starten Sie bei jedem Leckverdacht eine Doppelsitzung.

Leaks: Automatische Speicherleck-Suche

Leaks — ist ein spezialisiertes Werkzeug zur Erkennung von Speicherlecks in iOS- und macOS-Anwendungen. Anders als Allocations, das nur Allokationen anzeigt, scannt Leaks aktiv den Heap auf der Suche nach Retain Cycles — Situationen, in denen zwei oder mehr Objekte einander mit starken Referenzen halten.

Leaks arbeitet mit Cycles & Roots zusammen — einem Visualisierer des Objektbindungsgraphen. Wenn ein Leck erkannt wird, zeigt Leaks alle Objekte im Zyklus, ihre Retain Counts und die genauen Felder, über die Referenzen weitergegeben werden. Der Entwickler muss nur den Graphen betrachten und verstehen, welche Referenz durch weak ersetzt werden muss.

Das Werkzeug markiert Lecks automatisch mit einem roten Marker auf der Zeitachse. Leaks arbeitet in Echtzeit: Sobald das System ein Leck erkennt, signalisiert es dies sofort dem Entwickler. Dies ermöglicht es, Probleme „vor Ort“ zu beheben, ohne auf einen Dump und eine Nachanalyse warten zu müssen.

Laut WWDC 2022 kann Leaks sogar komplexe mehrstufige Retain Cycles erkennen — zum Beispiel, wenn drei oder mehr Objekte eine geschlossene Kette starker Referenzen bilden. Zur Diagnose solcher Zyklen ist der Cycles & Roots-Graph unverzichtbar: Er zeigt visuell, wie Objekte aufeinander verweisen.

So lesen Sie den Cycles & Roots-Graphen

Jeder Knoten des Graphen ist ein Objekt, jeder Pfeil ist eine starke Referenz. Ein Zyklus ist eine geschlossene Schleife von Pfeilen. Die Farbe des Knotens zeigt den Status: rot — ausgelaufenes Objekt, grün — Wurzel (GC Root), grau — Zwischenobjekt. Um das Leck zu beheben, finden Sie einen Pfeil, der ohne Logikverletzung schwach gemacht werden kann — und ändern Sie den Referenztyp im Code.

Energy Log: Energieverbrauchsanalyse

Energy Log — ist eine Instruments-Vorlage zur Messung des Energieverbrauchs der Anwendung. Es sammelt Daten von den Hardware-Sensoren des Geräts: CPU-Auslastung, Zustand von WLAN und Mobilfunk, GPS-Nutzung, Display und Bluetooth. Energy Log zeigt, welche Operationen in der Anwendung den größten Batterieverbrauch verursachen, und überlagert sie mit einem Energieverbrauchsdiagramm über die Zeit.

Das Werkzeug klassifiziert Operationen nach Energieverbrauchsstufe: niedrig (normale Prozessorarbeit), mittel (WLAN-Übertragung), hoch (GPS, Mobilfunknetz, GPU). Wenn Energy Log über einen längeren Zeitraum rote Indikatoren der hohen Stufe anzeigt — entlädt die Anwendung im Hintergrund die Batterie und wird vom Benutzer gelöscht.

Typische durch Energy Log erkannte Probleme: WakeLock ohne Zeitbegrenzung (Anwendung hält den Prozessor nach Aufgabenende aktiv), Location Updates mit hoher Genauigkeit im Hintergrund (alle paar Sekunden Koordinatenanfragen), Anomalien bei Netzwerksitzungen (häufige Wiederverbindungen zum Server). Energy Log empfiehlt, jeden solchen Vorfall zu protokollieren und eine Bedingung zum Ausschalten der energieintensiven Operation hinzuzufügen.

Verwenden Sie zum Testen des Energieverbrauchs ein echtes Gerät mit Batteriebetrieb — im Emulator sind die Energieverbrauchswerte ungenau. Führen Sie Energy Log zusammen mit UI-Tests aus, um die Batterieverbrauchsprüfung im CI zu automatisieren.

So starten und interpretieren Sie Instruments-Ergebnisse

Der Start von Instruments erfolgt aus Xcode auf zwei Arten: über das Menü Product → Profile (⌘I) oder durch Öffnen von Instruments als separate Anwendung im Launchpad. Die erste Methode ist bequemer: Xcode erstellt die Anwendung automatisch im Profiling-Modus und startet sie auf dem angeschlossenen Gerät mit der ausgewählten Vorlage. Nach dem Stoppen der Sitzung speichert Instruments den Trace in einer Datei mit der Erweiterung .trace.

Die Interpretation der Ergebnisse hängt von der Vorlage ab. Für den Time Profiler sehen Sie sich den nach Self Weight sortierten Call Tree an — die obersten Methoden sind Ihre Hauptengpässe. Für Allocations — sehen Sie sich # Living nach einem zyklischen Szenario an: Wenn die Anzahl der Objekte gestiegen ist, suchen Sie ein Leck. Für Leaks — sehen Sie sich die roten Marker und den Cycles & Roots-Graphen an. Vergleichen Sie die Ergebnisse vor und nach der Optimierung — dies ist der einzige Weg, die Wirksamkeit von Änderungen zu bestätigen.

// Befehlszeile für Instruments im CI
// Integration von Instruments in die CI/CD-Pipeline
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Messen der Scrollzeit der Collection
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

Im CI können Sie Instruments über die Befehlszeile mit xcodebuild -showBuildSettings und xcrun xctrace ausführen. Dies ermöglicht die Automatisierung des Profilings bei jedem Commit und das Vermeiden von Regressionen. Verwenden Sie für die Analyse einen Baseline-Vergleich: Wenn sich die Metrik um 5% gegenüber dem vorherigen Commit verschlechtert hat, sollte die Pipeline anhalten.

Hauptfehler bei der Arbeit mit Instruments: Profiling im Simulator statt auf dem Gerät (CPU- und GPU-Daten sind ungenau), Datenerfassung ohne Szenario (Ergebnisse sind zufällig), Ignorieren des Call Trees (nur auf das Diagramm schauen, nicht auf die spezifischen Methoden). Die Korrektur dieser Fehler bringt 80% der Profiling-Qualität.