Instruments — vad är det, funktioner i Time Profiler och Allocations

Vad är Instruments?

Instruments — är ett profilerings- och spårningssystem som ingår i Xcode och bygger på DTrace-teknik utvecklad av Sun Microsystems. Instruments kombinerar dussintals profileringsverktyg (mallar) i ett enhetligt gränssnitt: välj bara en mall, starta applikationen via Xcode och börja samla in data.

Arkitekturen för Instruments är baserad på en klient-servermodell: en agent på enheten samlar in data och överför den till Macen via USB-anslutning. Detta minimerar profilerarens påverkan på applikationens prestanda — Instruments arbetar främst på värdens sida. Enligt WWDC 2022 är overheaden för Time Profiler vid en samplingsfrekvens på 1 ms mindre än 3%.

Instruments stöder anpassade mallar — utvecklaren kan kombinera flera verktyg i en profileringssession. Till exempel samtidigt köra Time Profiler + Allocations + Leaks och se korrelationen mellan CPU-toppar och minnesallokeringar. Detta ger en helhetsbild av prestanda som inte är tillgänglig vid isolerad analys av varje komponent.

Vilka mallar är tillgängliga som standard

Xcode levereras med 16 förinstallerade Instruments-mallar: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace och andra. Varje mall är optimerad för en specifik uppgift och förkonfigurerad med rätt trigger- och filterinställningar.

Time Profiler: CPU-prestandaanalys

Time Profiler — är den mest använda Instruments-mallen. Den fungerar baserat på sampling av anropsstacken: var 1-10 millisekund registrerar systemet anropsstacken för alla applikationens trådar. Efter att sessionen stoppats summerar Instruments samplen och visar vilka metoder och funktioner som tog mest tid. Resultatet presenteras som ett Call Tree — ett anropsträd sorterat efter Self Weight.

Den viktigaste metriken för Time Profiler — Self Weight (tiden som spenderas direkt i metoden, exklusive anrop till barnmetoder). Det är just Self Weight som visar vilka funktioner som verkligen belastar processorn. Weight (total tid med barnmetoder) kan vara vilseledande: en metod med hög Weight kan helt enkelt anropa en annan långsam metod, medan den själv är snabb.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler kommer att visa att cellForItemAt har Self Weight = 40%
    // inuti den tar decodeImage 35% — detta är en flaskhals

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

Vid analys av Time Profiler, var uppmärksam på metoder som körs i com.apple.main-thread. Om Self Weight på huvudtråden överstiger tröskelvärdet på 16 ms per bildruta — kommer UI att vara långsamt. Lösningen på sådana problem — flytta avkodning av bilder, layoutberäkningar och databehandling från huvudtråden till bakgrunden via Grand Central Dispatch (GCD).

Hur man läser Call Tree i Time Profiler

Call Tree — är en hierarkisk representation av alla metodanrop, sorterad efter Self Weight. Den tyngsta metoden i Call Tree — den första raden. Genom att expandera raden ser du vilka barnmetoder denna metod anropade och hur mycket tid de tog. Leta efter metoder där Self Weight (egen tid) avsevärt överstiger Weight (total tid) — detta är tecken på synkron blockering och väntan.

Allocations: realtidsövervakning av minne

Allocations — är ett verktyg för att övervaka alla minnesallokeringar i applikationen. Det visar vilka objekt, i vilken mängd och med vilken total storlek som skapas vid varje tillfälle. Till skillnad från Memory Profiler i Android Studio stöder Allocations Heapshot — en ögonblicksbild av levande objekt med möjlighet att jämföra två bilder.

Gränssnittet för Allocations består av två huvudsektioner: All Allocations (sammanfattande statistik per objekttyp) och Call Trees (anropsträd med uppdelning per metod som skapar objekt). För att söka efter läckor, använd Heapshot Analysis: ta en bild före utförandet av scenariot, utför scenariot, ta en bild efter — och jämför vilka nya objekt som finns kvar i minnet.

Enligt Apple Developer Documentation är det vanligaste läckmönstret som upptäcks via Allocations — överdriven skapande av UIView och CALayer vid rullning av samlingar. Om antalet levande UIView ökar vid varje rullning, medan samlingen återanvänder celler — skapas någonstans extra vyer utan att frigöra gamla. Allocations visar den exakta anropsstacken där dessa vyer skapas.

Heapshot Analysis: jämförelse av minnesbilder

Heapshot — är en ögonblicksbild av levande objekt i Allocations. Ta en Heapshot före utförandet av scenariot, utför scenariot och ta en andra Heapshot. Skillnaden mellan bilderna visar vilka objekt som skapades och inte frigjordes. Det ideala resultatet — tillväxt endast av temporära objekt (Autorelease pool). För noggrann analys, använd kombinationen Allocations + Leaks i en session. Allocations visar vilka objekt som inte frigörs, och Leaks — varför (vilken stark referens som håller dem). Kör en dubbel session vid varje misstanke om läcka.

Leaks: automatisk sökning efter minnesläckor

Leaks — är ett specialiserat verktyg för att upptäcka minnesläckor i iOS- och macOS-applikationer. Till skillnad från Allocations, som bara visar allokeringar, skannar Leaks aktivt heapen för att hitta retain cycles — situationer där två eller flera objekt ömsesidigt håller varandra med starka referenser.

Leaks arbetar tillsammans med Cycles & Roots — en visualiserare av objektretentionsgrafen. När en läcka upptäcks visar Leaks alla objekt i cykeln, deras retain count och de exakta fälten genom vilka referenser överförs. Utvecklaren behöver bara titta på grafen och förstå vilken referens som måste ersättas med weak.

Verktyget markerar automatiskt läckor med en röd markör på tidslinjen. Leaks arbetar i realtid: så snart systemet upptäcker en läcka signalerar det omedelbart till utvecklaren. Detta gör det möjligt att åtgärda problem på plats, utan att vänta på dump och efteranalys.

Enligt WWDC 2022 kan Leaks upptäcka även komplexa flernivåiga retain cycles — till exempel när tre eller flera objekt bildar en sluten kedja av starka referenser. För diagnos av sådana cykler är Cycles & Roots-grafen oumbärlig: den visar visuellt hur objekt sluter sig kring varandra.

Hur man läser Cycles & Roots-grafen

Varje nod i grafen är ett objekt, varje pil — en stark referens. En cykel — en sluten kontur av pilar. Nodens färg visar status: röd — läckande objekt, grön — rot (GC Root), grå — mellanliggande objekt. För att åtgärda en läcka, hitta pilen som kan göras weak utan att bryta logiken — och ersätt referenstypen i koden.

Energy Log: analys av energiförbrukning

Energy Log — är en Instruments-mall för att mäta applikationens energiförbrukning. Den samlar in data från enhetens hårdvarusensorer: CPU-belastning, Wi-Fi- och mobilnätverksstatus, GPS-användning, display och Bluetooth. Energy Log visar vilka operationer i applikationen som orsakar störst batteriförbrukning och lägger dem på energiförbrukningsgrafen över tid.

Verktyget klassificerar operationer efter energiförbrukningsnivå: låg (normal processordrift), medel (Wi-Fi-överföring), hög (GPS, mobilt nätverk, GPU). Om Energy Log visar röda indikatorer på hög nivå under en längre tid — förbrukar applikationen batteriet i bakgrunden och kommer att tas bort av användaren.

Typiska problem som upptäcks av Energy Log: WakeLock utan tidsbegränsning (applikationen håller processorn aktiv efter att uppgiften slutförts), Location Updates med hög noggrannhet i bakgrunden (var några sekunder en koordinatförfrågan), anomalier i nätverkssessioner(frekvent återanslutning till servern). Energy Log rekommenderar att registrera varje sådan incident och lägga till ett villkor för att stänga av den energikrävande operationen.

För att testa energiförbrukning, använd en verklig enhet på batteridrift — på emulatorn är energiförbrukningsindikatorerna felaktiga. Kör Energy Log tillsammans med UI-tester för att automatisera batteriförbrukningskontrollen i CI.

Hur man startar och tolkar resultat från Instruments

Att starta Instruments från Xcode görs på två sätt: via menyn Product → Profile (⌘I) eller genom att öppna Instruments som en separat applikation i Launchpad. Det första sättet är bekvämare: Xcode bygger automatiskt applikationen i profileringsläge och startar den på den anslutna enheten med den valda mallen. Efter att sessionen stoppats sparar Instruments spårningen i en fil med tillägget .trace.

Tolkningen av resultaten beror på mallen. För Time Profiler, titta på Call Tree sorterat efter Self Weight — de översta metoderna är dina huvudsakliga flaskhalsar. För Allocations — på # Living efter ett cykliskt scenario: om antalet objekt har ökat, sök efter en läcka. För Leaks — på de röda markörerna och Cycles & Roots-grafen. Jämför resultat före och efter optimering — detta är det enda sättet att bekräfta effektiviteten av ändringar.

// Kommandorad för Instruments i CI
// Integration av Instruments i CI/CD-pipeline
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Mäter rullningstid för samling
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

I CI kan Instruments startas från kommandoraden via xcodebuild -showBuildSettings och xcrun xctrace. Detta gör det möjligt att automatisera profilering vid varje commit och undvika regression. För analys, använd Baseline-jämförelse: om metriken försämrats med 5% jämfört med föregående commit — bör pipelinen stoppas.

De vanligaste misstagen vid arbete med Instruments: profilering på simulator istället för enhet (CPU- och GPU-data är felaktiga), datainsamling utan scenario (resultaten är slumpmässiga), ignorering av Call Tree (att bara titta på grafen, inte på specifika metoder). Att åtgärda dessa misstag ger 80% av profileringskvaliteten.