Instruments — cos'è, funzionalità di Time Profiler e Allocations

Cos'è Instruments?

Instruments — è un sistema di profilazione e tracciamento che fa parte di Xcode e si basa sulla tecnologia DTrace sviluppata da Sun Microsystems. Instruments combina decine di strumenti di profilazione (modelli) in un'interfaccia unificata: basta selezionare un modello, avviare l'applicazione tramite Xcode e iniziare la raccolta dati.

L'architettura di Instruments si basa su un modello client-server: un agente sul dispositivo raccoglie i dati e li trasmette al Mac tramite connessione USB. Questo minimizza l'impatto del profiler sulle prestazioni dell'applicazione — Instruments opera principalmente sul lato host. Secondo la WWDC 2022, l'overhead del Time Profiler con una frequenza di campionamento di 1 ms è inferiore al 3%.

Instruments supporta modelli personalizzati — lo sviluppatore può combinare più strumenti in una singola sessione di profilazione. Ad esempio, avviare contemporaneamente Time Profiler + Allocations + Leaks e vedere la correlazione tra picchi di CPU e allocazioni di memoria. Questo fornisce un quadro olistico delle prestazioni, non disponibile con l'analisi isolata di ogni componente.

Quali modelli sono disponibili di default

Xcode viene fornito con 16 modelli Instruments preinstallati: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace e altri. Ogni modello è ottimizzato per un compito specifico e preconfigurato con le corrette impostazioni di trigger e filtri.

Time Profiler: analisi delle prestazioni della CPU

Time Profiler — è il modello più utilizzato di Instruments. Funziona basandosi sul campionamento dello stack di chiamate: ogni 1-10 millisecondi, il sistema registra lo stack di chiamate di tutti i thread dell'applicazione. Dopo l'arresto della sessione, Instruments somma i campioni e mostra quali metodi e funzioni hanno impiegato più tempo. Il risultato viene presentato come Call Tree — albero delle chiamate ordinato per Self Weight.

La metrica chiave del Time Profiler è Self Weight (tempo speso direttamente nel metodo, escluse le chiamate ai metodi figli). È il Self Weight che mostra quali funzioni stanno effettivamente caricando il processore. Il Weight (tempo totale con i metodi figli) può essere fuorviante: un metodo con Weight elevato potrebbe semplicemente chiamare un altro metodo lento, mentre esso stesso è veloce.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler mostrerà che cellForItemAt ha Self Weight = 40%
    // al suo interno decodeImage occupa il 35% — questo è il collo di bottiglia

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

Nell'analisi del Time Profiler, prestate attenzione ai metodi eseguiti in com.apple.main-thread. Se il Self Weight sul thread principale supera la soglia di 16 ms per fotogramma — l'UI rallenterà. La soluzione a questi problemi è spostare la decodifica delle immagini, i calcoli di layout e l'elaborazione dei dati dal thread principale a un thread in background tramite Grand Central Dispatch (GCD).

Come leggere il Call Tree in Time Profiler

Call Tree — è una rappresentazione gerarchica di tutte le chiamate ai metodi, ordinata per Self Weight. Il metodo più pesante nel Call Tree è la prima riga. Espandendo la riga, si vedono quali metodi figli questo metodo ha chiamato e quanto tempo hanno impiegato. Cercate metodi in cui il Self Weight (tempo proprio) supera significativamente il Weight (tempo totale) — questi sono segni di blocchi sincroni e attesa.

Allocations: tracciamento della memoria in tempo reale

Allocations — è uno strumento per monitorare tutte le allocazioni di memoria dell'applicazione. Mostra quali oggetti, in che quantità e con quale dimensione totale vengono creati in ogni momento. A differenza del Memory Profiler di Android Studio, Allocations supporta Heapshot — un'istantanea degli oggetti vivi con possibilità di confrontare due istantanee.

L'interfaccia di Allocations è composta da due sezioni principali: All Allocations (statistiche totali per tipo di oggetto) e Call Trees (albero delle chiamate con ripartizione per metodi che creano oggetti). Per trovare perdite, utilizzate Heapshot Analysis: scattate un'istantanea prima di eseguire uno scenario, eseguite lo scenario, scattate un'istantanea dopo — e confrontate quali nuovi oggetti sono rimasti in memoria.

Secondo la Apple Developer Documentation, il modello di perdita più comune rilevato da Allocations è la creazione eccessiva di UIView e CALayer durante lo scorrimento delle raccolte. Se ad ogni scorrimento il numero di UIView vive aumenta, ma la raccolta riutilizza le celle — da qualche parte vengono create viste aggiuntive senza liberare quelle vecchie. Allocations mostra lo stack di chiamate esatto dove queste viste vengono create.

Heapshot Analysis: confronto di istantanee di memoria

Heapshot — è un'istantanea degli oggetti vivi in Allocations. Scattate un Heapshot prima di eseguire lo scenario, eseguite lo scenario e scattate un secondo Heapshot. La differenza tra le istantanee mostrerà quali oggetti sono stati creati e non liberati. Il risultato ideale — aumento solo degli oggetti temporanei (Autorelease pool). Per un'analisi precisa, utilizzate la combinazione Allocations + Leaks in una singola sessione. Allocations mostra quali oggetti non vengono liberati, e Leaks — perché (quale riferimento forte li trattiene). Avviate una sessione doppia ogni volta che sospettate una perdita.

Leaks: ricerca automatica di perdite di memoria

Leaks — è uno strumento specializzato per il rilevamento di perdite di memoria in applicazioni iOS e macOS. A differenza di Allocations, che mostra solo le allocazioni, Leaks scansiona attivamente l'heap alla ricerca di retain cycle — situazioni in cui due o più oggetti si trattengono reciprocamente con riferimenti forti.

Leaks lavora insieme a Cycles & Roots — un visualizzatore del grafo di ritenzione degli oggetti. Quando viene rilevata una perdita, Leaks mostra tutti gli oggetti nel ciclo, i loro retain count e i campi esatti attraverso cui i riferimenti vengono passati. Lo sviluppatore deve solo guardare il grafo e capire quale riferimento deve essere sostituito con weak.

Lo strumento evidenzia automaticamente le perdite con un marcatore rosso sulla timeline. Leaks funziona in tempo reale: non appena il sistema rileva una perdita, segnala immediatamente lo sviluppatore. Questo consente di correggere i problemi “sul posto”, senza attendere dump e post-analisi.

Secondo la WWDC 2022, Leaks è in grado di rilevare anche retain cycle complessi a più livelli — ad esempio, quando tre o più oggetti formano una catena chiusa di riferimenti forti. Per diagnosticare tali cicli, il grafo Cycles & Roots è indispensabile: mostra visivamente come gli oggetti si chiudono l'uno sull'altro.

Come leggere il grafo Cycles & Roots

Ogni nodo del grafo è un oggetto, ogni freccia è un riferimento forte. Un ciclo è un circuito chiuso di frecce. Il colore del nodo mostra lo stato: rosso — oggetto perso, verde — radice (GC Root), grigio — oggetto intermedio. Per correggere la perdita, trovate una freccia che può essere resa weak senza violare la logica — e cambiate il tipo di riferimento nel codice.

Energy Log: analisi del consumo energetico

Energy Log — è un modello Instruments per misurare il consumo energetico dell'applicazione. Raccoglie dati dai sensori hardware del dispositivo: carico della CPU, stato del Wi-Fi e della radio cellulare, utilizzo GPS, display e Bluetooth. Energy Log mostra quali operazioni nell'applicazione causano il maggiore consumo di batteria e le sovrappone a un grafico del consumo energetico nel tempo.

Lo strumento classifica le operazioni per livello di consumo energetico: basso (funzionamento normale del processore), medio (trasmissione Wi-Fi), alto (GPS, rete mobile, GPU). Se Energy Log mostra indicatori rossi di livello alto per un periodo prolungato — l'applicazione sta scaricando la batteria in background e verrà rimossa dall'utente.

Problemi tipici identificati da Energy Log: WakeLock senza limite di tempo (l'applicazione mantiene il processore attivo dopo aver completato un'attività), Location Updates con alta precisione in background (richiesta di coordinate ogni pochi secondi), anomalie nelle sessioni di rete (riconnessioni frequenti al server). Energy Log raccomanda di registrare ogni incidente di questo tipo e aggiungere una condizione per disattivare l'operazione energivora.

Per testare il consumo energetico, utilizzate un dispositivo reale alimentato a batteria — sull'emulatore, gli indicatori di consumo energetico non sono corretti. Eseguite Energy Log insieme ai test UI per automatizzare la verifica del consumo di batteria nel CI.

Come avviare e interpretare i risultati di Instruments

L'avvio di Instruments si effettua da Xcode in due modi: tramite il menu Product → Profile (⌘I) o aprendo Instruments come applicazione separata in Launchpad. Il primo metodo è più comodo: Xcode compila automaticamente l'applicazione in modalità profilazione e la esegue sul dispositivo connesso con il modello selezionato. Dopo l'arresto della sessione, Instruments salva la traccia in un file con estensione .trace.

L'interpretazione dei risultati dipende dal modello. Per Time Profiler, guardate il Call Tree ordinato per Self Weight — i metodi in cima sono i vostri principali colli di bottiglia. Per Allocations — guardate # Living dopo uno scenario ciclico: se il numero di oggetti è aumentato, cercate una perdita. Per Leaks — guardate i marcatori rossi e il grafo Cycles & Roots. Confrontate i risultati prima e dopo l'ottimizzazione — questo è l'unico modo per confermare l'efficacia delle modifiche.

// Riga di comando per Instruments nel CI
// Integrazione di Instruments nel pipeline CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Misurazione del tempo di scorrimento della raccolta
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

Nel CI, è possibile eseguire Instruments dalla riga di comando tramite xcodebuild -showBuildSettings e xcrun xctrace. Questo consente di automatizzare la profilazione ad ogni commit e non perdere regressioni. Per l'analisi, utilizzate un confronto con la baseline: se la metrica è peggiorata del 5% rispetto al commit precedente — la pipeline deve fermarsi.

Errori principali nell'uso di Instruments: profilazione sul simulatore invece del dispositivo (dati CPU e GPU non corretti), raccolta dati senza scenario (risultati casuali), ignorare il Call Tree (guardare solo il grafico, non i metodi specifici). Correggere questi errori dà l'80% della qualità di profilazione.