मोबाइल ऐप्स में FPS: सार, गणना और अनुकूलन

FPS क्या है

FPS (Frames Per Second) फ्रेम दर की माप की एक इकाई है जिसका उपयोग कंप्यूटर ग्राफिक्स, वीडियो और मोबाइल इंटरफ़ेस में किया जाता है। प्रत्येक फ्रेम एक स्थिर छवि है जो थोड़े समय के लिए स्क्रीन पर प्रदर्शित होती है। तेज़ फ्रेम परिवर्तनों के साथ, मस्तिष्क उन्हें निरंतर गति के रूप में मानता है — इस प्रभाव को दृष्टि की दृढ़ता कहा जाता है। मोबाइल ऐप्स के लिए, FPS एक महत्वपूर्ण मीट्रिक है क्योंकि कोई भी छूटा हुआ फ्रेम एक स्मूथ एनिमेशन को ध्यान देने योग्य हकलाहट में बदल देता है। एप्लिकेशन को प्रत्येक फ्रेम को समय बजट के भीतर सख्ती से रेंडर करना चाहिए: 60 FPS के लिए 16.6 ms, 90 FPS के लिए 11.1 ms, 120 FPS के लिए 8.3 ms।

FPS न केवल UI के लिए बल्कि गेम, वीडियो और कैमरे के लिए भी मापा जाता है। गेम में, FPS दृश्य की जटिलता, बनावट की गुणवत्ता और GPU की शक्ति पर निर्भर करता है। वीडियो में, FPS निश्चित (24, 30, 60 fps) होता है और सामग्री द्वारा निर्धारित किया जाता है। मोबाइल ऐप्स में, FPS UI कोड की दक्षता पर निर्भर करता है: लेआउट की जटिलता, व्यूज़ की संख्या, पुनः ड्रॉ की आवृत्ति और GC (Garbage Collection) कार्य। Apple WWDC 2022 के अनुसार, अकुशल संग्रह अपडेट (insert/delete/dequeueReusableCell के बजाय reloadData) के कारण एप्लिकेशन में औसत FPS 10–15% तक गिर सकता है। वास्तविक समय में FPS मापना प्रदर्शन पर काम करने वाले QA इंजीनियरों और डेवलपर्स के लिए मानक अभ्यास है।

FPS की गणना कैसे की जाती है

मोबाइल एप्लिकेशन में FPS की गणना लगातार फ्रेम के बीच के समय को मापने पर आधारित है। सबसे सरल सूत्र: FPS = 1000 / deltaTimeMs, जहाँ deltaTimeMs पिछले फ्रेम के पूरा होने और वर्तमान फ्रेम के पूरा होने के बीच का अंतराल है। यदि वर्तमान फ्रेम 20 ms में रेंडर किया गया था, FPS = 1000 / 20 = 50। हालाँकि, व्यवहार में, FPS एक सेकंड के भीतर भी शायद ही कभी स्थिर होता है: एक विशिष्ट प्रोफ़ाइल में 12–16 ms के फ्रेम शामिल होते हैं जो छूटे हुए (jank) या धीमे फ्रेम (40–60 ms) के साथ मिश्रित होते हैं। इसलिए, FPS को 1–5 सेकंड में चलती औसत के रूप में या फ्रेम समय वितरण के प्रतिशतक के रूप में मापा जाता है।

Android पर, FPS की गणना Choreographer के माध्यम से की जाती है, जो VSync (डिस्प्ले सिंक्रनाइज़ेशन पल्स) से कॉलबैक प्राप्त करता है। प्रत्येक कॉलबैक एक फ्रेम से मेल खाता है। यदि कॉलबैक नहीं आता है — फ्रेम छोड़ दिया जाता है। Choreographer प्रति सेकंड फ्रेम की सटीक संख्या और छूटे हुए फ्रेम की संख्या मापने की अनुमति देता है। iOS पर, CADisplayLink समान रूप से काम करता है — यह हर बार कॉल किया जाता है जब डिस्प्ले एक नया फ्रेम रेंडर करने के लिए तैयार होता है। timestamp प्रॉपर्टी में अंतिम फ्रेम का सटीक समय होता है, और targetTimestamp — अगले फ्रेम का अपेक्षित समय। उनके बीच का अंतर वर्तमान फ्रेम के लिए समय बजट है।

CADisplayLink के माध्यम से FPS निगरानी

Swift कोड CADisplayLink के माध्यम से सरल FPS निगरानी प्रदर्शित करता है। frameCount काउंटर प्रत्येक कॉल के साथ बढ़ता है, और सेकंड में एक बार वास्तविक FPS की गणना की जाती है।

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
        }
    }
}

60 FPS मानक क्यों है

60 FPS (या 60 Hz) मानक कई कारणों से उद्योग में स्थापित हुआ। पहला शारीरिक है: मानव आँख 50–60 Hz से ऊपर की आवृत्तियों पर अलग-अलग फ्रेम को भेद नहीं करती है, उन्हें स्मूथ गति के रूप में मानती है। इस सीमा को Critical Flicker Fusion (CFF) कहा जाता है। दूसरा ऐतिहासिक है: प्रारंभिक कैथोड रे ट्यूब (CRT) US (NTSC) में 60 Hz और यूरोप (PAL) में 50 Hz पर संचालित होते थे। आधुनिक LCD डिस्प्ले ने इस आवृत्ति को विरासत में लिया। तीसरा इंजीनियरिंग है: UI एनिमेशन के लिए, 60 FPS सब-मिलीसेकंड टच रिस्पॉन्स विलंबता प्रदान करता है, जो टेक्स्ट इनपुट, स्क्रॉलिंग और ड्रैगिंग के लिए महत्वपूर्ण है।

मोबाइल डेवलपर्स के लिए, 60 FPS केवल एक अनुशंसा नहीं है बल्कि प्रति फ्रेम 16.6 ms का एक सख्त बजट है। यह बजट रेंडरिंग के सभी चरणों के बीच विभाजित होता है: इनपुट (1–2 ms), एनिमेशन (2–3 ms), लेआउट (3–5 ms), ड्रा (3–5 ms), और स्वैप (1–2 ms)। यदि कोई चरण अपने उप-बजट से अधिक हो जाता है, तो फ्रेम 16.6 ms के भीतर फ़िट नहीं हो सकता है। Google Android Performance फ्रेम तैयारी के लिए 12–14 ms के भीतर रहने की सिफारिश करता है, सिस्टम इंटरप्शन (GC, बैकग्राउंड थ्रेड) के लिए 2–4 ms का हेडरूम छोड़ता है। Firebase Performance के अनुसार, 52 से कम औसत FPS और 30 से कम P99 FPS वाले ऐप्स को Google Play समीक्षाओं में 35% अधिक प्रदर्शन शिकायतें मिलती हैं।

FPS और फ्रेम टाइम: संबंध

FPS और फ्रेम टाइम एक ही मीट्रिक के दो पहलू हैं, और उन्हें भ्रमित नहीं करना महत्वपूर्ण है। FPS गति है, फ्रेम टाइम विलंबता है। 60 FPS पर, प्रत्येक फ्रेम 16.6 ms लेता है। 30 FPS पर — 33.3 ms। लेकिन FPS एक गैर-रैखिक मीट्रिक है: 60 से 30 FPS तक की गिरावट का मतलब है कि फ्रेम का समय दोगुना हो गया, जबकि 30 से 20 तक की गिरावट का मतलब 1.5 गुना वृद्धि है। इसलिए, प्रोफ़ाइलर औसत आवृत्ति के बजाय फ्रेम टाइम दिखाते हैं — यह समस्याग्रस्त फ्रेम को देखने की अनुमति देता है। उदाहरण के लिए, 55 FPS का औसत इस तथ्य को छिपा सकता है कि 5% फ्रेम का फ्रेम टाइम 50–100 ms है — ये फ्रेम Jank का कारण बनते हैं लेकिन औसत FPS को महत्वपूर्ण रूप से प्रभावित नहीं करते हैं।

प्रदर्शन का विश्लेषण करते समय, औसत FPS के बजाय फ्रेम टाइम हिस्टोग्राम को देखने की सिफारिश की जाती है। Android Studio Profiler और iOS Instruments में, फ्रेम टाइम को एक पैमाने के रूप में प्रदर्शित किया जाता है जहाँ हरा क्षेत्र 16.6 ms (60 FPS) तक, पीला 16.6–33.3 ms (30–60 FPS), लाल 33.3 ms से अधिक (30 FPS से कम) होता है। प्रत्येक लाल कॉलम उपयोगकर्ता के लिए ध्यान देने योग्य अंतराल है। एक व्यावहारिक नियम: P95 फ्रेम टाइम (95% फ्रेम X ms में फ़िट होते हैं) औसत FPS की तुलना में अधिक विश्वसनीय मीट्रिक है। यदि P95 फ्रेम टाइम 32 ms (30 FPS) से अधिक है, तो एप्लिकेशन 50 के औसत FPS के साथ भी सुस्त महसूस होता है।

फ्रेम टाइम को FPS में परिवर्तित करना

प्रतिशतक के साथ फ्रेम समय की सरणी को FPS में परिवर्तित करने के लिए Kotlin फ़ंक्शन। यह विस्तृत विश्लेषण के लिए न केवल औसत FPS बल्कि P50, P90 और P99 भी लौटाता है।

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)]
    )
}

उच्च FPS और नए डिस्प्ले

90, 120 और 144 Hz डिस्प्ले वाले आधुनिक मोबाइल उपकरण FPS पर नई आवश्यकताएँ लगाते हैं। यदि कोई एप्लिकेशन 120 Hz डिस्प्ले पर 60 FPS देता है, तो उपयोगकर्ता माइक्रो-हकलाहट देखता है क्योंकि स्क्रीन रिफ्रेश का हर दूसरा चक्र समान फ्रेम प्राप्त करता है। 120 FPS बनाए रखने के लिए, प्रति-फ्रेम बजट 16.6 से 8.3 ms तक सिकुड़ जाता है — जिसके लिए दोगुना कुशल रेंडरिंग कोड की आवश्यकता होती है। Android डेवलपर्स (Google I/O 2023) के अनुसार, स्थिर 120 FPS प्राप्त करने के लिए आवश्यक है: ड्रा चक्र में आवंटन से बचना, पदानुक्रम में व्यूज़ की संख्या को कम करना (80 से कम), VectorDrawable के पक्ष में भारी drawable को छोड़ना, और जटिल ग्राफिक्स के लिए surfaceView का उपयोग करना।

iOS पर स्थिति समान है: iPhone Pro ProMotion (120 Hz) के साथ दोगुने फ्रेम की आवश्यकता होती है, लेकिन प्रति फ्रेम का समय आधा हो जाता है। Apple नोट करता है कि सभी एनिमेशन को 120 FPS पर चलने की आवश्यकता नहीं है — Core Animation स्वचालित रूप से स्थिर या धीरे-धीरे बदलने वाले तत्वों के लिए फ्रेम दर कम कर देता है। हालाँकि, स्क्रॉलिंग, जेस्चर एनिमेशन और ट्रांज़िशन को ‛रेशमी“ अनुभव के लिए 120 FPS देना चाहिए। 60 से 120 FPS में संक्रमण करते समय मुख्य समस्याएँ: बढ़ी हुई बिजली खपत (GPU के लिए 25–40%), डिवाइस हीटिंग और थ्रॉटलिंग — जब ओवरहीटिंग के कारण फ्रेम दर गिर जाती है। एक फ़ॉलबैक तंत्र लागू करने की सिफारिश की जाती है: यदि फ्रेम टाइम लगातार 8.3 ms से अधिक है, तो सिस्टम थ्रॉटलिंग की प्रतीक्षा करने के बजाय प्रोग्रामेटिक रूप से लक्ष्य फ्रेम दर को 60 FPS तक कम करें।

60/120 FPS स्विचर

Android के लिए Java कोड यह निर्धारित करता है कि डिवाइस 120 FPS का समर्थन कर सकता है या नहीं और रेंडरिंग मोड को स्विच करता है। समर्थित रिफ्रेश दरों को निर्धारित करने के लिए Display.getMode का उपयोग किया जाता है।

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;
    }
}

एप्लिकेशन में FPS अनुकूलन

FPS को अनुकूलित करने के लिए एक व्यवस्थित दृष्टिकोण की आवश्यकता होती है, जो प्रोफाइलिंग से शुरू होता है और समस्या क्षेत्रों के रिफैक्टरिंग पर समाप्त होता है। पहला कदम प्रोफाइलर का उपयोग करके वर्तमान FPS को मापना है। दूसरा कदम उन फ्रेम को ढूंढना है जो बजट से अधिक हैं। Android पर, यह GPU Profiling या Perfetto के माध्यम से किया जा सकता है। iOS पर — Instruments Core Animation टेम्पलेट के साथ। तीसरा कदम कारणों को समाप्त करना है: overdraw कम करें, व्यू पदानुक्रम की गहराई कम करें, लेआउट चरण को ConstraintLayout से बदलें, ViewHolder Recycling जोड़ें, भारी गणनाओं को बैकग्राउंड थ्रेड में ले जाएँ।

विशिष्ट FPS अनुकूलन में शामिल हैं: Frame Pacing — एक तंत्र जो तेज़ और धीमे फ्रेम के ‛विस्फोट“ से बचने के लिए फ्रेम के बीच समय को समान रूप से वितरित करता है। Android पर, Choreographer.FrameCallback एक निश्चित अंतराल के साथ Frame Pacing को लागू करने की अनुमति देता है। iOS पर, CADisplayLink.preferredFrameRateRange ऐसा ही करता है। दूसरी विधि — Triple Buffering: सिस्टम दो के बजाय तीन बफ़र का उपयोग करता है, जिससे GPU पिछले फ्रेम के जारी होने की प्रतीक्षा किए बिना अगला फ्रेम रेंडर करना शुरू कर सकता है। Android आवश्यकता पड़ने पर स्वचालित रूप से Triple Buffering को सक्षम करता है, लेकिन iOS के लिए डेवलपर CAMetalLayer के माध्यम से स्पष्ट रूप से इसका अनुरोध कर सकता है। तीसरा — Texture Caching: प्रत्येक फ्रेम पर उन्हें पुनः लोड करने से बचने के लिए GPU मेमोरी में बिटमैप को कैश करना।

Choreographer के माध्यम से Frame Pacing

एक Kotlin उदाहरण 16.6 ms के निश्चित अंतराल के साथ Frame Pacing को लागू करने का प्रदर्शन करता है। सिस्टम में देरी होने पर भी सभी कॉलबैक एक समान अंतराल पर आते हैं।

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) {
        // फ्रेम रेंडरिंग
    }
}