Instruments — wat is het, mogelijkheden van Time Profiler en Allocations

Wat is Instruments?

Instruments — is een profilering- en traceersysteem dat deel uitmaakt van Xcode en is gebaseerd op DTrace-technologie, ontwikkeld door Sun Microsystems. Instruments combineert tientallen profileringstools (sjablonen) in één interface: selecteer een sjabloon, start de applicatie via Xcode en begin met het verzamelen van gegevens.

De architectuur van Instruments is gebaseerd op een client-servermodel: een agent op het apparaat verzamelt gegevens en stuurt deze via USB naar de Mac. Dit minimaliseert de impact van de profiler op de prestaties van de applicatie — Instruments werkt voornamelijk aan de hostzijde. Volgens WWDC 2022 is de overhead van Time Profiler bij een samplefrequentie van 1 ms minder dan 3%.

Instruments ondersteunt aangepaste sjablonen — de ontwikkelaar kan meerdere tools combineren in één profilering sessie. Bijvoorbeeld tegelijkertijd Time Profiler + Allocations + Leaks starten en de correlatie zien tussen CPU-pieken en geheugentoewijzingen. Dit geeft een compleet prestatiebeeld dat niet beschikbaar is bij geïsoleerde analyse van elke component.

Welke sjablonen zijn standaard beschikbaar

Xcode wordt geleverd met 16 vooraf geïnstalleerde Instruments-sjablonen: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace en andere. Elk sjabloon is geoptimaliseerd voor een specifieke taak en vooraf geconfigureerd met de juiste trigger- en filterinstellingen.

Time Profiler: CPU-prestatieanalyse

Time Profiler — is het meest gebruikte Instruments-sjabloon. Het werkt op basis van sampling van de call-stack: elke 1-10 milliseconden legt het systeem de call-stack van alle threads van de applicatie vast. Na het stoppen van de sessie sommeert Instruments de samples en toont welke methoden en functies de meeste tijd in beslag hebben genomen. Het resultaat wordt gepresenteerd als een Call Tree — een aanroepboom gesorteerd op Self Weight.

De belangrijkste metriek van Time Profiler — Self Weight (de tijd die direct in de methode wordt doorgebracht, exclusief aanroepen van kindmethoden). Juist Self Weight toont welke functies de processor echt belasten. Weight (totale tijd met kindmethoden) kan misleidend zijn: een methode met hoge Weight kan simpelweg een andere langzame methode aanroepen, terwijl deze zelf snel is.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler zal tonen dat cellForItemAt Self Weight = 40% heeft
    // daarbinnen neemt decodeImage 35% in beslag — dit is een knelpunt

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

Let bij het analyseren van Time Profiler op methoden die worden uitgevoerd in com.apple.main-thread. Als op de hoofdthread Self Weight de drempel van 16 ms per frame overschrijdt — zal de UI traag zijn. De oplossing voor dergelijke problemen — het verplaatsen van decoderen van afbeeldingen, lay-outberekeningen en gegevensverwerking van de hoofdthread naar de achtergrond via Grand Central Dispatch (GCD).

Hoe lees je Call Tree in Time Profiler

Call Tree — is een hiërarchische weergave van alle methodeaanroepen, gesorteerd op Self Weight. De zwaarste methode in Call Tree — de eerste regel. Door de regel uit te vouwen, zie je welke kindmethoden deze methode heeft aangeroepen en hoeveel tijd ze hebben ingenomen. Zoek naar methoden waar Self Weight (eigen tijd) aanzienlijk hoger is dan Weight (totale tijd) — dit zijn tekenen van synchrone blokkades en wachttijd.

Allocations: real-time geheugenbewaking

Allocations — is een tool voor het bewaken van alle geheugentoewijzingen van de applicatie. Het toont welke objecten, in welke hoeveelheid en met welke totale grootte op elk moment worden gemaakt. In tegenstelling tot Memory Profiler in Android Studio, ondersteunt Allocations Heapshot — een momentopname van levende objecten met de mogelijkheid om twee momentopnamen te vergelijken.

De interface van Allocations bestaat uit twee hoofdsecties: All Allocations (samenvattende statistiek per objecttype) en Call Trees (aanroepboom met uitsplitsing per methode die objecten maakt). Gebruik Heapshot Analysis om lekken te vinden: maak een momentopname vóór het uitvoeren van het scenario, voer het scenario uit, maak een momentopname erna — en vergelijk welke nieuwe objecten in het geheugen zijn achtergebleven.

Volgens Apple Developer Documentation is het meest voorkomende lekpatroon dat door Allocations wordt gedetecteerd — overmatig aanmaken van UIView en CALayer tijdens het scrollen van collecties. Als bij elke scroll het aantal levende UIView toeneemt, terwijl de collectie cellen hergebruikt — worden er ergens extra views aangemaakt zonder oude vrij te geven. Allocations toont de exacte call-stack waar deze views worden gemaakt.

Heapshot Analysis: vergelijken van geheugenmomentopnamen

Heapshot — is een momentopname van levende objecten in Allocations. Maak een Heapshot vóór het uitvoeren van het scenario, voer het scenario uit en maak een tweede Heapshot. Het verschil tussen de momentopnamen toont welke objecten zijn gemaakt en niet zijn vrijgegeven. Het ideale resultaat — groei alleen van tijdelijke objecten (Autorelease pool). Gebruik voor nauwkeurige analyse de combinatie Allocations + Leaks in één sessie. Allocations toont welke objecten niet worden vrijgegeven, en Leaks — waarom (welke sterke referentie ze vasthoudt). Start een dubbele sessie bij elk vermoeden van een lek.

Leaks: automatisch zoeken naar geheugenlekken

Leaks — is een gespecialiseerd hulpmiddel voor het detecteren van geheugenlekken in iOS- en macOS-applicaties. In tegenstelling tot Allocations, dat alleen toewijzingen toont, scant Leaks actief de heap op zoek naar retain cycles — situaties waarin twee of meer objecten elkaar wederzijds vasthouden met sterke referenties.

Leaks werkt samen met Cycles & Roots — een visualisator van de objectretentiefgraaf. Wanneer een lek wordt gedetecteerd, toont Leaks alle objecten in de cyclus, hun retain count en de exacte velden waarmee referenties worden doorgegeven. De ontwikkelaar hoeft alleen naar de graaf te kijken en te begrijpen welke referentie moet worden vervangen door weak.

De tool markeert lekken automatisch met een rode marker op de tijdlijn. Leaks werkt in real-time: zodra het systeem een lek detecteert, signaleert het onmiddellijk de ontwikkelaar. Dit maakt het mogelijk om problemen ter plekke op te lossen, zonder te wachten op een dump en post-analyse.

Volgens WWDC 2022 is Leaks in staat om zelfs complexe meerlaagse retain cycles te detecteren — bijvoorbeeld wanneer drie of meer objecten een gesloten keten van sterke referenties vormen. Voor de diagnose van dergelijke cycli is de Cycles & Roots-graaf onmisbaar: hij toont visueel hoe objecten op elkaar zijn gesloten.

Hoe lees je de Cycles & Roots-graaf

Elk knooppunt van de graaf is een object, elke pijl — een sterke referentie. Een cyclus — een gesloten contour van pijlen. De kleur van het knooppunt toont de status: rood — gelekt object, groen — wortel (GC Root), grijs — tussenliggend object. Om een lek te verhelpen, vind de pijl die weak kan worden gemaakt zonder de logica te schenden — en vervang het referentietype in de code.

Energy Log: analyse van energieverbruik

Energy Log — is een Instruments-sjabloon voor het meten van het energieverbruik van de applicatie. Het verzamelt gegevens van de hardware-sensoren van het apparaat: CPU-belasting, Wi-Fi- en mobiele netwerkstatus, GPS-gebruik, display en Bluetooth. Energy Log toont welke bewerkingen in de applicatie het meeste batterijverbruik veroorzaken en legt ze op de energieverbruikgrafiek over de tijd.

De tool classificeert bewerkingen op energieverbruikniveau: laag (normale processorwerking), gemiddeld (Wi-Fi-transmissie), hoog (GPS, mobiel netwerk, GPU). Als Energy Log gedurende lange tijd rode indicatoren van een hoog niveau toont — verbruikt de applicatie de batterij op de achtergrond en wordt door de gebruiker verwijderd.

Typische problemen die door Energy Log worden gedetecteerd: WakeLock zonder tijdsbeperking (de applicatie houdt de processor actief na voltooiing van de taak), Location Updates met hoge nauwkeurigheid op de achtergrond (elke paar seconden een coördinaataanvraag), afwijkingen in netwerksessies (veelvuldig opnieuw verbinden met de server). Energy Log adviseert om elk dergelijk incident vast te leggen en een voorwaarde toe te voegen voor het uitschakelen van de energie-intensieve bewerking.

Gebruik voor het testen van energieverbruik een echt apparaat op batterijvoeding — op de emulator zijn de energieverbruiksindicatoren onjuist. Start Energy Log samen met UI-tests om de batterijcontrole in CI te automatiseren.

Hoe Instruments te starten en resultaten te interpreteren

Instruments starten vanuit Xcode kan op twee manieren: via het menu Product → Profile (⌘I) of door Instruments als aparte applicatie te openen in Launchpad. De eerste manier is handiger: Xcode bouwt de applicatie automatisch in profilermodus en start deze op het aangesloten apparaat met het geselecteerde sjabloon. Na het stoppen van de sessie slaat Instruments de trace op in een bestand met de extensie .trace.

De interpretatie van resultaten hangt af van het sjabloon. Voor Time Profiler kijk naar Call Tree gesorteerd op Self Weight — de bovenste methoden zijn je belangrijkste knelpunten. Voor Allocations — naar # Living na een cyclisch scenario: als het aantal objecten is toegenomen, zoek dan naar een lek. Voor Leaks — naar de rode markers en de Cycles & Roots-graaf. Vergelijk resultaten voor en na optimalisatie — dit is de enige manier om de effectiviteit van wijzigingen te bevestigen.

// Opdrachtregel voor Instruments in CI
// Integratie van Instruments in CI/CD-pipeline
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Scrolltijd van collectie meten
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

In CI kan Instruments worden gestart vanaf de opdrachtregel via xcodebuild -showBuildSettings en xcrun xctrace. Dit maakt het mogelijk om profilering bij elke commit te automatiseren en regressie te voorkomen. Gebruik voor analyse Baseline-vergelijking: als de metriek met 5% is verslechterd ten opzichte van de vorige commit — moet de pipeline stoppen.

De belangrijkste fouten bij het werken met Instruments: profilering op de simulator in plaats van op het apparaat (CPU- en GPU-gegevens zijn onjuist), gegevens verzamelen zonder scenario (resultaten zijn willekeurig), negeren van Call Tree (alleen naar de grafiek kijken, niet naar specifieke methoden). Het corrigeren van deze fouten levert 80% van de profileringkwaliteit.