Праћење перформанси — шта је то, метрике и прикупљање података

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

Праћење перформанси је пракса квантитативне процене понашања апликације кроз прикупљање метрика времена извршења, коришћења меморије, фреквенције кадрова и потрошње енергије. За разлику од извештавања о крашевима, које бележи само фаталне кварове, праћење перформанси прати постепену деградацију: апликација ради, али спорије него што би требало.

Према Google (2024), 53% корисника затвара апликацију ако се учитава дуже од 3 секунде. Свака додатна секунда кашњења смањује конверзију у просеку за 20% по категоријама. Ово чини праћење перформанси не само техничком праксом, већ пословном потребом за мобилне производе.

Модерно праћење перформанси покрива четири нивоа: клијентски део (iOS, Android), мрежа (API захтеви, WebSocket), backend услуге и инфраструктура. У мобилном развоју фокус је на клијентским метрикама, јер већина проблема са перформансама настаје управо на уређају корисника.

Кључне метрике мобилне апликације

За потпуно праћење потребно је пратити пет група метрика, од којих је свака одговорна за свој аспект корисничког искуства. FPS (frames per second) показује глаткоћу анимација и скроловања — вредност испод 30 кадрова у секунди осећа се као успорење.

Метрике времена

Време хладног покретања апликације — од тренутка додира на иконицу до потпуне спремности интерфејса. Време топлог покретања — повратак из позадине. Време одговора на корисничку акцију (tap-to-response). Време покретања за Android се мери преко ActivityManager-а, за iOS — преко dyld и premain времена. Према Firebase Performance, медијанa времена хладног покретања за 100 најбољих апликација износи 1,8 секунди.

Метрике меморије и CPU

Потрошња RAM меморије не би требало да прелази 80% доступног обима на уређају, иначе систем почиње да истоварује апликацију из позадине. Меморијски отисак се прати преко Xcode Instruments (iOS) и Android Profiler-а. Цурења меморије се откривају порастом потрошње при понављајућим операцијама — на пример, преласком између екрана.

Мрежне метрике

Време извршења HTTP захтева, величина одговора, учесталост timeout-а и грешака. Мрежно кашњење је посебно критично за мобилне апликације које раде у условима нестабилне везе (3G, метро, лифт, роминг). Препоручује се праћење p95 времена одговора — управо оно показује искуство нај"тежих" корисника са најгорим мрежним условима.

Real User Monitoring и Synthetic Monitoring

Real User Monitoring (RUM) прикупља податке са стварних уређаја корисника у производном окружењу. Ова метода показује стварна кашњења која корисници доживљавају, узимајући у обзир њихове уређаје, верзије ОС-а, мрежу и геолокацију. RUM даје најтачнију слику перформанси, али зависи од тога који корисници су ушли у узорак.

Synthetic Monitoring, напротив, извршава унапред дефинисане сценарије на тест уређајима у контролисаним условима. Омогућава откривање регресије пре него што стигне до корисника и репродуковање проблема у истом окружењу. Firebase Test Lab и BrowserStack пружају синтетичке тестове на стварним уређајима без ручног покретања.

Оптимална стратегија је комбинација оба приступа: синтетички тестови хватају регресије у CI фази, а RUM даје стварну слику у продукцији. Према Datadog (2024), тимови који користе обе методе откривају 35% више проблема са перформансама пре него што постану инциденти.

Подешавање Firebase Performance Monitoring

Firebase Performance Monitoring је бесплатан алат од Google-а за прикупљање метрика перформанси на iOS и Android. Аутоматски мери време покретања апликације, HTTP захтеве и рендеровање екрана без потребе за писањем кода. За инсталацију је довољно додати SDK у пројекат и активирати модул Performance у Firebase конзоли.

Аутоматско прикупљање метрика

Након повезивања SDK-а, Firebase Performance аутоматски креира trace за сваки HTTP захтев преко URLSession (iOS) или OkHttp (Android). Рендеровање екрана се мери за UIViewController и Activity, бележећи време од onCreate/viewDidLoad до завршетка првог рендеровања. Све метрике се агрегирају у Firebase конзоли са расподелом по верзијама апликације, уређајима и земљама.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // извршење плаћања
        trace.stop()
    }
}

Код креира прилагођени trace за сценариј плаћања са атрибутом износа. Преко овог trace-а у Firebase конзоли можете видети медијану и p95 времена извршења плаћања, груписано по верзијама апликације и уређајима.

HTTP праћење

Firebase аутоматски пресреће мрежне захтеве и бележи URL, код одговора, величину payload-а и време извршења. За OkHttp на Android-у аутоматска инструментација ради без додатног подешавања. Мрежни захтеви се приказују у конзоли са груписањем по endpoint-има, што омогућава брзо откривање успорења одређеног API-ја.

Прилагођени trace-ови за пословну логику

Стандардне метрике покривају опште перформансе, али за дијагностику пословних процеса потребна је инструментација одређених сценарија. Прилагођени trace-ови омогућавају мерење времена извршења аутентификације, учитавања вести, обраде слике или синхронизације података.

Сваки прилагођени trace треба да има смислено име у формату „scenario-akcija” и садржи атрибуте за филтрирање. На пример, trace „image-upload” са атрибутима „file_size” и „compression_quality” омогућиће откривање зависности времена учитавања од величине слике. Препоручује се да не креирате више од 20 прилагођених trace-ова по екрану — прекомерна инструментација ствара шум и отежава анализу.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // учитавање слике
    trace?.stop()
}

Пример у Swift-у креира trace за учитавање слике са атрибутима величине датотеке и нивоа компресије. У Firebase конзоли ови атрибути постају поља за груписање и филтрирање метрика.

Границе упозорења и алармирање

Прикупљање метрика без система обавештавања је бескорисно. Алармирање треба да обавештава тим о изласку метрика из дозвољених граница, при чему се границе упозорења деле на три нивоа: упозорење (warning), критично (critical) и хаваријско (outage). Сваки ниво одређује канал обавештавања: warning — на Slack канал тима, critical — у PagerDuty дежурном инжењеру, outage — масовно слање свим заинтересованим странама.

За мобилне метрике препоручује се коришћење динамичких граница заснованих на перцентилима: p95 време хладног покретања прелази 4 секунде — критични аларм. Статичке границе (на пример, CPU > 90%) раде лошије, јер не узимају у обзир нормалне флуктуације оптерећења у зависности од доба дана и дана у недељи. Firebase Performance подржава подешавање аларма путем Firebase Console са слањем у Slack, PagerDuty и е-поштом, са могућношћу ескалације у случају изостанка потврде.

Према Incident Management Survey (2024), тимови који подешавају аларме на основу перцентила, а не просечних вредности, пропуштају 45% мање инцидената. Просечна вредност (average) изглађује скокове — p95 гарантовано показује најгори сценариј за кориснике, без обзира на доба дана и сезонске флуктуације оптерећења.