মোবাইল অ্যাপে 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) মানক বিভিন্ন কারণে শিল্পে প্রতিষ্ঠিত হয়েছে। প্রথমটি শারীরবৃত্তীয়: মানুষের চ eye 50–60 Hz-এর উপরে ফ্রিকোয়েন্সিতে পৃথক ফ্রেম আলাদা করতে পারে না, সেগুলিকে মসৃণ গতি হিসেবে উপলব্ধি করে। এই সীমাকে Critical Flicker Fusion (CFF) বলা হয়। দ্বিতীয়টি ঐতিহাসিক: প্রাথমিক ক্যাথোড রে টিউব (CRT) USA (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-এ — 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) {
        // ফ্রেম রেন্ডারিং
    }
}