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 за кадър — потребителският интерфейс ще забавя. Решението на такива проблеми — прехвърляне на декодирането на изображения, изчисленията на оформлението и обработката на данни от главната нишка във фонов режим чрез 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 активно сканира heap-а в търсене на retain cycles — ситуации, при които два или повече обекта взаимно се задържат със силни референции.

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

Инструментът автоматично маркира изтичанията с червен маркер на времевата линия. Leaks работи в реално време: веднага щом системата открие изтичане, тя незабавно сигнализира на разработчика. Това позволява коригиране на проблемите на място, без да се чака dumр и последващ анализ.

Според 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 pipeline
import XCTest

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

В CI Instruments може да се стартира от командния ред чрез xcodebuild -showBuildSettings и xcrun xctrace. Това позволява автоматизиране на профилирането при всеки commit и предотвратяване на регресия. За анализ използвайте Baseline сравнение: ако показателят се е влошил с 5% спрямо предишния commit — pipeline трябва да спре.

Основните грешки при работа с Instruments: профилиране на симулатор вместо на устройство (данните за CPU и GPU са некоректни), събиране на данни без сценарий (резултатите са случайни), игнориране на Call Tree (гледане само на графиката, а не на конкретните методи). Коригирането на тези грешки дава 80% от качеството на профилирането.