Performance Test у мобільній розробці: що це таке, метрики та як проводиться

Що таке Performance Test?

Performance Test — це тип нефункціонального тестування, який визначає, наскільки швидко та ефективно додаток виконує свої завдання. На відміну від юніт-тестів або UI-тестів, Performance Test вимірює кількісні характеристики: час відгуку, навантаження CPU, споживання RAM та використання батареї. За даними звіту Sauce Labs (2025), 68% команд мобільної розробки включають Performance Test у свій регулярний цикл тестування, а 41% автоматизують його в CI.

Основна мета Performance Test — переконатися, що додаток відповідає вимогам до продуктивності, зафіксованим в специфікації. Якщо час запуску екрану перевищує 500 мілісекунд або додаток споживає понад 200 МБ RAM на середньому пристрої, це сигнал до оптимізації. Базова лінія продуктивності встановлюється на етапі першого стабільного релізу та переглядається при кожному великому оновленні.

Performance Test проводиться на реальних пристроях, а не на симуляторах, оскільки емуляція не дає точної картини використання CPU, GPU та мережевих ресурсів. За даними Apple WWDC (2024), тести на симуляторі показують завищені результати порівняно з реальним пристроєм на 15–30%. Реальний пристрій залишається єдиним достовірним джерелом даних про продуктивність.

Регулярність виконання Performance Test залежить від циклу розробки. В рекомендаціях Google Android Performance (2024) зазначено, що базові виміри продуктивності повинні запускатися на кожному pull request, а повний набір — перед кожним релізом. Автоматизація цих вимірів дозволяє виявляти регресії продуктивності на ранніх етапах.

Ключові метрики продуктивності

У мобільній розробці виділяють п’ять основних метрик, які покривають 90% сценаріїв Performance Test. Час запуску (cold start та warm start) — перша метрика, яку перевіряють при кожному релізі. Google Play Console (2024) фіксує час запуску за порогом: холодний старт не повинен перевищувати 5 секунд, теплий — 1,5 секунди. Перевищення цих порогів безпосередньо впливає на рейтинг в магазині додатків.

Час запуску (Cold Start)

Холодний старт вимірюється від моменту натискання на іконку до появи першого кадру додатка. iOS використовує `dispatch_async` для відстроченої ініціалізації, що скорочує видимий час запуску. Android холодний старт включає створення процесу, ініціалізацію Application та запуск Activity. За даними Google Performance (2024), кожні 100 мс затримки холодного старту знижує Conversion Rate на 1,2% в e-commerce додатках.

Частота кадрів (FPS)

FPS (Frames Per Second) — частота кадрів під час анімацій та прокрутки списків. Для плавного інтерфейсу потрібні стабільні 60 FPS. Android Studio Profiler та Xcode GPU Report показують падіння FPS під час важких операцій — завантаження зображень, парсингу JSON або рендерингу складних макетів. Падіння нижче 30 FPS відчувається користувачем як гальмування та веде до зниження Retention Rate на 22% за даними Adjust (2025).

Споживання оперативної пам’яті

Споживання оперативної пам’яті — третя критична метрика. Витоки пам’яті (memory leaks) — основна причина погіршення продуктивності в довготривалих сесіях. Instruments Allocations та Android Memory Profiler допомагають виявити циклічні посилання в Swift та незвільнені Activity в Android. Розхід батареї — метрика, яку часто не враховують на етапі тестування. За даними Apple Developer (2024), додатки з високим енергоспоживанням обмежуються в фоновому режимі на iOS. Energy Log в Xcode фіксує профіль енергоспоживання додатка за сесію.

Види тестування продуктивності

Навантажувальне тестування (Load Test) перевіряє поведінку додатка під очікуваною кількістю одночасних користувачів. Для мобільного бекенду це означає симуляцію 1000–10000 одночасних запитів до API. Серверна частина має обробляти пікове навантаження без збільшення часу відгуку понад 20% від базового значення. За даними k6 benchmarks (2024), типова конфігурація Load Test включає рампу від 0 до 1000 VUs (віртуальних користувачів) за 5 хвилин.

Стрес-тестування (Stress Test) визначає точку відмови додатка — момент, коли система перестає відповідати на запити або деградує неприйнятно. На відміну від Load Test, Stress Test навантажує систему понад нормальні межі. Точка відмови фіксується за одним з критеріїв: час відгуку перевищує 10 секунд, відсоток помилок 5XX перевищує 5%, або споживання RAM досягає 90% від доступної пам’яті.

Об’ємне тестування (Volume Test) оцінює поведінку додатка при роботі з великими обсягами даних. У мобільному контексті це перевірка роботи з тисячами записів у локальній базі даних, десятками гігабайт кешу або мільйонами push-повідомлень. SQLite на Android та Core Data на iOS показують різну продуктивність при обсязі понад 100000 записів.

Інструменти для Performance Test

Xcode Instruments

Xcode Instruments — основний інструмент для профілювання iOS-додатків. Time Profiler показує, які методи споживають найбільше CPU, а Allocations відстежує виділення та звільнення пам’яті. Instruments підтримує запис протягом тривалих сесій (до 30 хвилин) та експорт трейсів для порівняння між збірками. Activity Monitor всередині Instruments показує загальне навантаження на систему в реальному часі.

Android Studio Profiler

Android Studio Profiler — вбудований профілювач для Android. Він об’єднує CPU, Memory, Network та Energy профілювачі в єдиний інтерфейс. Особливість Android Profiler — підтримка інтерактивних сесій: розробник може виконувати дії в додатку та бачити миттєву реакцію метрик. За даними Google I/O (2024), Profiler підтримує запис у форматі .perf, який можна порівнювати з базовою лінією в CI.

Charles Proxy

Charles Proxy та Proxyman — інструменти для аналізу мережевого трафіку. Вони показують час кожного HTTP-запиту, розмір відповіді та заголовки. Для Performance Test важливо фіксувати запити, які виконуються довше 500 мс — це кандидати на кешування або оптимізацію. Charles підтримує throttle-режим, симулюючи повільні мережі: 3G, Edge та LTE. Proxyman — легша альтернатива для macOS з нативною Swift-архітектурою.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

Performance Test в CI/CD конвієрі

Вбудовування Performance Test в CI/CD — стандарт індустрії для 2025–2026 років. Конвієр продуктивності включає три етапи: pre-commit (швидкі виміри на pull request), nightly (повний набір тестів) та pre-release (порівняння з базовою лінією на еталонних пристроях). Bitrise та GitHub Actions підтримують запуск Xcode Instruments CLI та Gradle Profiler.

GitHub Actions (2024) опублікував офіційний шаблон для iOS Performance Test з використанням `xcodebuild test-without-building`. Шаблон запускає тести на одній з машин GitHub та публікує звіт як артефакт. Базова лінія зберігається в JSON-файлі в репозиторії: при перевищенні порогу на 10% конвієр падає з помилкою. Такий підхід запобігає деградації продуктивності без ручного перегляду кожної збірки.

Проблема мобільного Performance Test в CI — нестабільність результатів на різних машинах. Apple Silicon (M1–M4) та Intel Xeon дають різний час виконання. Рішення — використовувати відсоткове співвідношення до базової лінії, а не абсолютні значення. Якщо тест виконується на 15% довше базової лінії, збірка позначається як така, що потребує перевірки.

Написання Performance Test на iOS та Android

XCTest Performance на iOS використовує метод `measure(metrics:)`, який запускає блок коду 10 разів та повертає статистику: середнє, медіану, стандартне відхилення. Для тестування продуктивності бази даних XCTest зручно використовувати XCTMemoryMetric, який фіксує пікове споживання RAM. Поріг задається через `XCTPerformanceReport` після завершення тесту.

Android Macrobenchmark — бібліотека від Google для вимірювання продуктивності на рівні додатка. Macrobenchmark запускає користувацькі сценарії (запуск Activity, прокрутка RecyclerView, відкриття WebView) та вимірює час виконання. Baseline Profile — це набір класів та методів, які компілятор Android попередньо оптимізує. Google Play використовує Baseline Profile для прискорення першого запуску на 30%.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

Обидва підходи — XCTest Performance і Android Macrobenchmark — використовують однакову концепцію: багаторазовий замір з усередненням та порівнянням з порогом. Продуктивність не може бути зведена до одного числа. Кожен реліз повинен супроводжуватися звітом про продуктивність, що містить тренди за останні 5 збірок. Такий звіт дозволяє команді бачити деградацію до того, як її помітять користувачі.