Instruments — ce este, capabilitățile Time Profiler și Allocations

Ce este Instruments?

Instruments — este un sistem de profilare și urmărire, care face parte din Xcode și se bazează pe tehnologia DTrace, dezvoltată de Sun Microsystems. Instruments combină zeci de instrumente de profilare (șabloane) într-o singură interfață: este suficient să alegi un șablon, să rulezi aplicația prin Xcode și să începi colectarea datelor.

Arhitectura Instruments este construită pe modelul client-server: un agent pe dispozitiv colectează date și le transmite pe Mac prin conexiune USB. Acest lucru minimizează impactul profilerului asupra performanței aplicației — Instruments funcționează în principal pe partea gazdei. Conform WWDC 2022, overhead-ul Time Profiler la frecvența de eșantionare de 1 ms este mai mic de 3%.

Instruments suportă șabloane personalizate — dezvoltatorul poate combina mai multe instrumente într-o singură sesiune de profilare. De exemplu, să ruleze simultan Time Profiler + Allocations + Leaks și să vadă corelația între vârfurile CPU și alocările de memorie. Aceasta oferă o imagine de ansamblu a performanței, inaccesibilă în analiza izolată a fiecărei componente.

Ce șabloane sunt disponibile implicit

Xcode vine cu 16 șabloane preinstalate Instruments: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace și altele. Fiecare șablon este optimizat pentru o sarcină specifică și configurat în prealabil cu setările corecte ale declanșatorilor și filtrelor.

Time Profiler: analiza performanței CPU

Time Profiler — este cel mai utilizat șablon Instruments. Funcționează pe baza eșantionării stivei de apeluri: la fiecare 1-10 milisecunde, sistemul înregistrează stiva de apeluri a tuturor thread-urilor aplicației. După oprirea sesiunii, Instruments însumează eșantioanele și arată care metode și funcții au ocupat cel mai mult timp. Rezultatul este prezentat sub forma unui Call Tree — arbore de apeluri sortat după Self Weight.

Metrica cheie a Time Profiler — Self Weight (timpul petrecut direct în metodă, fără a include apelurile metodelor copil). Exact Self Weight arată care funcții încarcă cu adevărat procesorul. Weight (timpul total cu metodele copil) poate fi înșelător: o metodă cu Weight ridicat poate apela pur și simplu o altă metodă lentă, ea însăși fiind rapidă.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler va arăta că cellForItemAt are Self Weight = 40%
    // în interiorul său decodeImage ocupă 35% — acesta este un blocaj

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

La analiza Time Profiler, acordă atenție metodelor care se execută în com.apple.main-thread. Dacă pe thread-ul principal Self Weight depășește pragul de 16 ms per cadru — UI va fi lent. Soluția acestor probleme — transferarea decodării imaginilor, calculelor de layout și procesării datelor din thread-ul principal în fundal prin Grand Central Dispatch (GCD).

Cum să citești Call Tree în Time Profiler

Call Tree — este o reprezentare ierarhică a tuturor apelurilor de metode, sortată după Self Weight. Cea mai grea metodă din Call Tree — primul rând. Deschizând rândul, vezi ce metode copil a apelat această metodă și cât timp au ocupat. Caută metode unde Self Weight (timpul propriu) depășește semnificativ Weight (timpul total) — acestea sunt semne de blocări sincrone și așteptare.

Allocations: urmărirea memoriei în timp real

Allocations — este un instrument pentru monitorizarea tuturor alocărilor de memorie ale aplicației. Arată ce obiecte, în ce cantitate și cu ce dimensiune totală sunt create în fiecare moment. Spre deosebire de Memory Profiler din Android Studio, Allocations suportă Heapshot — o imagine instantanee a obiectelor vii cu posibilitatea de a compara două imagini.

Interfața Allocations este formată din două secțiuni principale: All Allocations (statistici sumare pe toate tipurile de obiecte) și Call Trees (arbore de apeluri cu defalcare pe metodele care creează obiecte). Pentru căutarea scurgerilor, folosește Heapshot Analysis: fă o imagine înainte de executarea scenariului, execută scenariul, fă o imagine după — și compară ce obiecte noi au rămas în memorie.

Conform Apple Developer Documentation, cel mai frecvent model de scurgere detectabil prin Allocations — crearea excesivă de UIView și CALayer la derularea colecțiilor. Dacă la fiecare derulare numărul de UIView-uri vii crește, iar colecția reutilizează celule — undeva se creează view-uri suplimentare fără eliberarea celor vechi. Allocations arată stiva exactă de apeluri unde aceste view-uri sunt create.

Heapshot Analysis: compararea imaginilor de memorie

Heapshot — este o imagine instantanee a obiectelor vii în Allocations. Fă Heapshot înainte de executarea scenariului, execută scenariul și fă al doilea Heapshot. Diferența dintre imagini va arăta ce obiecte au fost create și nu au fost eliberate. Rezultatul ideal — creșterea doar a obiectelor temporare (Autorelease pool). Pentru o analiză precisă, folosește combinația Allocations + Leaks într-o singură sesiune. Allocations arată ce obiecte nu sunt eliberate, iar Leaks — de ce (ce referință puternică le menține). Rulează sesiunea dublă la fiecare suspiciune de scurgere.

Leaks: căutarea automată a scurgerilor de memorie

Leaks — este un instrument specializat pentru detectarea scurgerilor de memorie în aplicațiile iOS și macOS. Spre deosebire de Allocations, care doar arată alocările, Leaks scanează activ heap-ul în căutarea retain cycles — situații în care două sau mai multe obiecte se mențin reciproc prin referințe puternice.

Leaks funcționează împreună cu Cycles & Roots — un vizualizator al grafului de menținere a obiectelor. Când o scurgere este detectată, Leaks arată toate obiectele din ciclu, retain count-ul lor și câmpurile exacte prin care referințele sunt transmise. Dezvoltatorul trebuie doar să se uite la graf și să înțeleagă ce referință trebuie înlocuită cu weak.

Instrumentul evidențiază automat scurgerile cu un marker roșu pe axa temporală. Leaks funcționează în timp real: imediat ce sistemul detectează o scurgere, semnalizează imediat dezvoltatorului. Acest lucru permite remedierea problemelor pe loc, fără a aștepta dump-ul și analiza post-factum.

Conform WWDC 2022, Leaks este capabil să detecteze chiar și retain cycles complexe pe mai multe niveluri — de exemplu, când trei sau mai multe obiecte formează un lanț închis de referințe puternice. Pentru diagnosticarea unor astfel de cicluri, graful Cycles & Roots este de neînlocuit: arată vizual cum obiectele se închid unul asupra altuia.

Cum să citești graful Cycles & Roots

Fiecare nod al grafului este un obiect, fiecare săgeată — o referință puternică. Un ciclu — un contur închis de săgeți. Culoarea nodului arată statusul: roșu — obiect scurs, verde — rădăcină (GC Root), gri — obiect intermediar. Pentru a remedia scurgerea, găsește săgeata care poate fi făcută weak fără a încălca logica — și înlocuiește tipul referinței în cod.

Energy Log: analiza consumului de energie

Energy Log — este un șablon Instruments pentru măsurarea consumului de energie al aplicației. Colectează date de la senzorii hardware ai dispozitivului: încărcarea CPU, starea Wi-Fi și rețelei celulare, utilizarea GPS, afișajul și Bluetooth. Energy Log arată ce operații din aplicație cauzează cel mai mare consum de baterie și le suprapune pe graficul consumului de energie pe scara temporală.

Instrumentul clasifică operațiile după nivelul de consum energetic: scăzut (funcționarea normală a procesorului), mediu (transmisia Wi-Fi), ridicat (GPS, rețeaua mobilă, GPU). Dacă Energy Log arată indicatori roșii de nivel ridicat pe o perioadă îndelungată — aplicația descarcă bateria în fundal și va fi ștearsă de utilizator.

Probleme tipice detectate de Energy Log: WakeLock fără limită de timp (aplicația menține procesorul activ după finalizarea sarcinii), Location Updates cu precizie ridicată în fundal (la fiecare câteva secunde cerere de coordonate), anomalii ale sesiunilor de rețea (reconectări frecvente la server). Energy Log recomandă înregistrarea fiecărui astfel de incident și adăugarea unei condiții pentru dezactivarea operației consumatoare de energie.

Pentru testarea consumului de energie, folosește un dispozitiv real pe alimentare cu baterie — pe emulator, indicatorii de consum energetic sunt incorecți. Rulează Energy Log împreună cu testele UI pentru automatizarea verificării consumului de baterie în CI.

Cum să rulezi și să interpretezi rezultatele Instruments

Lansarea Instruments se face din Xcode în două moduri: prin meniul Product → Profile (⌘I) sau prin deschiderea Instruments ca aplicație separată în Launchpad. Primul mod este mai convenabil: Xcode compilează automat aplicația în modul de profilare și o lansează pe dispozitivul conectat cu șablonul selectat. După oprirea sesiunii, Instruments salvează trasarea într-un fișier cu extensia .trace.

Interpretarea rezultatelor depinde de șablon. Pentru Time Profiler, uită-te la Call Tree sortat după Self Weight — metodele cele mai sus sunt blocajele tale principale. Pentru Allocations — la # Living după un scenariu ciclic: dacă numărul de obiecte a crescut, caută o scurgere. Pentru Leaks — la markerii roșii și graful Cycles & Roots. Compară rezultatele înainte și după optimizare — acesta este singurul mod de a confirma eficiența modificărilor.

// Linia de comandă pentru Instruments în CI
// Integrarea Instruments în pipeline-ul CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Măsurăm timpul de derulare a colecției
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

În CI, Instruments poate fi rulat din linia de comandă prin xcodebuild -showBuildSettings și xcrun xctrace. Acest lucru permite automatizarea profilării la fiecare commit și evitarea regresiei. Pentru analiză, folosește compararea cu Baseline: dacă metrica s-a înrăutățit cu 5% față de commit-ul anterior, pipeline-ul ar trebui să se oprească.

Principalele greșeli la lucrul cu Instruments: profilarea pe simulator în loc de dispozitiv (datele CPU și GPU sunt incorecte), colectarea datelor fără scenariu (rezultatele sunt aleatorii), ignorarea Call Tree (uitarea doar la grafic, nu la metodele specifice). Remedierea acestor greșeli asigură 80% din calitatea profilării.