Mobil Uygulama Performans Optimizasyonu: Startup Time ve FPS

Google Play Console 2026 verilerine göre cold start 2 saniyeyi aşan uygulamalarda 7 günlük tutma %29 düşüyor; 3 saniye üstünde dönüşüm kaybı %38’e ulaşıyor. Apple App Store Connect aynı dönemde, ortalama FPS 50 altında kalan uygulamalarda 30 günlük retention’ın %22 daha düşük olduğunu raporladı. Sentry Mobile Performance Index 2026, kullanıcıların %47’sinin “yavaş” hissettikleri uygulamayı 90 gün içinde sildiğini gösteriyor. Statista küresel app abandonment raporuna göre ilk açılışta 5 saniye üstü bekleme, kullanıcının uygulamayı bir daha açma olasılığını %53 düşürüyor. Mobil performans 2026 itibarıyla UX kozmetiği değil, iş sonuçlarının ölçülebilir sürücüsüdür.

Bu rehberde startup time fazları (TTI, TTFR, time-to-content), frame budget matematiği (60/90/120 Hz), iOS Core Animation ile Android RenderThread render pipeline farkları, bellek baskı seviyeleri, App Hang/ANR eşikleri, profiling araç stack’i ve sürdürülebilir performans yönetim modelini sayısal hedeflerle inceliyoruz.

Mobil Performansın Üç Eksenli Tanımı

Mobil performans üç eksende ölçülür ve birbirinden bağımsız regresyon gösterebilir. Başlangıç performansı (cold/warm/hot start, TTFR, TTI), çalışma anı akıcılığı (FPS, jank %, App Hang/ANR, scroll smoothness) ve kaynak verimliliği (peak memory, energy drain, network payload, disk I/O). Üretim cihazlarında her üç eksen P50/P75/P95 dağılımıyla raporlanmalı; mid-range Android pazarında P95 değerleri P50’nin ortalama 2.4 katıdır ve gerçek kullanıcı deneyimini yalnızca uzun kuyruk yansıtır.

Startup Time Fazları: Cold, Warm, Hot

Başlangıç süresi üç farklı senaryoda üç ayrı eğridir. Cold start sürecin sıfırdan başladığı en pahalı senaryodur ve binary load, runtime init, application object, ilk Activity/ViewController, ilk frame ve TTI aşamalarına ayrılır. Warm start sürecin canlı olduğu ama Activity’nin yeniden oluştuğu durumdur; cold start’ın %30-40’ı kadar sürer. Hot start arka plandan ön plana dönüşte yaşanır; hedef 400 ms altıdır. Google Play vitals dokümantasyonu bu üç senaryoyu Android Vitals üzerinden ayrı raporlar; threshold ihlali Play Store sıralamasında negatif sinyal üretir.

Senaryo	Tanım	Hedef P50	Hedef P95	Play Vitals Sınırı	Ana Optimizasyon
Cold Start	Süreç sıfırdan	900 ms	1.8 sn	5 sn üstü kritik	Baseline profiles, lazy init
Warm Start	Süreç canlı, Activity yeniden	350 ms	900 ms	2 sn üstü uyarı	State restore optimizasyonu
Hot Start	Foreground’a dönüş	120 ms	400 ms	1.5 sn üstü uyarı	Resume hook minimize
TTFR	İlk piksel	700 ms	1.4 sn	Resmi sınır yok	Splash hierarchy, pre-warm
TTI	Tap’e yanıt verebilir hâl	1.2 sn	2.3 sn	Resmi sınır yok	Ana thread temizliği
Time-to-Content	Anlamlı içerik gösterimi	1.6 sn	3.0 sn	Resmi sınır yok	Skeleton + paralel fetch

Android’de baseline profiles + App Startup library + Macrobenchmark kombinasyonu cold start’ı %22, Compose ekranlarda ilk frame’i %35 düşürür. iOS’ta pre-main süresi (dyld load, ObjC runtime init, +load metodları), dyld3 cache ve Swift static linker kritiktir. Her iki platformda da Application / AppDelegate içinde I/O, ağ, JSON parse veya analytics SDK init yapılmamalı; tüm pahalı işler ilk gerçek ihtiyaç anına ertelenmelidir. Splash screen optimizasyon yerine geçmez; sorunu maskeler ve P95’i gizler.

Frame Budget Matematiği: 60, 90, 120 Hz

Akıcılığın matematiği acımasızdır: ekran tazeleme frekansı her frame için sabit bütçe verir; aşan kareler “dropped frame” olur ve kullanıcıda jank/stutter/scroll takılması olarak hissedilir. 2026 itibarıyla flagship Android’in %78’i 120 Hz, mid-range’in %54’ü 90 Hz ekranla geliyor; iPhone ProMotion ailesi 120 Hz adaptive refresh kullanıyor. Tek 16.67 ms hedefi değil, cihaza göre üç farklı bütçe vardır.

Refresh Rate	Frame Bütçesi	Render + Layout Hedefi	GPU Hedefi	Jank Tolerans	Tipik Cihaz Segmenti
60 Hz	16.67 ms	8 ms	6 ms	%1 üstü uyarı	Entry / mid-range Android
90 Hz	11.11 ms	5.5 ms	4 ms	%0.7 üstü uyarı	Mid-range / üst orta Android
120 Hz	8.33 ms	4 ms	3 ms	%0.5 üstü uyarı	Flagship Android, ProMotion iPhone
120 Hz Adaptive	8.33-33 ms	Dinamik	Dinamik	İçerik bazlı	iPhone Pro, Pixel Pro, Galaxy S Ultra

120 Hz hedefi 60 Hz’in yarısı kadar frame bütçesi demektir; aynı UI kodu 60 Hz’de smooth görünürken 120 Hz’de jank yapabilir. Apple HIG performance ProMotion için adaptive refresh önerir: durağan içerikte 10 Hz, scroll’da 120 Hz. Android’de Choreographer ve FrameMetricsAggregator frame süre dağılımını verir; P95 eşik ihlali CI’da otomatik regression olarak işaretlenmelidir.

Render Pipeline: iOS Core Animation vs Android RenderThread

İki platformun render mimarisi yüzeyde benzer ama detayda derin farklıdır; aynı optimizasyon eşit fayda üretmez. iOS Core Animation CALayer ağacını GPU’ya offload eden compositor üzerine kuruludur; transaction commit anında GPU iş kuyruğu doldurulur. Android’de UI thread layout+draw yapar, ardından RenderThread display list’i GPU’ya gönderir. Bu fark hangi katmanda iyileştireceğinizi belirler.

Boyut	iOS Core Animation	Android RenderThread
Compositor	backboardd / WindowServer	SurfaceFlinger
Layer modeli	CALayer ağacı	RenderNode + display list
UI thread işi	Layout + transaction commit	Layout + draw call recording
GPU thread	Sistem composer	RenderThread (uygulama içi)
Off-screen render maliyeti	Yüksek (corner radius + shadow)	Orta (HW layer + clipPath)
Asenkron rasterization	shouldRasterize + drawsAsynchronously	setLayerType HARDWARE
Profiling	Instruments Core Animation	Perfetto + GPU profiler

iOS’ta corner radius + shadow + masksToBounds kombinasyonu off-screen rendering tetikler ve scroll’da jank üretir; Instruments Color Off-screen Rendered Yellow modu bu durumu işaretler. Android’de gereksiz clipPath, derin View hiyerarşisi, overdraw birikimi ve büyük bitmap software rasterization RenderThread’i şişirir. Hedef aynı: ana thread temiz, ağır iş GPU veya background thread’e taşınsın.

• Off-screen rendering: iOS’ta corner radius + shadow zinciri; çözüm pre-rendered asset veya shouldRasterize.
• Overdraw birikimi: Android’de iç içe arka plan katmanları; Developer Options > Debug GPU overdraw modu ile görselleştirilir.
• Layout thrashing: Scroll sırasında ölçüm yeniden tetikleyen view ağacı; ConstraintLayout veya SwiftUI primitive ile çözülür.
• Bitmap rasterization: Büyük image’ların runtime decode’u; downsampling ve thumbnail caching ile sıfırlanır.
• Compose recomposition: Gereksiz state bağımlılığı; Compose Compiler metrics ile tespit, derivedStateOf ile çözüm.
• UI thread bloklayan IPC: Senkron AIDL/Binder veya XPC çağrısı; async wrapper veya callback model’e çevrilir.

Profiling Araç Stack’i: Üretim ve Geliştirme

Profiling iki katmanda yürür: geliştirme zamanı (deep dive, root cause) ve üretim zamanı (RUM, dağıtık metric). Tek araç her ikisini eşit kapsamaz; doğru kombinasyon geliştirme için Android Studio Profiler/Perfetto + Xcode Instruments, üretim için Firebase Performance + Sentry Mobile veya Datadog RUM Mobile’dır.

Araç	Platform	Cold Start	FPS / Jank	Bellek	Network	Üretim Verisi	Tipik Maliyet
Android Studio Profiler	Android	Çok güçlü	Güçlü	Çok güçlü	Orta	Hayır	Ücretsiz
Macrobenchmark	Android	Çok güçlü	Çok güçlü	Orta	Yok	Hayır	Ücretsiz
Perfetto	Android + Linux	Çok güçlü	Çok güçlü	Çok güçlü	Orta	Hayır	Ücretsiz
Xcode Instruments	iOS	Çok güçlü	Çok güçlü	Çok güçlü	Güçlü	Hayır	Ücretsiz
Firebase Performance	Android + iOS	Güçlü	Güçlü	Yok	Güçlü	Evet	Ücretsiz tier
Sentry Mobile	Android + iOS	Güçlü	Güçlü	Orta	Güçlü	Evet	$26+/ay
Datadog RUM Mobile	Android + iOS	Güçlü	Güçlü	Orta	Çok güçlü	Evet	Volume bazlı
Flipper	Android + iOS	Orta	Orta	Orta	Güçlü	Hayır	Ücretsiz

Geliştirme tarafında Perfetto Android 10+ için Systrace’in yerini aldı; CPU scheduling, GPU pipeline, binder calls ve ftrace event’lerini tek timeline’da gösterir. Android Studio Profiler Compose recomposition, allocation tracking ve baseline profile generation için günlük araçtır. iOS’ta Xcode Instruments içinde Time Profiler, Allocations, Leaks, Hangs ve Core Animation şablonları zorunlu rotasyondur. Üretimde Sentry Mobile Vitals P95 cold start ve frozen frame oranını release bazlı izler; regresyon eşiği aşılınca deploy bloke edilir.

Bellek Baskı Seviyeleri ve Response Stratejileri

Mobil OS’lar bellek baskısı oluştuğunda kademeli sinyaller yayınlar; uygulama sinyalleri ciddiye almazsa OS LMK (Android) veya jetsam (iOS) yoluyla süreci sonlandırır. Aylık %0.5 üstü OOM oranı retention’da kalıcı hasar üretir. Baskı tek threshold değil merdivendir; her seviye farklı response gerektirir.

Seviye	Android Sinyali	iOS Sinyali	Tipik Tetik	Response Stratejisi
Düşük	TRIM_MEMORY_RUNNING_MODERATE	didReceiveMemoryWarning (low)	Background app birikimi	L2 cache flush, off-screen bitmap drop
Orta	TRIM_MEMORY_RUNNING_LOW	didReceiveMemoryWarning (normal)	Aktif kullanım baskısı	Image cache trim, prefetch durdur
Yüksek	TRIM_MEMORY_RUNNING_CRITICAL	didReceiveMemoryWarning (critical)	OOM yakın	Tüm non-essential cache temizle, video stream durdur
Background	TRIM_MEMORY_UI_HIDDEN	applicationDidEnterBackground	App backgrounded	UI cache, ImageView referansları drop
Kritik	TRIM_MEMORY_COMPLETE	jetsam imminent	LMK / jetsam yaklaşıyor	State persist + minimal footprint

Leak tespitinde Android’de LeakCanary debug build’lerde Activity ve Fragment sızıntılarını otomatik raporlar; iOS’ta Instruments Leaks ve Allocations şablonları kullanılır. Üretimde Sentry ve Firebase Crashlytics OOM crash’lerini ayrı metric gösterir. Hedef: P95 peak memory cihaz fiziksel belleğinin %35 altında, OOM oranı aylık %0.3 altında.

App Hang ve ANR Tespiti

App Hang (iOS) ve ANR — Application Not Responding (Android) ana iş parçacığının uzun süreli bloklanmasıdır; kullanıcı tarafından “donmuş uygulama” olarak deneyimlenir. Her iki platformda sistem otomatik tespit eder ve metrik yayınlar; eşik ihlali Play/App Store sıralamasında negatif sinyal üretir.

Sınıflandırma	Android ANR	iOS App Hang	Kullanıcı Hissi	Tipik Sebep	Hedef Oran
Mikro Hang	100-250 ms	100-250 ms	Hafif takılma	UI thread’de sync IPC	%2 altı
Kısa Hang	250 ms – 1 sn	250 ms – 1 sn	Belirgin gecikme	Disk I/O, JSON parse	%0.8 altı
Orta Hang	1-2 sn	1-2 sn	Donmuş hissi	Senkron network, bitmap decode	%0.4 altı
ANR / Severe Hang	5 sn üstü (zorla kill riski)	2 sn üstü (rapor edilir)	Tamamen donuk	Deadlock, infinite loop	%0.47 altı (Vitals)

Apple App Hang baseline 2026 itibarıyla %0.6’ya çekildi; üstüne çıkan uygulamalar App Store Connect üzerinden uyarı alıyor. Google Play Vitals “ANR rate user-perceived” %0.47’yi kritik eşik kabul ediyor. Çözüm: ana thread’de senkron disk/network çağrısı yasak; tüm pahalı işler coroutine / async-await / OperationQueue üzerinde olmalı.

Lazy Loading ve Init Erteleme Patternleri

Cold start optimizasyonunun %70’i gereksiz işi başlangıçtan kaldırmaktan geçer. Analytics SDK init, A/B framework warmup, remote config fetch, push token registration, image preloader ve crash reporter session start gibi “ilk frame’den önce çalışan” kod parçaları lazy initialization ile gerçek ihtiyaç anına ertelenmelidir.

• App Startup Library (Android Jetpack): Tüm content provider tabanlı init’leri tek noktada birleştirir; bağımlılık grafiğine göre ertelenebilir initializer sınıfları yazılır.
• Coroutine + structured concurrency: Ana thread’de yapılan tüm I/O Dispatchers.IO‘ya taşınır; başlangıç anında yapılan ağ çağrıları lifecycleScope üzerine alınır.
• Lazy by-property delegation: Kotlin by lazy, Swift lazy var ile sınıf alanları ilk erişimde yüklenir; init listesinden çıkarılır.
• SwiftUI Task modifier: View görünür olduğunda task başlatılır, screen background’a gittiğinde otomatik iptal edilir.
• Jetpack Compose remember + LaunchedEffect: Composable yaşam döngüsüne bağlı side-effect; recomposition sırasında re-run önlenir.
• WorkManager / BGTaskScheduler: Cron-benzeri arka plan işleri OS scheduler’a devredilir; başlangıç critical path’inden tamamen çıkar.
• Image lazy load + placeholder: Coil, Glide, SDWebImage’da downsampling açık; off-screen image’lar memory’ye alınmaz.

iOS’ta +load yerine +initialize; @inlinable ve static linkage doğru kullanıldığında dyld pre-main süresini azaltır. SPM modüllerinde static linkage tercihi dynamic linker overhead’ini düşürür. web.dev mobile performance hybrid uygulamalar için critical CSS, code splitting ve preload stratejilerini benzer mantıkla aktarır.

FPS ve Render Optimizasyon Adımları

1. UI iş parçacığında ağır işlemleri tespit edin: Perfetto veya Time Profiler ile frame bütçesini aşan kareleri çıkarın; ana thread main loop’unda blocking call var mı?
2. RecyclerView/LazyColumn/LazyVStack içinde view binding maliyetini azaltın: stable key, item type ve view holder yeniden kullanımını doğru yapılandırın.
3. Bitmap ve görselleri doğru çözünürlükte yükleyin; Coil, Glide veya SDWebImage’da downsampling ve inSampleSize açık olsun.
4. Overdraw seviyesini ölçün: ekranın aynı pikseli en fazla 2-3 kez çizilmelidir; gereksiz arka plan katmanlarını ve transparent overlay’leri kaldırın.
5. Karmaşık layout’ları ConstraintLayout veya SwiftUI / Compose primitive’leriyle yeniden tasarlayın; iç içe LinearLayout zincirlerini düzleştirin.
6. Off-screen rendering tetikleyicilerini temizleyin: iOS corner radius + shadow kombinasyonu yerine pre-rendered asset veya shouldRasterize kullanın.
7. Frame Metric API ile üretim cihazlarında jank ve frozen frame oranı toplayın; sürüm bazlı regresyon CI’da bloklansın.
8. Compose recomposition’u Layout Inspector veya Compose Compiler metrics ile izleyin; gereksiz State bağımlılıklarını ayıklayın.

Network, Payload, Maliyet ve Sınırlamalar

Performans problemlerinin %40-60’ı ağ katmanından gelir. HTTP/2 multiplex, HTTP/3 (QUIC) head-of-line blocking eliminasyonu, brotli sıkıştırma, payload küçültme ve AVIF/WebP kombinasyonu temel araçlardır. Ülke içi PoP’lu CDN 4G/5G cihazlarda P95 yanıtı 800 ms’den 250 ms’ye indirir. GraphQL veya tailored REST gereksiz alan transferini keser; over-fetching mobilde batarya ve veri kotası yakar.

• Image format zinciri: AVIF (öncelik) → WebP (fallback) → JPEG (legacy); aynı asset için srcset benzeri çoklu çözünürlük.
• Brotli q=4 mobile payload için CPU/sıkıştırma dengesi olarak optimaldir; q=11 sadece statik içerikte.
• OkHttp / URLSession connection pool ayarları: keep-alive süresi 60 sn, max idle 5 connection.
• Retry stratejisi exponential backoff + jitter; 3 deneme üstü kullanıcıya hata gösterilir.
• Offline-first cache: Room / Core Data + ETag tabanlı conditional GET; 304 cevabı parse maliyetinden tasarruf sağlar.

Orta ölçekli bir uygulamada 6 haftalık odaklı performans sprint’i 2 senior + 1 QA ile 90.000-140.000 USD maliyet üretir. Karşılığında P95 cold start’ın 3.2’den 1.6 saniyeye inmesi retention’ı %14, conversion’ı %9, ARPU’yu %6 artırır. Aylık 100K aktif kullanıcılı bir e-ticaret app’inde yıllık 600.000 USD üstü ek gelir anlamına gelir.

Sınırlamalar: hiçbir optimizasyon kötü mimariyi telafi etmez. Büyük DI grafikleri, ağır JSON yanıtlar, donanım filtresiz grafik efektleri ve çok katmanlı abstraction’lar profil temizliği yapılmadan yatırımı boşa düşürür. Cross-platform framework seçimi performans sınırını belirler; bu karar erken verilmeli (bkz. React Native vs Flutter 2026 ve iOS Native vs Cross-Platform 2026).

Sürdürülebilirlik: CI’da Performans Regresyonu

Performans defalık sprint değil; sürekli mühendislik disiplinidir. Macrobenchmark ve XCTest Performance ile CI’a cold start, scroll FPS ve memory peak baseline yazılır; her PR baseline’a karşı çalışır, %5 üstü regresyon CI’ı kırar. Üretimde Sentry/Firebase/Datadog dashboard’unda P95 cold start ve frozen frame rate alarm’a bağlanır; release sonrası 4 saat içinde regresyon görülürse otomatik rollback tetiklenir. Mobil CI/CD pipeline bu otomasyonun belkemiğidir.

Push notification, deep link ve crash reporting katmanları da performans bütçesinin parçasıdır: yanlış yapılandırılmış push handler ana thread’de blocking iş yapabilir, deep link parser cold start’a yük bindirir. Tam pipeline için mobil push notification ve deep link / universal link rehberi birlikte değerlendirilmelidir.

Sık Sorulan Sorular

Sonuç: Optimizasyon Önceliği Verdict

Mobil performans optimizasyonu retention, conversion ve ARPU üzerinde kanıtlanabilir etki üreten ROI’li bir mühendislik disiplinidir. Öncelik sırası: önce ölçüm (üretim cihazlarında P95 metric stack’i), sonra cold start (baseline profiles + lazy init), ardından ana thread temizliği (App Hang/ANR sıfırlama), sonra FPS ve render pipeline (frame budget disiplini), en son network ve bellek (payload + cache). 6 haftalık odaklı sprint P95 cold start’ı yarıya indirir; bu %14 retention + %9 conversion getirisidir. Profiling üretimde sürekli yapılmalı, regresyon CI’da otomatik bloklanmalı, baseline her major release’de yeniden kilitlenmelidir. 2026 itibarıyla bu disiplin opsiyonel değil; rekabet avantajının kendisidir.