Лагови у мобилном развоју: шта су, узроци и методе отклањања

Шта је лаг у мобилном развоју

Лаг (од енгл. lag) у мобилној апликацији је субјективно приметно кашњење између радње корисника (додир, превлачење, унос текста) и реакције интерфејса. Технички, лаг се мери као време између улазног догађаја и потпуног рендеровања оквира: удобан праг — до 100 ms, приметан — од 200 ms, критичан — преко 500 ms.

Разлика између лага, грешке и успоравања

У корисничкој терминологији „лагује” и „успорава” се често користе као синоними, али технички лаг је фиксно кашњење (нпр. 300 ms при сваком клику), а „успорава” — нестално успоравање: апликација понекад ради глатко, понекад се замрзне на секунд. Грешка, за разлику од лага, везана је не за брзину, већ за исправност приказа.

Утицај лагова на метрике апликације

Google Play и App Store узимају у обзир показатеље перформанси при рангирању апликација. ANR стопа, учесталост џанка (jank) и време покретања утичу на видљивост у претрази и конверзију инсталација. Апликација са сталним лаговима губи до 40% корисника након првог покретања.

Узроци лагова и успоравања у апликацијама

Лагови настају када главна UI нит не стигне да обради оквире са учесталошћу од 60 FPS (16.6 ms по оквиру) или 120 FPS (8.3 ms). Размотримо главне изворе кашњења.

Блокирање главне нити

Свака синхрона операција у UI нити — читање из SharedPreferences, рад са базом података преко Room без suspend, декодирање слике у Bitmap — блокира цртање оквира. На Android-у ово доводи до прескакања оквира (jank), на iOS-у — до кашњења рендеровања Core Animation.

Цурење меморије и честе GC паузе

Када Garbage Collector на Android-у или ARC на iOS-у ослобађа меморију, све нити се заустављају. Честе GC паузе настају при стварању великог броја привремених објеката — на пример, при сваком позиву адаптера листе ствара се нова инстанца ViewHolder. Ово се манифестује као трзаво скроловање.

Тешке layout хијерархије

Угнежђени ConstraintLayout, вишеструки LinearLayout, преклапајући View — свако угнежђење повећава време measure и layout pass-а. Xcode указује да дубока хијерархија слојева (више од 10 нивоа) изазива пад FPS за 20-30%.

• Android — прекомерни requestLayout, неефикасни ConstraintLayout ланци, велики Bitmap без downscale
• iOS — Auto Layout constraints са конфликтима, тешки CALayer, shadowPath без растеризације
• Cross-platform — синхрони HTTP позиви у UI нити, тешко парсирање JSON, неоптималне слике високе резолуције

Како дијагностиковати кашњења перформанси

За откривање узрока лагова користе се профилери уграђени у IDE и алати системског надзора. Сваки алат решава свој задатак.

CPU Profiler у Android Studio

CPU Profiler показује које методе заузимају процесорско време и у којим нитима се извршавају. Ако се метод са тешким прорачунима извршава у main thread-у — то је корен проблема. Снимак трасирања са укљученим sample Java Method омогућава да се види стек позива у сваком тренутку и пронађу „вруће тачке”.

Time Profiler у Xcode Instruments

Аналогни алат за iOS — Time Profiler — прикупља узорке стека сваке милисекунде и показује који проценат CPU времена заузима сваки метод. Комбинација са заставицом Main Thread Only филтрира само операције на главној нити, што директно указује на изворе лагова.

Network Profiler и анализа захтева

Спори мрежни захтеви стварају утисак лагова, чак и ако UI нит није блокирана. Network Profiler у Android Studio и Network Link Conditioner у Xcode омогућавају симулацију споре везе и откривање како се апликација понаша у реалним условима. Chunked одговори без напретка и велики JSON товари — типични извори привидних лагова.

Пример профилисања мрежног захтева са OkHttp уз мерење времена:

class TimingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val start = System.nanoTime()
        val response = chain.proceed(chain.request())
        val duration = (System.nanoTime() - start) / 1_000_000
        Log.d("Тајминг", "Захтев је трајао $duration ms")
        return response
    }
}

Методе отклањања лагова на Android и iOS

Отклањање лагова захтева систематски рад: од оптимизације једног метода до архитектонских промена. Размотримо најефикасније технике.

Асинхрона обрада кроз корутине и GCD

Kotlin Coroutines са диспечером Dispatchers.IO за мрежне захтеве и Dispatchers.Default за прорачуне гарантују да главна нит остаје слободна за UI. На iOS-у Grand Central Dispatch са queue .global(qos: .userInitiated) за позадинске задатке и .main за ажурирање UI — стандардни приступ. Избегавајте sync операције између редова.

Оптимизација адаптера и листи

RecyclerView на Android-у и UICollectionView на iOS-у захтевају правилно подешавање: ViewHolder са минималним стварањем објеката у onBindViewHolder, DiffUtil за израчунавање промена, prefetching за раније учитавање података. На iOS-у користите diffable data source за анимирана ажурирања без ручног управљања.

Кеширање података и слика

Учитавање исте слике при сваком скроловању — гарантовани лаг. Coil (Android) и Kingfisher (iOS) кеширају слике у меморији и на диску, обезбеђујући тренутни приказ при поновном захтеву. За податке користите Room са кеширајућим слојем заснованим на Flow или Combine.

Пример подешавања кеширања слика са Coil на Android-у:

val imageLoader = ImageLoader(context) {
    memoryCachePolicy(CachePolicy.ENABLED)
    diskCachePolicy(CachePolicy.ENABLED)
    crossfade(true)
    size(512, 512)
}

// Учитавање са укљученим аутоматским кеширањем
imageView.load("https://example.com/image.jpg") {
    placeholder(R.drawable.placeholder)
    error(R.drawable.error)
}

Превенција лагова у фази развоја

Спречавање лагова је јефтиније него њихово исправљање у продукцији. Превентивне мере се уграђују у процес развоја на нивоу алата и архитектуре.

StrictMode на Android-у

StrictMode — уграђени Android алат који открива случајне операције улаза-излаза и мрежне позиве на главној нити у фази развоја. Укључите га у Application.onCreate са политиком penaltyDeath за критичне прекршаје. Ово је једини начин да се гарантује да ће програмер видети проблем пре комита.

Main Thread Checker на iOS-у

Аналог за iOS — Main Thread Checker у Xcode, који је део Runtime Sanitization. Он аутоматски проверава да се сви позиви UIKit и AppKit извршавају из главне нити. Укључите га у шеми компилације Debug и постигните нула упозорења у CI.

Бенчмаркови перформанси у CI

Додајте у CI цевовод покретање Macrobenchmark (Android) и XCTMetrics (iOS) за мерење времена покретања, FPS скроловања и коришћења меморије. Поставите прагове: ако нови комит повећава време покретања за више од 5% — изградња пада.

• Android — Macrobenchmark, Baseline Profiles, Jetpack Benchmark Library
• iOS — XCTMetrics, os_signpost, MetricKit за прикупљање метрика са уређаја корисника
• Општи приступ — профилисање пре и после сваке значајне промене, регресиони тестови перформанси