Instruments — co to jest, możliwości Time Profiler i Allocations

Czym jest Instruments?

Instruments — to system profilowania i śledzenia, wchodzący w skład Xcode i oparty na technologii DTrace, opracowanej przez Sun Microsystems. Instruments łączy dziesiątki narzędzi profilujących (szablonów) w jednym interfejsie: wystarczy wybrać szablon, uruchomić aplikację przez Xcode i rozpocząć zbieranie danych.

Architektura Instruments oparta jest na modelu klient-serwer: agent na urządzeniu zbiera dane i przesyła je na Maca przez połączenie USB. Minimalizuje to wpływ profilera na wydajność aplikacji — Instruments działa głównie po stronie hosta. Według WWDC 2022, narzut Time Profiler przy częstotliwości próbkowania 1 ms wynosi mniej niż 3%.

Instruments obsługuje niestandardowe szablony — programista może łączyć kilka narzędzi w jednej sesji profilowania. Na przykład jednocześnie uruchomić Time Profiler + Allocations + Leaks i widzieć korelację między szczytami CPU a alokacjami pamięci. Daje to całościowy obraz wydajności, niedostępny przy izolowanej analizie każdego komponentu.

Jakie szablony są dostępne domyślnie

Xcode jest dostarczany z 16 preinstalowanymi szablonami Instruments: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace i inne. Każdy szablon jest zoptymalizowany do konkretnego zadania i wstępnie skonfigurowany z odpowiednimi ustawieniami wyzwalaczy i filtrów.

Time Profiler: analiza wydajności CPU

Time Profiler — to najczęściej używany szablon Instruments. Działa na podstawie próbkowania stosu wywołań: co 1–10 milisekund system zapisuje stos wywołań wszystkich wątków aplikacji. Po zatrzymaniu sesji Instruments sumuje próbki i pokazuje, które metody i funkcje zajęły najwięcej czasu. Wynik jest prezentowany w postaci Call Tree — drzewa wywołań z sortowaniem według Self Weight.

Kluczowa metryka Time Profiler — Self Weight (czas spędzony bezpośrednio w metodzie, bez uwzględniania wywołań metod potomnych). To właśnie Self Weight pokazuje, które funkcje rzeczywiście obciążają procesor. Weight (całkowity czas z metodami potomnymi) może być mylący: metoda z wysokim Weight może po prostu wywoływać inną wolną metodę, a sama być szybka.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler pokaże, że cellForItemAt ma Self Weight = 40%
    // wewnątrz niego decodeImage zajmuje 35% — to wąskie gardło

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

Podczas analizy Time Profiler zwracaj uwagę na metody wykonywane w com.apple.main-thread. Jeśli na głównym wątku Self Weight przekracza próg 16 ms na klatkę — UI będzie opóźnione. Rozwiązaniem takich problemów jest przeniesienie dekodowania obrazów, obliczeń layoutu i przetwarzania danych z głównego wątku do tła przez Grand Central Dispatch (GCD).

Jak czytać Call Tree w Time Profiler

Call Tree — to hierarchiczna reprezentacja wszystkich wywołań metod, posortowana według Self Weight. Najcięższa metoda w Call Tree to pierwszy wiersz. Rozwijając wiersz, widzisz, które metody potomne wywołała ta metoda i ile czasu zajęły. Szukaj metod, gdzie Self Weight (czas własny) znacznie przewyższa Weight (całkowity czas) — to oznaki synchronicznych blokad i oczekiwania.

Allocations: śledzenie pamięci w czasie rzeczywistym

Allocations — to narzędzie do monitorowania wszystkich alokacji pamięci aplikacji. Pokazuje, jakie obiekty, w jakiej ilości i z jakim całkowitym rozmiarem są tworzone w każdym momencie. W przeciwieństwie do Memory Profiler w Android Studio, Allocations obsługuje Heapshot — migawkę żywych obiektów z możliwością porównania dwóch migawek.

Interfejs Allocations składa się z dwóch głównych sekcji: All Allocations (sumaryczna statystyka według wszystkich typów obiektów) i Call Trees (drzewo wywołań z podziałem według metod, które tworzą obiekty). Do wyszukiwania wycieków używaj Heapshot Analysis: zrób migawkę przed wykonaniem scenariusza, wykonaj scenariusz, zrób migawkę po — i porównaj, które nowe obiekty pozostały w pamięci.

Według Apple Developer Documentation, najczęstszy wzorzec wycieku wykrywanego przez Allocations — nadmierne tworzenie UIView i CALayer podczas przewijania kolekcji. Jeśli przy każdym przewijaniu liczba żywych UIView rośnie, a kolekcja ponownie używa komórek — gdzieś tworzone są dodatkowe widoki bez zwalniania starych. Allocations pokazuje dokładny stos wywołań, gdzie te widoki są tworzone.

Heapshot Analysis: porównanie migawek pamięci

Heapshot — to migawka żywych obiektów w Allocations. Zrób Heapshot przed wykonaniem scenariusza, wykonaj scenariusz i zrób drugi Heapshot. Różnica między migawkami pokaże, które obiekty zostały utworzone i nie zwolnione. Idealny wynik — wzrost tylko tymczasowych obiektów (Autorelease pool). Do dokładnej analizy używaj kombinacji Allocations + Leaks w jednej sesji. Allocations pokazuje, które obiekty nie są zwalniane, a Leaks — dlaczego (która silna referencja je utrzymuje). Uruchamiaj podwójną sesję przy każdym podejrzeniu wycieku.

Leaks: automatyczne wyszukiwanie wycieków pamięci

Leaks — to wyspecjalizowane narzędzie do wykrywania wycieków pamięci w aplikacjach na iOS i macOS. W przeciwieństwie do Allocations, który po prostu pokazuje alokacje, Leaks aktywnie skanuje stertę w poszukiwaniu retain cycles — sytuacji, gdy dwa lub więcej obiektów wzajemnie utrzymuje się silnymi referencjami.

Leaks działa w połączeniu z Cycles & Roots — wizualizatorem grafu utrzymania obiektów. Gdy wyciek zostanie wykryty, Leaks pokazuje wszystkie obiekty w cyklu, ich retain count i dokładne pola, przez które referencje są przekazywane. Programista musi tylko spojrzeć na graf i zrozumieć, którą referencję należy zastąpić na weak.

Narzędzie automatycznie podświetla wycieki czerwonym znacznikiem na osi czasu. Leaks działa w czasie rzeczywistym: gdy tylko system wykryje wyciek, natychmiast sygnalizuje programiście. Pozwala to naprawiać problemy na bieżąco, bez czekania na zrzut i analizę post factum.

Według WWDC 2022, Leaks jest w stanie wykrywać nawet złożone wielopoziomowe retain cycles — na przykład, gdy trzy lub więcej obiektów tworzy zamknięty łańcuch silnych referencji. Do diagnozy takich cykli graf Cycles & Roots jest niezastąpiony: wizualnie pokazuje, jak obiekty zamykają się na siebie.

Jak czytać graf Cycles & Roots

Każdy węzeł grafu to obiekt, każda strzałka to silna referencja. Cykl to zamknięty kontur strzałek. Kolor węzła pokazuje status: czerwony — wyciekły obiekt, zielony — korzeń (GC Root), szary — pośredni obiekt. Aby naprawić wyciek, znajdź strzałkę, którą można zrobić weak bez naruszania logiki — i zastąp typ referencji w kodzie.

Energy Log: analiza zużycia energii

Energy Log — to szablon Instruments do pomiaru zużycia energii przez aplikację. Zbiera dane z czujników sprzętowych urządzenia: obciążenie CPU, stan Wi-Fi i sieci komórkowej, użycie GPS, wyświetlacz i Bluetooth. Energy Log pokazuje, które operacje w aplikacji powodują największe zużycie baterii, i nakłada je na wykres zużycia energii w skali czasu.

Narzędzie klasyfikuje operacje według poziomu energochłonności: niski (normalna praca procesora), średni (transmisja Wi-Fi), wysoki (GPS, sieć komórkowa, GPU). Jeśli Energy Log pokazuje czerwone wskaźniki wysokiego poziomu przez dłuższy czas — aplikacja rozładowuje baterię w tle i zostanie usunięta przez użytkownika.

Typowe problemy wykrywane przez Energy Log: WakeLock bez ograniczenia czasu (aplikacja utrzymuje procesor aktywnym po zakończeniu zadania), Location Updates z wysoką dokładnością w tle (co kilka sekund zapytanie o współrzędne), anomalie sesji sieciowych (częste ponowne łączenie z serwerem). Energy Log zaleca rejestrowanie każdego takiego incydentu i dodawanie warunku do wyłączenia energochłonnej operacji.

Do testowania zużycia energii używaj rzeczywistego urządzenia na zasilaniu bateryjnym — na emulatorze wskaźniki zużycia energii są nieprawidłowe. Uruchamiaj Energy Log razem z testami UI w celu automatyzacji sprawdzania zużycia baterii w CI.

Jak uruchomić i interpretować wyniki Instruments

Uruchomienie Instruments odbywa się z Xcode na dwa sposoby: przez menu Product → Profile (⌘I) lub przez otwarcie Instruments jako osobnej aplikacji w Launchpad. Pierwszy sposób jest wygodniejszy: Xcode automatycznie kompiluje aplikację w trybie profilowania i uruchamia ją na podłączonym urządzeniu z wybranym szablonem. Po zatrzymaniu sesji Instruments zapisuje śledzenie w pliku z rozszerzeniem .trace.

Interpretacja wyników zależy od szablonu. Dla Time Profiler patrz na Call Tree posortowane według Self Weight — najwyższe metody to twoje główne wąskie gardła. Dla Allocations — na # Living po cyklicznym scenariuszu: jeśli liczba obiektów wzrosła — szukaj wycieku. Dla Leaks — na czerwone znaczniki i graf Cycles & Roots. Porównuj wyniki przed i po optymalizacji — to jedyny sposób, aby potwierdzić skuteczność zmian.

// Wiersz poleceń dla Instruments w CI
// Integracja Instruments w pipeline CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Mierzymy czas przewijania kolekcji
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

W CI można uruchamiać Instruments z wiersza poleceń przez xcodebuild -showBuildSettings i xcrun xctrace. Pozwala to zautomatyzować profilowanie przy każdym commit i nie przeoczyć regresji. Do analizy używaj porównania z Baseline: jeśli metryka pogorszyła się o 5% względem poprzedniego commita — pipeline powinien się zatrzymać.

Najczęstsze błędy podczas pracy z Instruments: profilowanie na symulatorze zamiast na urządzeniu (dane CPU i GPU są nieprawidłowe), zbieranie danych bez scenariusza (wyniki są przypadkowe), ignorowanie Call Tree (patrzenie tylko na wykres, a nie na konkretne metody). Naprawienie tych błędów daje 80% jakości profilowania.