موبائل ایپلی کیشنز میں فریم ریٹ — یہ کیا ہے، fps اور اسے کیسے بہتر بنایا جائے

فریم ریٹ کیا ہے

فریم ریٹ (فریم کی شرح) ایک میٹرک ہے جسے فریم فی سیکنڈ (fps) میں ماپا جاتا ہے اور یہ ظاہر کرتا ہے کہ ایک ایپلیکیشن فی سیکنڈ کتنی بار اسکرین پر تصویر کو اپ ڈیٹ کرتی ہے۔ انسانی آنکھ 24 fps (سنیما) سے حرکت کو ہموار سمجھتی ہے، لیکن انٹرایکٹو UI کے لیے کم از کم 60 fps کی ضرورت ہوتی ہے تاکہ ٹچ اور اینیمیشنز فوری محسوس ہوں۔ ہر فریم ایک مکمل چکر ہے: صارف کے ان پٹ کی پروسیسنگ، لے آؤٹ کا حساب، ویو کے درجہ بندی کی رینڈرنگ اور اسکرین پر آؤٹ پٹ۔ اگر ان میں سے کوئی بھی مرحلہ مختص کردہ وقت کے بجٹ (60 fps پر 16.6 ملی سیکنڈ) سے تجاوز کر جائے تو فریم چھوٹ جاتا ہے اور صارف جھٹکا دیکھتا ہے۔

ایپلیکیشن کے فریم ریٹ اور ڈسپلے کے ریفریش ریٹ کے درمیان فرق کرنا ضروری ہے۔ ریفریش ریٹ اسکرین کی ایک ہارڈویئر خصوصیت ہے: ڈسپلے فی سیکنڈ کتنی بار تصویر کو جسمانی طور پر اپ ڈیٹ کرتا ہے (60، 90، 120 یا 144 Hz)۔ فریم ریٹ یہ ہے کہ ایپلیکیشن فی سیکنڈ کتنے فریم رینڈر کر سکتی ہے۔ اگر ایپلیکیشن 120 Hz ڈسپلے پر 60 fps آؤٹ پٹ کرتی ہے، تو ہر دوسرا فریم ڈپلیکیٹ ہو جائے گا — تصویر ہموار رہے گی لیکن اتنی رد عمل نہیں ہوگی جتنی ہو سکتی تھی۔ Google I/O 2023 کے مطابق، جدید فلیگ شپ سادہ UI منظرناموں میں 120 fps برقرار رکھ سکتے ہیں، لیکن بھاری بوجھ (گیمز، پیچیدہ فہرستیں) کے تحت شرح 40–60 fps تک گر جاتی ہے۔

فریم رینڈرنگ کیسے کام کرتی ہے

موبائل ایپلیکیشن میں فریم رینڈرنگ کئی مراحل کی پائپ لائن سے گزرتی ہے۔ Android میں، پائپ لائن میں شامل ہیں: ان پٹ پروسیسنگ (Input)، اینیمیشن (Animation)، پیمائش اور ترتیب (Layout)، ڈرائنگ (Draw)، GPU سنکرونائزیشن اور اسکرین آؤٹ پٹ (Swap)۔ ہر مرحلہ CPU یا GPU پر چلتا ہے، اور تمام مراحل کا کل وقت فریم بجٹ سے تجاوز نہیں کرنا چاہیے۔ 60 fps کے لیے بجٹ 16.6 ملی سیکنڈ ہے، 120 fps کے لیے — 8.3 ملی سیکنڈ۔ Choreographer (Android) اور CADisplayLink (iOS) ڈسپلے کے عمودی خالی وقفہ (VSync) کے ساتھ رینڈرنگ کو ہم آہنگ کرتے ہیں، اس بات کو یقینی بناتے ہوئے کہ فریم صرف اسکرین ریفریش کے لمحے میں آؤٹ پٹ ہو، ٹیئرنگ سے بچتے ہوئے۔

iOS میں، پائپ لائن ایک جیسی ہے: Run Loop ایونٹس کو پروسیس کرتا ہے، Core Animation لیئرز کا حساب لگاتا ہے، Render Server (ایک علیحدہ عمل) رینڈر کرتا ہے اور فریم کو GPU بھیجتا ہے۔ iOS میں فرق وقف شدہ Render Server عمل ہے، جو رینڈرنگ کو مرکزی ایپلیکیشن سے الگ کرتا ہے۔ اگر ایپلیکیشن مرکزی تھریڈ کو بلاک کرتی ہے، تو Render Server پھر بھی آخری معلوم فریم کھینچ سکتا ہے، لیکن اینیمیشنز رک جائیں گی۔ اگر Render Server خود رفتار برقرار نہیں رکھ سکتا — تو GPU بیکار ہو جاتا ہے اور فریم ریٹ گر جاتا ہے۔ Apple WWDC 2022 کے مطابق، iOS میں کم فریم ریٹ کی سب سے عام وجوہات CALayer کی ضرورت سے زیادہ نیسٹنگ، بھاری shadowPath اور آف اسکرین رینڈرنگ ہیں۔

Choreographer کے ذریعے فریم ٹریکنگ

Kotlin کوڈ Choreographer.FrameCallback کو سبسکرائب کرتا ہے اور فریموں کے درمیان حقیقی وقت لاگ کرتا ہے۔ اگر وقفہ 16.6 ملی سیکنڈ سے تجاوز کر جائے تو چھوٹا ہوا فریم ریکارڈ کیا جاتا ہے۔

class FrameRateMonitor {

    private var lastFrameTime = 0L
    private val frameCallback =
        Choreographer.FrameCallback { frameTimeNanos ->
            if (lastFrameTime != 0L) {
                val deltaMs = (frameTimeNanos - lastFrameTime) / 1_000_000f
                if (deltaMs > 16.6f) {
                    Log.w("FrameRate",
                        "Skipped frame: $deltaMs ms")
                }
            }
            lastFrameTime = frameTimeNanos
            Choreographer.getInstance()
                .postFrameCallback(this)
        }

    fun start() {
        Choreographer.getInstance()
            .postFrameCallback(frameCallback)
    }
}

ڈسپلے ریفریش ریٹ اور فریم ریٹ

ریفریش ریٹ ڈسپلے کی ایک ہارڈویئر خصوصیت ہے جو یہ طے کرتی ہے کہ اسکرین فی سیکنڈ کتنی بار تصویر کو جسمانی طور پر دوبارہ کھینچتی ہے۔ معیاری ڈسپلے میں 60 Hz ہوتا ہے، جدید فلیگ شپ میں 90، 120 یا 144 Hz۔ ایپلیکیشن کا فریم ریٹ ریفریش ریٹ سے کم، برابر یا زیادہ ہو سکتا ہے (آخری صورت میں، اضافی فریم ضائع کر دیے جاتے ہیں)۔ مثالی منظر نامہ وہ ہے جب فریم ریٹ ریفریش ریٹ سے مماثل ہو: ہر ہارڈویئر سائیکل کو ایپلیکیشن سے ایک نیا فریم ملتا ہے اور حرکت زیادہ سے زیادہ ہموار ہوتی ہے۔ اگر فریم ریٹ کم ہے تو ڈسپلے آخری فریم کو دہراتا ہے، جسے مائیکرو جھٹکے کے طور پر محسوس کیا جاتا ہے۔

Android اور iOS ڈائنامک ریفریش ریٹ سوئچنگ کو سپورٹ کرتے ہیں۔ Android 12+ Smart Refresh Rate استعمال کرتا ہے: اسکرول کرتے وقت سسٹم شرح 120 Hz تک بڑھا دیتا ہے، جامد مواد پر بیٹری بچانے کے لیے 60 Hz تک کم کر دیتا ہے۔ iOS ProMotion (iPhone 13 Pro اور نئے) اسی طرح کام کرتا ہے — مواد کے لحاظ سے شرح 10 سے 120 Hz کے درمیان مختلف ہوتی ہے۔ ڈویلپر کو چیک کرنا چاہیے کہ آیا آلہ زیادہ شرح کو سپورٹ کرتا ہے اور فی فریم وقت کے بجٹ کو ڈھالنا چاہیے۔ اگر ایپلیکیشن 8.3 ملی سیکنڈ (120 Hz کے لیے) میں فریم رینڈر نہیں کر سکتی، تو 60 Hz کو مجبور کرنا بہتر ہے — یہ چھوٹے ہوئے فریموں کے بغیر ایک مستحکم فریم ریٹ کو یقینی بنائے گا۔

فریم ریٹ پیمائش کے اوزار

موبائل ایپلیکیشنز میں فریم ریٹ کی پیمائش کے لیے پلیٹ فارم کے بلٹ ان ٹولز اور تھرڈ پارٹی پروفائلرز دونوں دستیاب ہیں۔ Android میں، بنیادی ٹول GPU Profiling (Developer Options → Profile GPU Rendering) ہے، جو ہر فریم کو مراحل (Draw, Prepare, Process, Execute) میں تقسیم شدہ ٹائم لائن دکھاتا ہے۔ زیادہ تفصیلی تجزیہ Android Studio Profiler فراہم کرتا ہے — یہ دوبارہ ڈرائنگ کا سبب بننے والے مخصوص ویوز کی نشاندہی کرتے ہوئے ایک مکمل رینڈرنگ پروفائل ریکارڈ کرتا ہے۔ iOS میں، Core Animation ٹیمپلیٹ کے ساتھ Instruments استعمال کیا جاتا ہے — یہ FPS، لیئر رینڈرنگ کا وقت اور آف اسکرین رینڈرز کی تعداد دکھاتا ہے۔

پروڈکشن فریم ریٹ مانیٹرنگ کے لیے، Firebase Performance (Android) استعمال کیا جاتا ہے — یہ پس منظر میں فریم ریٹ جمع کرتا ہے اور آلہ، OS ورژن اور سیشن کے مطابق جمع کرتا ہے۔ iOS میں، MetricKit MXAnimatoryMetric کے ذریعے اسی طرح کا ڈیٹا فراہم کرتا ہے۔ گیمز اور Flutter ایپلیکیشنز کے لیے، FrameTimingCallback (Flutter) اور Unity Profiler استعمال کیا جاتا ہے۔ اوسط فریم ریٹ نہیں بلکہ پرسنٹائل (P50، P90 اور P99) کی پیمائش کرنا ضروری ہے۔ ایک ایپلیکیشن اوسط 55 fps دکھا سکتی ہے لیکن اس کا P99 = 30 fps ہو سکتا ہے — اس کا مطلب ہے کہ 1% وقت صارفین شدید جھٹکے دیکھتے ہیں، جو منفی جائزوں کے لیے کافی ہے۔

Flutter میں فریم ریٹ کی پیمائش

Dart مثال ظاہر کرتی ہے کہ Flutter میں FrameTimingCallback کو کیسے سبسکرائب کیا جائے اور چھوٹے ہوئے فریموں کی تعداد کیسے لاگ کی جائے۔ کال بیک ہر مکمل فریم کے بعد فائر ہوتا ہے۔

import 'package:flutter/scheduler.dart';

class FrameRateLogger {
    int totalFrames = 0;
    int missedFrames = 0;

    void start() {
        SchedulerBinding.instance
            .addTimingsCallback(_onReportTimings);
    }

    void _onReportTimings(List<FrameTiming> timings) {
        for (final timing in timings) {
            totalFrames++;
            if (timing.totalSpan()
                > Duration(milliseconds: 16)) {
                missedFrames++;
            }
        }
        debugPrint("FPS: \${totalFrames - missedFrames}");
    }
}

فریم کی شرح کی اصلاح

فریم ریٹ کی اصلاح رینڈرنگ پائپ لائن میں رکاوٹوں کی نشاندہی سے شروع ہوتی ہے۔ لے آؤٹ مرحلے میں، اہم مسائل ویو کے درجہ بندی کی ضرورت سے زیادہ نیسٹنگ، رلیٹیو لے آؤٹ (بہت سے قواعد کے ساتھ RelativeLayout) کا استعمال اور بار بار requestLayout کالز ہیں۔ حل — ConstraintLayout یا فلیٹ درجہ بندی کا استعمال، 5–6 سطحوں سے زیادہ نیسٹنگ سے بچنا۔ ڈرا مرحلے میں — overdraw: جب ایک پکسل فی فریم کئی بار کھینچا جاتا ہے۔ مثال کے طور پر، ایک نیم شفاف فریگمنٹ کے نیچے سفید Activity پس منظر، جس کے نیچے ایک اور پرت — ہر پکسل تین بار کھینچا جاتا ہے۔ Debug GPU Overdraw ٹول رنگین اشارے کے ساتھ مسئلہ والے علاقے دکھاتا ہے۔ overdraw کو 2x یا اس سے کم رکھنے کی سفارش کی جاتی ہے۔

iOS میں، اہم مسائل بھاری cornerRadius اور masksToBounds ہیں — یہ آف اسکرین رینڈرنگ کا سبب بنتے ہیں، جہاں Core Animation ایک عارضی بفر بناتا ہے، اس میں کھینچتا ہے، پھر نتیجہ کو اسکرین پر کاپی کرتا ہے۔ آف اسکرین رینڈرنگ Instruments Core Animation میں آسانی سے دیکھی جا سکتی ہے: اگر Renderer لائن سرخ ہے — مسائل ہیں۔ حل — cornerRadius کے بجائے پہلے سے کٹی ہوئی تصاویر کے ساتھ UIImageView استعمال کرنا، جب تک بالکل ضروری نہ ہو groupOpacity اور shouldRasterize سے بچنا۔ دونوں پلیٹ فارمز کے لیے، invalidate() اور setNeedsDisplay() کالز کی تعداد کو کم سے کم کرنا ضروری ہے — ایسی ہر کال ایک مکمل ویو دوبارہ ڈرائنگ سائیکل شروع کرتی ہے۔

Android میں درجہ بندی کی اصلاح

کوڈ گہری RelativeLayout نیسٹنگ کو فلیٹ ConstraintLayout ڈھانچے سے تبدیل کرنے کا مظاہرہ کرتا ہے۔ نیسٹنگ لیول کو 4 سے کم کرکے 1 کرنے سے لے آؤٹ کا وقت 30–50% کم ہو جاتا ہے۔

// مثال: ConstraintLayout کے ذریعے فلیٹ ساخت
class OptimizedView(context: Context) :
    ConstraintLayout(context) {

    private val binding =
        ItemProfileBinding.inflate(
            LayoutInflater.from(context)
        )

    fun bind(user: User) {
        binding.avatar.setImageURI(user.avatarUrl)
        binding.nameText.text = user.name
        // پورے کنٹینر کو دوبارہ کھینچے بغیر ڈیٹا بائنڈ کرنا
    }
}

انطباقی تعدد اور ڈائنامک فریم ریٹ

جدید موبائل ایپلیکیشنز تیزی سے انطباقی فریم ریٹ استعمال کر رہی ہیں — ایک نظام جو موجودہ منظر نامے کے مطابق ہدف کی تعدد کو متحرک طور پر ایڈجسٹ کرتا ہے۔ تیز اسکرولنگ کو ہمواری کے لیے 120 fps کی ضرورت ہوتی ہے، جبکہ ایک جامد اسکرین کو صرف 60 fps یا ویڈیو کے لیے 30 fps کی ضرورت ہوتی ہے۔ Android میں، انطباق Choreographer.setFrameInterval (API 33+) اور Window.setFrameRate کے ذریعے لاگو کیا جاتا ہے۔ ڈویلپر ترجیحی تعدد بتا سکتا ہے: SurfaceView میں setPreferredRefreshRate یا Window میں setFrameRate۔ iOS ProMotion کے ذریعے خود بخود تعدد کا انتظام کرتا ہے، لیکن ڈویلپر CADisplayLink کے لیے واضح طور پر preferredFramesPerSecond سیٹ کر سکتا ہے۔

ڈائنامک فریم ریٹ خاص طور پر گیمز اور اینیمیشن والی ایپلیکیشنز کے لیے اہم ہے۔ Google کے مطابق، جامد اسکرین پر فریم ریٹ کو 120 سے 60 Hz تک کم کرنے سے GPU توانائی کا 30–40% تک بچت ہوتی ہے۔ ہمواری اور بجلی کی کھپت کے درمیان بہترین توازن حاصل کرنے کے لیے سفارش کی جاتی ہے: مختلف منظرناموں میں حقیقی فریم ریٹ کی پیمائش کریں، منظر کے لحاظ سے ہدف fps سیٹ کریں (گیم — 60، مینو — 30، ویڈیو — 24)، اور Lifecycle-aware اجزاء کے ذریعے موڈز کو سوئچ کریں تاکہ ایپلیکیشن چھوٹی ہونے پر پس منظر میں 120 fps رینڈر کرنے میں وسائل ضائع نہ کرے۔

ترجیحی فریم ریٹ سیٹ کرنا

Swift کوڈ iOS میں CADisplayLink کے لیے preferredFramesPerSecond سیٹ کرتا ہے۔ اسکرول کرتے وقت شرح 120 Hz تک بڑھ جاتی ہے، رکنے پر 60 Hz تک کم ہو جاتی ہے۔

class AdaptiveFrameRateManager {

    private var displayLink: CADisplayLink?

    func startWithHighRate() {
        displayLink = CADisplayLink(
            target: self,
            selector: #selector(step)
        )
        if #available(iOS 15.0, *) {
            displayLink?.preferredFrameRateRange =
                CAFrameRateRange(
                    minimum: 60,
                    maximum: 120,
                    preferred: 120
                )
        }
        displayLink?.add(to: .current,
            forMode: .common)
    }

    @objc
    private func step() {
        // اینیمیشن اپ ڈیٹ
    }
}