Mobil Uygulamalarda FPS: Özü, Hesaplanması ve Optimizasyonu

FPS Nedir

FPS (Frames Per Second), bilgisayar grafikleri, video ve mobil arayüzlerde kullanılan kare hızı ölçü birimidir. Her kare, ekranda kısa bir süre görüntülenen statik bir görüntüdür. Hızlı kare değişimleriyle beyin bunları sürekli hareket olarak algılar — bu etkiye görme kalıcılığı denir. Mobil uygulamalar için FPS kritik bir ölçüttür çünkü atlanan herhangi bir kare, akıcı bir animasyonu fark edilir bir takılmaya dönüştürür. Uygulama her kareyi zaman bütçesi içinde kesinlikle oluşturmalıdır: 60 FPS için 16,6 ms, 90 FPS için 11,1 ms, 120 FPS için 8,3 ms.

FPS yalnızca kullanıcı arayüzü için değil, aynı zamanda oyunlar, video ve kamera için de ölçülür. Oyunlarda FPS, sahne karmaşıklığına, doku kalitesine ve GPU gücüne bağlıdır. Videoda FPS sabittir (24, 30, 60 fps) ve içeriğe göre belirlenir. Mobil uygulamalarda FPS, UI kodunun verimliliğine bağlıdır: Layout karmaşıklığı, View sayısı, yeniden çizim sıklığı ve GC (Garbage Collection) çalışması. Apple WWDC 2022'ye göre, verimsiz koleksiyon güncellemeleri (insert/delete/dequeueReusableCell yerine reloadData) nedeniyle bir uygulamadaki ortalama FPS %10–15 oranında düşebilir. Gerçek zamanlı FPS ölçümü, performans üzerinde çalışan QA mühendisleri ve geliştiriciler için standart bir uygulamadır.

FPS Nasıl Hesaplanır

Mobil uygulamada FPS hesaplaması, ardışık kareler arasındaki sürenin ölçülmesine dayanır. En basit formül: FPS = 1000 / deltaTimeMs, burada deltaTimeMs, önceki karenin tamamlanması ile mevcut karenin tamamlanması arasındaki aralıktır. Mevcut kare 20 ms'de oluşturulduysa, FPS = 1000 / 20 = 50. Ancak pratikte FPS, bir saniye içinde bile nadiren kararlıdır: tipik bir profil, atlanmış (jank) veya yavaş karelerle (40–60 ms) serpiştirilmiş 12–16 ms'lik kareler içerir. Bu nedenle FPS, 1–5 saniye üzerinden hareketli ortalama veya kare süresi dağılımının yüzdelik dilimleri olarak ölçülür.

Android'de FPS, VSync'ten (ekran senkronizasyon darbesi) geri arama alan Choreographer aracılığıyla hesaplanır. Her geri arama bir kareye karşılık gelir. Geri arama gelmezse kare atlanır. Choreographer, saniyedeki tam kare sayısını ve atlanan kare sayısını ölçmeye olanak tanır. iOS'ta CADisplayLink benzer şekilde çalışır — ekran yeni bir kare oluşturmaya hazır olduğunda her seferinde çağrılır. timestamp özelliği son karenin tam saatini içerir ve targetTimestamp bir sonraki karenin beklenen saatini içerir. Aralarındaki fark, mevcut kare için zaman bütçesidir.

CADisplayLink ile FPS İzleme

Swift kodu, CADisplayLink aracılığıyla basit FPS izlemeyi gösterir. frameCount sayacı her çağrıda artar ve saniyede bir kez gerçek FPS hesaplanır.

class FpsCounter {

    private var displayLink: CADisplayLink?
    private var frameCount = 0
    private var lastTime = TimeInterval(0)

    func start() {
        displayLink = CADisplayLink(
            target: self,
            selector: #selector(countFrame)
        )
        displayLink?.add(to: .current,
            forMode: .common)
    }

    @objc
    private func countFrame() {
        frameCount += 1
        let now = Date().timeIntervalSince1970

        if now - lastTime >= 1.0 {
            print("FPS: \(frameCount)")
            frameCount = 0
            lastTime = now
        }
    }
}

Neden 60 FPS Standarttır

60 FPS (veya 60 Hz)标准ı, sektörde birkaç nedenden dolayı yerleşmiştir. İlki fizyolojiktir: insan gözü 50–60 Hz'in üzerindeki frekanslarda tek tek kareleri ayırt edemez ve bunları akıcı hareket olarak algılar. Bu eşik Critical Flicker Fusion (CFF) olarak adlandırılır. İkincisi tarihseldir: ilk katot ışın tüpleri (CRT) ABD'de (NTSC) 60 Hz ve Avrupa'da (PAL) 50 Hz'de çalışıyordu. Modern LCD ekranlar bu frekansı miras almıştır. Üçüncüsü mühendislikle ilgilidir: UI animasyonları için 60 FPS, metin girişi, kaydırma ve sürükleme için kritik olan milisaniye altı dokunma yanıt gecikmesi sağlar.

Mobil geliştiriciler için 60 FPS yalnızca bir öneri değil, kare başına 16,6 ms'lik sıkı bir bütçedir. Bu bütçe, oluşturmanın tüm aşamaları arasında bölünür: Girdi (1–2 ms), Animasyon (2–3 ms), Layout (3–5 ms), Çizim (3–5 ms) ve Değişim (1–2 ms). Herhangi bir aşama alt bütçesini aşarsa, kare 16,6 ms'ye sığmayabilir. Google Android Performance, sistem kesintileri (GC, arka plan iş parçacıkları) için 2–4 ms boşluk bırakarak kare hazırlığı için 12–14 ms içinde kalmayı önerir. Firebase Performance'a göre, ortalama FPS'si 52'nin altında ve P99 FPS'si 30'un altında olan uygulamalar, Google Play incelemelerinde %35 daha fazla performans şikayeti alır.

FPS ve Kare Süresi: İlişki

FPS ve kare süresi aynı ölçütün iki yüzüdür ve bunları karıştırmamak önemlidir. FPS hızdır, kare süresi gecikmedir. 60 FPS'de her kare 16,6 ms sürer. 30 FPS'de — 33,3 ms. Ancak FPS doğrusal olmayan bir ölçüttür: 60'tan 30 FPS'ye düşüş, kare süresinin iki katına çıktığı anlamına gelirken, 30'dan 20'ye düşüş 1,5 kat artış anlamına gelir. Bu nedenle profilleyiciler, ortalama frekans yerine kare süresini gösterir — bu, sorunlu karelerin görülmesini sağlar. Örneğin, ortalama 55 FPS, karelerin %5'inin 50–100 ms kare süresine sahip olduğu gerçeğini gizleyebilir — bu kareler Jank'a neden olur ancak ortalama FPS'yi önemli ölçüde etkilemez.

Performans analiz edilirken, ortalama FPS'ye değil, kare süresi histogramına bakılması önerilir. Android Studio Profiler ve iOS Instruments'da kare süresi, yeşil bölgenin 16,6 ms'ye (60 FPS), sarının 16,6–33,3 ms (30–60 FPS) ve kırmızının 33,3 ms'den (30 FPS'den az) fazla olduğu bir ölçek olarak görüntülenir. Her kırmızı sütun, kullanıcı için fark edilir bir gecikmedir. Pratik bir kural: P95 Kare Süresi (karelerin %95'i X ms içinde sığarsa) ortalama FPS'den daha güvenilir bir ölçüttür. P95 Kare Süresi 32 ms'yi (30 FPS) aşarsa, uygulama ortalama 50 FPS'de bile yavaş olarak algılanır.

Kare Süresini FPS'ye Dönüştürme

Yüzdelik dilimlerle bir kare süresi dizisini FPS'ye dönüştüren bir Kotlin işlevi. Ayrıntılı analiz için yalnızca ortalama FPS'yi değil, aynı zamanda P50, P90 ve P99'u da döndürür.

data class FpsReport(
    val average: Float,
    val p50: Float,
    val p90: Float,
    val p99: Float
)

fun List<Long>.toFpsReport(): FpsReport {
    val fpsValues = this.map { ms ->
        if (ms > 0) 1000f / ms else 0f
    }.sorted()

    return FpsReport(
        average = fpsValues.average().toFloat(),
        p50 = fpsValues[fpsValues.size / 2],
        p90 = fpsValues[(fpsValues.size * 90 / 100)],
        p99 = fpsValues[(fpsValues.size * 99 / 100)]
    )
}

Yüksek FPS ve Yeni Ekranlar

90, 120 ve 144 Hz ekranlara sahip modern mobil cihazlar, FPS için yeni gereksinimler getirir. Bir uygulama 120 Hz ekranda 60 FPS sağlıyorsa, kullanıcı mikro takılmalar görür çünkü her ikinci ekran yenileme döngüsü aynı kareyi alır. 120 FPS'yi korumak için kare başına bütçe 16,6'dan 8,3 ms'ye düşer — bu da iki kat daha verimli oluşturma kodu gerektirir. Android geliştiricilerine (Google I/O 2023) göre, kararlı 120 FPS elde etmek için şunlar gerekir: çizim döngüsünde ayırmalardan kaçınma, hiyerarşideki görünüm sayısını en aza indirme (80'in altında), ağır drawable'ları VectorDrawable lehine terk etme ve karmaşık grafikler için surfaceView kullanma.

iOS'ta durum benzerdir: ProMotion (120 Hz) ile iPhone Pro iki kat daha fazla kare gerektirir, ancak kare başına süre yarıya iner. Apple, tüm animasyonların 120 FPS'de çalışması gerekmediğini belirtir — Core Animation, statik veya yavaş değişen öğeler için kare hızını otomatik olarak düşürür. Ancak kaydırma, jest animasyonları ve geçişler, “ipeksi” bir his için 120 FPS sağlamalıdır. 60'tan 120 FPS'ye geçişteki ana sorunlar: artan güç tüketimi (GPU için %25–40), cihaz ısınması ve kısma (throttling) — aşırı ısınma nedeniyle kare hızının düşmesi. Bir geri dönüş mekanizması uygulanması önerilir: kare süresi sürekli olarak 8,3 ms'yi aşarsa, sistem kısmasını beklemek yerine programlama yoluyla hedef kare hızını 60 FPS'ye düşürün.

60/120 FPS Anahtarı

Android için Java kodu, cihazın 120 FPS'yi destekleyip destekleyemeyeceğini belirler ve oluşturma modunu değiştirir. Desteklenen yenileme hızlarını belirlemek için Display.getMode kullanılır.

class FpsModeSwitcher {

    static boolean canDo120Fps(Activity activity) {
        Display display = activity.getWindowManager()
            .getDefaultDisplay();
        for (Display.Mode mode : display.getSupportedModes()) {
            if (mode.getRefreshRate() >= 120f) {
                return true;
            }
        }
        return false;
    }
}

Uygulamalarda FPS Optimizasyonu

FPS optimizasyonu, profillemeyle başlayan ve sorunlu alanların yeniden düzenlenmesiyle biten sistematik bir yaklaşım gerektirir. İlk adım, bir profilleyiciyle mevcut FPS'yi ölçmektir. İkinci adım, bütçeyi aşan kareleri bulmaktır. Android'de bu, GPU Profiling veya Perfetto aracılığıyla yapılabilir. iOS'ta — Core Animation şablonuyla Instruments. Üçüncü adım, nedenleri ortadan kaldırmaktır: overdraw'ı azaltmak, View hiyerarşisi derinliğini azaltmak, layout aşamasını ConstraintLayout ile değiştirmek, ViewHolder Recycling eklemek ve ağır hesaplamaları bir arka plan iş parçacığına taşımak.

FPS'ye özgü optimizasyonlar şunları içerir: Frame Pacing — hızlı ve yavaş karelerin “patlamalarını” önlemek için kareler arasında zamanı eşit olarak dağıtan bir mekanizma. Android'de sabit aralıklı Choreographer.FrameCallback, Frame Pacing'i uygulamaya olanak tanır. iOS'ta CADisplayLink.preferredFrameRateRange aynı şeyi yapar. İkinci yöntem — Triple Buffering: sistem iki yerine üç arabellek kullanır ve GPU'nun önceki karenin serbest bırakılmasını beklemeden bir sonraki kareyi oluşturmaya başlamasına olanak tanır. Android gerektiğinde Triple Buffering'i otomatik olarak etkinleştirir, ancak iOS'ta geliştirici bunu CAMetalLayer aracılığıyla açıkça talep edebilir. Üçüncüsü — Texture Caching: her karede yeniden yüklemeyi önlemek için bitmap'leri GPU belleğinde önbelleğe alma.

Choreographer ile Frame Pacing

Bir Kotlin örneği, 16,6 ms'lik sabit bir aralıkla Frame Pacing uygulamasını gösterir. Sistem gecikse bile tüm geri aramalar tek biçimli bir aralıkta gelir.

class PacedFrameRenderer {

    private val targetDelta = 16_666_666L // 16.6 ms (60 FPS)
    private var lastFrameTime = 0L

    private val frameCallback =
        Choreographer.FrameCallback { frameTimeNanos ->
            val delta = frameTimeNanos - lastFrameTime
            if (delta >= targetDelta) {
                onFrame(delta)
                lastFrameTime = frameTimeNanos
            }
            Choreographer.getInstance()
                .postFrameCallback(this)
        }

    private fun onFrame(delta: Long) {
        // kare oluşturma
    }
}