Тест перформанси у мобилном развоју: шта је то, метрике и како се спроводи

Шта је тест перформанси?

Тест перформанси је врста нефункционалног тестирања која одређује колико брзо и ефикасно апликација обавља своје задатке. За разлику од јединичних тестова или UI тестова, Тест перформанси мери квантитативне карактеристике: време одговора, оптерећење процесора, потрошњу RAM меморије и потрошњу батерије. Према извештају Sauce Labs (2025), 68% тимова за мобилни развој укључује Тест перформанси у редовни циклус тестирања, а 41% га аутоматизује у CI.

Главни циљ Теста перформанси је да се осигура да апликација испуњава захтеве перформанси наведене у спецификацији. Ако време отварања екрана прелази 500 милисекунди или апликација троши више од 200 MB RAM меморије на просечном уређају, то је сигнал за оптимизацију. Основна линија перформанси се успоставља у фази прве стабилне верзије и ревидира се приликом сваког великог ажурирања.

Тест перформанси се спроводи на стварним уређајима, а не на симулаторима, јер емулација не даје тачну слику коришћења CPU, GPU и мрежних ресурса. Према Apple WWDC (2024), тестови на симулатору показују преувеличане резултате у поређењу са стварним уређајем за 15–30%. Стварни уређај остаје једини поуздани извор података о перформансама.

Редовност извођења Теста перформанси зависи од развојног циклуса. У препорукама Google Android Performance (2024) наведено је да основна мерења перформанси треба покретати на сваки pull request, а комплетан сет — пре сваког објављивања верзије. Аутоматизација ових мерења омогућава откривање регресија перформанси у раним фазама.

Кључне метрике перформанси

У мобилном развоју издваја се пет главних метрика које покривају 90% сценарија Теста перформанси. Време покретања (хладно покретање и топло покретање) — прва метрика која се проверава при свакој верзији. Google Play Console (2024) бележи време покретања према праговима: хладно покретање не сме да пређе 5 секунди, топло — 1.5 секунди. Прекорачење ових прагова директно утиче на рејтинг у продавници апликација.

Време покретања (Cold Start)

Хладно покретање се мери од тренутка клика на икону до појаве првог оквира апликације. iOS користи `dispatch_async` за одложену иницијализацију, што скраћује видљиво време покретања. Android хладно покретање укључује креирање процеса, иницијализацију Application и покретање Activity. Према Google Performance (2024), сваких 100 ms кашњења хладног покретања смањује стопу конверзије за 1.2% у e-commerce апликацијама.

Брзина кадрова (FPS)

FPS (Frames Per Second) — брзина кадрова током анимација и померања листи. За глатки интерфејс потребно је стабилних 60 FPS. Android Studio Profiler и Xcode GPU Report показују падове FPS при тешким операцијама — учитавању слика, парсирању JSON или рендеровању сложених распореда. Пад испод 30 FPS корисник осећа као „успоравање” и доводи до смањења стопе задржавања за 22% према Adjust (2025).

Потрошња RAM меморије

Потрошња RAM меморије — трећа критична метрика. Цурење меморије — главни узрок пада перформанси у дуготрајним сесијама. Instruments Allocations и Android Memory Profiler помажу у откривању цикличних референци у Swift и неослобођених Activity у Android-у. Потрошња батерије — метрика која се често занемарује у фази тестирања. Према Apple Developer (2024), апликације са високом потрошњом енергије се ограничавају у позадини на iOS-у. Energy Log у Xcode-у бележи профил снаге апликације током сесије.

Врсте тестирања перформанси

Тестирање оптерећења (Load Test) проверава понашање апликације под очекиваним бројем истовремених корисника. За мобилни бекенд ово значи симулацију 1000–10000 истовремених захтева ка API-ју. Серверски део мора да обради вршно оптерећење без повећања времена одговора за више од 20% од основне вредности. Према k6 бенчмарковима (2024), типична конфигурација Load Test-а укључује рампу од 0 до 1000 VU (виртуелних корисника) у 5 минута.

Тестирање стреса (Stress Test) одређује тачку отказивања апликације — тренутак када систем престаје да одговара на захтеве или деградира неприхватљиво. За разлику од Load Test-а, Stress Test оптерећује систем изнад нормалних граница. Тачка отказивања се бележи према једном од критеријума: време одговора прелази 10 секунди, проценат грешака 5XX прелази 5%, или потрошња RAM меморије достиже 90% расположиве.

Тестирање обима (Volume Test) процењује понашање апликације при раду са великим количинама података. У мобилном контексту ово је провера рада са хиљадама записа у локалној бази података, десетинама гигабајта кеша или милионима push обавештења. SQLite на Android-у и Core Data на iOS-у показују различите перформансе при обиму преко 100000 записа.

Алати за тест перформанси

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 формату, који се може упоређивати са baseline-ом у CI-ју.

Charles Proxy

Charles Proxy и Proxyman — алати за анализу мрежног саобраћаја. Они показују време сваког HTTP захтева, величину одговора и заглавља. За Тест перформанси важно је бележити захтеве који трају дуже од 500 ms — они су кандидати за кеширање или оптимизацију. 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()
        }
    }
}

Тест перформанси у CI/CD цевоводу

Уграђивање Теста перформанси у CI/CD је индустријски стандард за 2025–2026. годину. Цевовод перформанси укључује три фазе: pre-commit (брза мерења на pull request), nightly (комплетан сет тестова) и pre-release (поређење са baseline-ом на референтним уређајима). Bitrise и GitHub Actions подржавају покретање Xcode Instruments CLI и Gradle Profiler-а.

GitHub Actions (2024) је објавио званични шаблон за iOS Тест перформанси користећи `xcodebuild test-without-building`. Шаблон покреће тестове на једној од GitHub машина и објављује извештај у artifact-у. Baseline се чува у JSON фајлу у репозиторијуму: при прекорачењу прага за 10%, цевовод пада са грешком. Овај приступ спречава деградацију перформанси без ручног прегледа сваке верзије.

Проблем мобилног Теста перформанси у CI-ју је нестабилност резултата на различитим машинама. Apple Silicon (M1–M4) и Intel Xeon дају различита времена извршења. Решење је коришћење процентуалног односа према baseline-у, а не апсолутних вредности. Ако тест траје 15% дуже од baseline-а — верзија се означава као да захтева проверу.

Писање тестова перформанси на 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 верзија. Такав извештај омогућава тиму да види деградацију пре него што је примете корисници.