Instruments — шта је то, могућности Time Profiler и Allocations

Шта је Instruments?

Instruments — је систем профилирања и праћења, који је део Xcode-а и заснован на DTrace технологији коју је развио Sun Microsystems. Instruments обједињује десетине алата за профилирање (шаблона) у јединственом интерфејсу: довољно је изабрати шаблон, покренути апликацију кроз Xcode и почети прикупљање података.

Архитектура Instruments-а је изграђена на моделу клијент-сервер: агент на уређају прикупља податке и шаље их на Mac преко USB везе. Ово минимизира утицај профајлера на перформансе апликације — Instruments ради углавном на страни хоста. Према WWDC 2022, оверхеад Time Profiler-а при фреквенцији узорковања од 1 ms је мањи од 3%.

Instruments подржава прилагођене шаблоне — програмер може комбиновати више алата у једној сесији профилирања. На пример, истовремено покренути Time Profiler + Allocations + Leaks и видети корелацију између CPU пикова и алокација меморије. Ово даје целовиту слику перформанси, недоступну при изолованој анализи сваке компоненте.

Који шаблони су доступни подразумевано

Xcode долази са 16 пред-инсталираних Instruments шаблона: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace и други. Сваки шаблон је оптимизован за одређени задатак и унапред конфигурисан са правим подешавањима окидача и филтера.

Time Profiler: анализа перформанси CPU

Time Profiler — је најчешће коришћени Instruments шаблон. Ради на основу узорковања стека позива: сваких 1-10 милисекунди систем бележи стек позива свих нити апликације. Након заустављања сесије, Instruments сумира узорке и показује које методе и функције су заузеле највише времена. Резултат се приказује у облику Call Tree — стабла позива сортираног по Self Weight.

Кључна метрика Time Profiler-а — Self Weight (време проведено директно у методи, без укључивања позива подређених метода). Управо Self Weight показује које функције стварно оптерећују процесор. Weight (укупно време са подређеним методама) може бити вараљив: метода са високим Weight може једноставно позивати другу спору методу, а сама бити брза.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler ће показати да cellForItemAt има Self Weight = 40%
    // унутар њега decodeImage заузима 35% — то је уско грло

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

При анализи Time Profiler-а обратите пажњу на методе које се извршавају у com.apple.main-thread. Ако на главној нити Self Weight прелази праг од 16 ms по кадру — UI ће успоравати. Решење ових проблема — преношење декодирања слика, прорачуна layout-а и обраде података са главне нити у позадину путем Grand Central Dispatch (GCD).

Како читати Call Tree у Time Profiler-у

Call Tree — је хијерархијски приказ свих позива метода, сортиран по Self Weight. Најтежа метода у Call Tree-у — први ред. Отварањем реда видите које подређене методе је ова метода позивала и колико времена су заузеле. Тражите методе где Self Weight (сопствено време) значајно премашује Weight (укупно време) — то су знаци синхроних блокирања и чекања.

Allocations: праћење меморије у реалном времену

Allocations — је алат за праћење свих алокација меморије апликације. Показује који објекти, у којој количини и са којом укупном величином се стварају у сваком тренутку. За разлику од Memory Profiler-а у Android Studio, Allocations подржава Heapshot — тренутни снимак живих објеката са могућношћу поређења два снимка.

Интерфејс Allocations се састоји из две главне секције: All Allocations (збирна статистика по свим типовима објеката) и Call Trees (стабло позива са разлагањем по методама које стварају објекте). За тражење цурења користите Heapshot Analysis: направите снимак пре извршења сценарија, извршите сценарио, направите снимак после — и упоредите који нови објекти су остали у меморији.

Према Apple Developer Documentation, најчешћи образац цурења који се открива кроз Allocations — прекомерно стварање UIView и CALayer при скроловању колекција. Ако при сваком скроловању број живих UIView расте, а колекција поново користи ћелије — негде се стварају додатни view-ови без ослобађања старих. Allocations показује тачан стек позива где се ови view-ови стварају.

Heapshot Analysis: поређење снимака меморије

Heapshot — је тренутни снимак живих објеката у Allocations-у. Направите Heapshot пре извршења сценарија, извршите сценарио и направите други Heapshot. Разлика између снимака ће показати који објекти су створени и нису ослобођени. Идеалан резултат — раст само привремених објеката (Autorelease pool). За прецизну анализу користите комбинацију Allocations + Leaks у једној сесији. Allocations показује који објекти се не ослобађају, а Leaks — зашто (која јака референца их држи). Покрените двоструку сесију при свакој сумњи на цурење.

Leaks: аутоматско тражење цурења меморије

Leaks — је специјализовани алат за откривање цурења меморије у апликацијама на iOS и macOS. За разлику од Allocations, који само показује алокације, Leaks активно скенира хеап у потрази за retain cycles — ситуацијама када два или више објеката међусобно држе један другог јаким референцама.

Leaks ради у вези са Cycles & Roots — визуализатором графа задржавања објеката. Када се цурење открије, Leaks показује све објекте у циклусу, њихов retain count и тачна поља кроз која се референце преносе. Програмеру је довољно да погледа граф и разуме коју референцу треба заменити на weak.

Алат аутоматски истиче цурења црвеним маркером на временској линији. Leaks ради у реалном времену: чим систем открије цурење, одмах сигнализира програмеру. Ово омогућава исправљање проблема на лицу места, без чекања на дамп и пост-анализу.

Према WWDC 2022, Leaks је способан да открије чак и сложене вишеслојне retain cycles — на пример, када три или више објеката формирају затворени ланац јаких референци. За дијагностику таквих циклуса, граф Cycles & Roots је незаменљив: визуелно показује како се објекти затварају један на други.

Како читати граф Cycles & Roots

Сваки чвор графа је објекат, свака стрелица — јака референца. Циклус — затворени контур стрелица. Боја чвора показује статус: црвена — објекат који цури, зелена — корен (GC Root), сива — посредни објекат. Да бисте поправили цурење, пронађите стрелицу која се може учинити weak без нарушавања логике — и замените тип референце у коду.

Energy Log: анализа потрошње енергије

Energy Log — је Instruments шаблон за мерење потрошње енергије апликације. Прикупља податке са хардверских сензора уређаја: оптерећење CPU, стање Wi-Fi и мобилне мреже, коришћење GPS, дисплеј и Bluetooth. Energy Log показује које операције у апликацији изазивају највећу потрошњу батерије и наноси их на графикон потрошње енергије по временској скали.

Алат класификује операције по нивоу потрошње енергије: низак (нормалан рад процесора), средњи (Wi-Fi пренос), висок (GPS, мобилна мрежа, GPU). Ако Energy Log показује црвене индикаторе високог нивоа током дужег времена — апликација празни батерију у позадини и биће уклоњена од стране корисника.

Типични проблеми које Energy Log открива: WakeLock без временског ограничења (апликација држи процесор активним након завршетка задатка), Location Updates са високом прецизношћу у позадини (сваких неколико секунди захтев за координатама), аномалије мрежних сесија (честа поновна повезивања са сервером). Energy Log препоручује бележење сваког таквог инцидента и додавање услова за искључивање енергетски интензивне операције.

За тестирање потрошње енергије користите прави уређај на батеријском напајању — на емулатору су показатељи потрошње енергије нетачни. Покрените Energy Log заједно са UI тестовима за аутоматизацију провере потрошње батерије у CI.

Како покренути и интерпретирати резултате Instruments

Покретање Instruments-а се врши из Xcode-а на два начина: преко менија Product → Profile (⌘I) или отварањем Instruments-а као засебне апликације у Launchpad-у. Први начин је погоднији: Xcode аутоматски компајлира апликацију у режиму профилирања и покреће је на повезаном уређају са изабраним шаблоном. Након заустављања сесије, Instruments чува трасирање у датотеци са екстензијом .trace.

Интерпретација резултата зависи од шаблона. За Time Profiler гледајте Call Tree сортиран по Self Weight — највише методе су ваша главна уска грла. За Allocations — на # Living након цикличног сценарија: ако је број објеката порастао — тражите цурење. За Leaks — на црвене маркере и граф Cycles & Roots. Упоређујте резултате пре и после оптимизације — ово је једини начин да потврдите ефикасност промена.

// Командна линија за Instruments у CI
// Интеграција Instruments у CI/CD пајплајн
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Меримо време скроловања колекције
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

У CI-у се Instruments може покренути из командне линије преко xcodebuild -showBuildSettings и xcrun xctrace. Ово омогућава аутоматизацију профилирања при сваком комиту и спречавање регресије. За анализу користите Baseline поређење: ако се метрика погоршала за 5% у односу на претходни комит — пајплајн треба да се заустави.

Главне грешке при раду са Instruments-ом: профилирање на симулатору уместо на уређају (CPU и GPU подаци су нетачни), прикупљање података без сценарија (резултати су насумични), игнорисање Call Tree-а (гледање само на графикон, а не на конкретне методе). Исправљање ових грешака даје 80% квалитета профилирања.