Instruments — mi ez, a Time Profiler és Allocations képességei

Mi az Instruments?

Instruments — egy profilozó és nyomkövető rendszer, amely az Xcode része és a Sun Microsystems által fejlesztett DTrace technológián alapul. Az Instruments több tucat profilozó eszközt (sablont) egyesít egyetlen interfészben: csak ki kell választani egy sablont, elindítani az alkalmazást az Xcode-on keresztül, és elkezdeni az adatgyűjtést.

Az Instruments architektúrája kliens-szerver modellre épül: egy ügynök az eszközön összegyűjti az adatokat, és USB-kapcsolaton keresztül továbbítja a Mac-re. Ez minimalizálja a profiler hatását az alkalmazás teljesítményére — az Instruments főként a gazdagép oldalán működik. A WWDC 2022 szerint a Time Profiler terhelése 1 ms mintavételezési frekvencián kevesebb, mint 3%.

Az Instruments támogatja az egyéni sablonokat — a fejlesztő több eszközt kombinálhat egyetlen profilozási munkamenetben. Például egyszerre futtathatja a Time Profiler + Allocations + Leaks eszközöket, és láthatja a CPU-csúcsok és a memóriaallokációk közötti korrelációt. Ez holisztikus teljesítményképet ad, amely az egyes komponensek elkülönített elemzésével nem érhető el.

Milyen sablonok érhetők el alapértelmezés szerint

Az Xcode 16 előre telepített Instruments sablonnal érkezik: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace és mások. Minden sablon egy adott feladatra van optimalizálva, és előre konfigurálva van a megfelelő trigger- és szűrőbeállításokkal.

Time Profiler: CPU-teljesítmény elemzése

Time Profiler — az Instruments leggyakrabban használt sablonja. A hívási verem mintavételezésén alapul: 1-10 ezredmásodpercenként a rendszer rögzíti az alkalmazás összes szálának hívási vermét. A munkamenet leállítása után az Instruments összegzi a mintákat, és megmutatja, mely metódusok és függvények vettek igénybe a legtöbb időt. Az eredmény Call Tree-ként — egy Self Weight szerint rendezett hívásfaként jelenik meg.

A Time Profiler kulcsmetrikája — Self Weight (a metódusban közvetlenül eltöltött idő, a gyermekmetódusok hívásai nélkül). Pontosan a Self Weight mutatja meg, mely függvények terhelik valójában a processzort. A Weight (teljes idő a gyermekmetódusokkal) félrevezető lehet: egy magas Weight-tel rendelkező metódus egyszerűen csak egy másik lassú metódust hívhat, miközben maga gyors.

import UIKit

class ImageGalleryViewController: UIViewController {
    // A Time Profiler megmutatja, hogy a cellForItemAt Self Weight = 40%
    // benne a decodeImage 35%-ot foglal — ez egy szűk keresztmetszet

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

A Time Profiler elemzésekor figyeljen a com.apple.main-thread-ben végrehajtott metódusokra. Ha a főszálon a Self Weight meghaladja a 16 ms-os küszöbértéket képkockánként — az UI lassulni fog. Az ilyen problémák megoldása — a képek dekódolásának, layout-számításoknak és adatfeldolgozásnak a főszálról háttérbe helyezése a Grand Central Dispatch (GCD) segítségével.

Hogyan olvassuk a Call Tree-t a Time Profiler-ben

Call Tree — az összes metódushívás hierarchikus ábrázolása, Self Weight szerint rendezve. A legnehezebb metódus a Call Tree-ben — az első sor. A sort kibontva láthatja, mely gyermekmetódusokat hívta ez a metódus, és mennyi időt vettek igénybe. Keresse azokat a metódusokat, ahol a Self Weight (saját idő) jelentősen meghaladja a Weight-t (teljes idő) — ezek a szinkron blokkolások és várakozás jelei.

Allocations: memória valós idejű nyomon követése

Allocations — egy eszköz az alkalmazás összes memóriaallokációjának figyelésére. Megmutatja, mely objektumok, milyen mennyiségben és milyen teljes méretben jönnek létre minden pillanatban. Az Android Studio Memory Profiler-jétől eltérően az Allocations támogatja a Heapshot-ot — az élő objektumok pillanatképét két pillanatkép összehasonlításának lehetőségével.

Az Allocations felülete két fő részből áll: All Allocations (összesített statisztika az összes objektumtípus szerint) és Call Trees (hívásfa az objektumokat létrehozó metódusok szerinti bontásban). A szivárgások kereséséhez használja a Heapshot Analysis-t: készítsen pillanatképet a forgatókönyv végrehajtása előtt, hajtsa végre a forgatókönyvet, készítsen pillanatképet utána — és hasonlítsa össze, mely új objektumok maradtak a memóriában.

A Apple Developer Documentation szerint az Allocations által észlelt leggyakoribb szivárgási minta — a UIView és CALayer túlzott létrehozása gyűjtemények görgetésekor. Ha minden görgetéskor az élő UIView-ek száma nő, miközben a gyűjtemény újrahasznosítja a cellákat — valahol további nézetek jönnek létre a régiek felszabadítása nélkül. Az Allocations megmutatja a pontos hívási vermet, ahol ezek a nézetek létrejönnek.

Heapshot Analysis: memória pillanatképek összehasonlítása

Heapshot — az élő objektumok pillanatképe az Allocations-ben. Készítsen Heapshot-ot a forgatókönyv végrehajtása előtt, hajtsa végre a forgatókönyvet, és készítsen második Heapshot-ot. A pillanatképek közötti különbség megmutatja, mely objektumok jöttek létre és nem szabadultak fel. Az ideális eredmény — csak az ideiglenes objektumok növekedése (Autorelease pool). A pontos elemzéshez használja az Allocations + Leaks kombinációt egy munkamenetben. Az Allocations megmutatja, mely objektumok nem szabadulnak fel, a Leaks pedig — miért (mely erős referencia tartja őket). Futtasson dupla munkamenetet minden szivárgás gyanúja esetén.

Leaks: memóriaszivárgások automatikus keresése

Leaks — egy specializált eszköz memóriaszivárgások észlelésére iOS és macOS alkalmazásokban. Az Allocations-szel ellentétben, amely csak az allokációkat mutatja, a Leaks aktívan vizsgálja a heap-et retain cycle-ek — olyan helyzetek után kutatva, amikor két vagy több objektum kölcsönösen erős referenciákkal tartja egymást.

A Leaks a Cycles & Roots — az objektumretenciós gráf vizualizálójával együttműködve működik. Amikor egy szivárgást észlel, a Leaks megmutatja a ciklusban lévő összes objektumot, azok retain count-ját és a pontos mezőket, amelyeken keresztül a referenciák továbbadódnak. A fejlesztőnek csak a gráfra kell néznie, és megértenie, melyik referenciát kell weak-re cserélnie.

Az eszköz automatikusan piros markerrel jelöli a szivárgásokat az idővonalon. A Leaks valós időben működik: amint a rendszer szivárgást észlel, azonnal jelzi a fejlesztőnek. Ez lehetővé teszi a problémák helyben történő javítását, anélkül, hogy dump-ra és utólagos elemzésre kellene várni.

A WWDC 2022 szerint a Leaks képes észlelni akár összetett többszintű retain cycle-eket is — például amikor három vagy több objektum zárt erős referencia láncot alkot. Az ilyen ciklusok diagnosztizálásához a Cycles & Roots gráf nélkülözhetetlen: vizuálisan mutatja, hogyan záródnak egymásra az objektumok.

Hogyan olvassuk a Cycles & Roots gráfot

A gráf minden csomópontja egy objektum, minden nyíl — egy erős referencia. A ciklus — a nyilak zárt kontúrja. A csomópont színe mutatja az állapotot: piros — szivárgó objektum, zöld — gyökér (GC Root), szürke — köztes objektum. A szivárgás javításához keresse meg a nyilat, amely weak-é tehető a logika megsértése nélkül — és cserélje ki a referencia típusát a kódban.

Energy Log: energiafogyasztás elemzése

Energy Log — egy Instruments sablon az alkalmazás energiafogyasztásának mérésére. Adatokat gyűjt az eszköz hardverszenzorairól: CPU-terhelés, Wi-Fi és mobilhálózat állapota, GPS-használat, kijelző és Bluetooth. Az Energy Log megmutatja, mely műveletek okozzák a legnagyobb akkumulátorfogyasztást az alkalmazásban, és ráhelyezi ezeket az energiafogyasztási grafikonra az időskálán.

Az eszköz a műveleteket energiafogyasztási szint szerint osztályozza: alacsony (processzor normál működése), közepes (Wi-Fi átvitel), magas (GPS, mobilhálózat, GPU). Ha az Energy Log hosszú időn keresztül magas szintű piros jelzőket mutat — az alkalmazás a háttérben meríti az akkumulátort, és a felhasználó eltávolítja.

Az Energy Log által észlelt tipikus problémák: WakeLock időkorlát nélkül (az alkalmazás a feladat befejezése után is aktívan tartja a processzort), Location Updates nagy pontossággal a háttérben (néhány másodpercenként koordináta-kérelem), hálózati munkamenetek anomáliái(gyakori újracsatlakozás a szerverhez). Az Energy Log azt javasolja, hogy minden ilyen incidenst rögzítsen, és adjon hozzá egy feltételt az energiaigényes művelet kikapcsolásához.

Az energiafogyasztás teszteléséhez használjon valódi eszközt akkumulátoros táplálással — az emulátoron az energiafogyasztási mutatók helytelenek. Futtassa az Energy Log-ot az UI-tesztekkel együtt az akkumulátorfogyasztás ellenőrzésének automatizálásához a CI-ban.

Az Instruments futtatása és eredmények értelmezése

Az Instruments indítása az Xcode-ból kétféleképpen történik: a Product → Profile (⌘I) menüponton keresztül, vagy az Instruments különálló alkalmazásként történő megnyitásával a Launchpad-ben. Az első mód kényelmesebb: az Xcode automatikusan profilozási módban építi fel az alkalmazást, és elindítja a csatlakoztatott eszközön a kiválasztott sablonnal. A munkamenet leállítása után az Instruments .trace kiterjesztésű fájlba menti a nyomkövetést.

Az eredmények értelmezése a sablontól függ. A Time Profiler esetében nézze a Self Weight szerint rendezett Call Tree-t — a legfelső metódusok a fő szűk keresztmetszetek. Az Allocations esetében — a # Living értéket egy ciklikus forgatókönyv után: ha az objektumok száma nőtt, keressen szivárgást. A Leaks esetében — a piros markereket és a Cycles & Roots gráfot. Hasonlítsa össze az eredményeket optimalizálás előtt és után — ez az egyetlen módja a változtatások hatékonyságának megerősítésére.

// Parancssor az Instruments számára CI-ben
// Az Instruments integrációja CI/CD pipeline-ba
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Gyűjtemény görgetési idejének mérése
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

A CI-ban az Instruments a parancssorból is futtatható a xcodebuild -showBuildSettings és xcrun xctrace segítségével. Ez lehetővé teszi a profilozás automatizálását minden commit-nél, és a regresszió elkerülését. Az elemzéshez használjon Baseline összehasonlítást: ha a metrika 5%-kal romlott az előző commithoz képest — a pipeline-nak le kell állnia.

A főbb hibák az Instruments használata során: profilozás szimulátoron eszköz helyett (a CPU és GPU adatok helytelenek), adatgyűjtés forgatókönyv nélkül (az eredmények véletlenszerűek), a Call Tree figyelmen kívül hagyása (csak a grafikon nézése, nem a konkrét metódusoké). Ezen hibák kijavítása a profilozás minőségének 80%-át adja.