موبائل ایپس میں 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) امریکہ (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 سے کم)، بھاری drawable کو VectorDrawable کے حق میں ترک کریں، اور پیچیدہ گرافکس کے لیے 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 پر — Core Animation ٹیمپلیٹ کے ساتھ Instruments۔ تیسرا قدم وجوہات کو ختم کرنا ہے: 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) {
        // فریم رینڈرنگ
    }
}