মোবাইল ডেভেলপমেন্টে Performance Test: এটি কী, মেট্রিক্স এবং কিভাবে করা হয়

Performance Test কী?

Performance Test হল এক ধরনের অনাফংশনাল টেস্টিং যা নির্ধারণ করে যে একটি অ্যাপ্লিকেশন কত দ্রুত এবং দক্ষতার সাথে তার কাজ সম্পাদন করে। ইউনিট টেস্ট বা UI টেস্টের বিপরীতে, Performance Test পরিমাণগত বৈশিষ্ট্য পরিমাপ করে: প্রতিক্রিয়া সময়, CPU লোড, RAM ব্যবহার এবং ব্যাটারি ব্যবহার। Sauce Labs প্রতিবেদন (2025) অনুযায়ী, 68% মোবাইল ডেভেলপমেন্ট টিম Performance Test তাদের নিয়মিত টেস্টিং চক্রে অন্তর্ভুক্ত করে, এবং 41% এটি CI এ স্বচালিত করে।

Performance Test এর প্রধান লক্ষ্য হল নিশ্চিত করা যে অ্যাপ্লিকেশন ডকুমেন্টেশনে উল্লিখিত পারফরম্যান্স আবশ্যকতা পূরণ করে। যদি স্ক্রিন লোন্চ সময় 500 মিলিসেকেন্ড অতিক্রম করে বা অ্যাপ্লিকেশন একটি মাঝারি ডিভাইসে 200 MB এর বেশি RAM ব্যবহার করে, তা হল অপ্টিমাইজেশনের একটি সংস্কার। বেসলাইন পারফরম্যান্স প্রথম স্থির রিলিজ়ে স্থাপন করা হয় এবং প্রতিটি বড় হালনাগাড়ীর সাথে পুনরাভব পর্যালোচনা করা হয়।

Performance Test বাস্তব ডিভাইসে করা হয়, সিমুলেটরে নয়, কারণ এমুলেশন CPU, GPU এবং নেটওয়ার্ক রিসোর্স ব্যবহারের সঠিক চিত্র দেয় না। Apple WWDC (2024) অনুযায়ী, সিমুলেটরে টেস্ট বাস্তব ডিভাইসের তুলনায় 15–30% বেশি ফলাফল দেখায়। একটি বাস্তব ডিভাইস পারফরম্যান্স ডেটার একমাত্র বিশ্বসনীয় উৎস হিসেবে রয়েছে।

Performance Test করার ফ্রিকোয়েন্সি ডেভেলপমেন্ট চক্রের উপর নির্ভর করে। Google Android Performance সুপারিশ (2024) অনুযায়ী, বেসলাইন পরিমাপ প্রতিটি pull request এ চালানো উচিত, এবং একটি পূর্ণ সুট প্রতিটি রিলিজ়ের আগে চালানো উচিত। এই পরিমাপগুলির অটোমেশন প্রারম্ভিক পর্যায়ে পারফরম্যান্স রিগ্রেশন শনাক্ত করতে সাহায্য করে।

প্রধান পারফরম্যান্স মেট্রিক্স

মোবাইল ডেভেলপমেন্টে পাঁচটি প্রধান মেট্রিক্স চিহ্নিত করা হয়েছে যা Performance Test এর 90% পরিদৃশ্য আবরণ করে। লোন্চ সময় (cold start এবং warm start) হল প্রথম মেট্রিক যা প্রতিটি রিলিজ়ে পরীক্ষা করা হয়। Google Play Console (2024) সীমানুযায়ী লোন্চ সময় রিকর্ড করে: cold start 5 সেকেন্ডের বেশি হওয়া উচিত নয়, warm start — 1.5 সেকেন্ড। এই সীমাগুলি অতিক্রম করা সরাসরি অ্যাপ্সটোর রেটিংয়ে প্রভাব ফেলে।

লোন্চ সময় (Cold Start)

Cold start আইকনে ট্যাপ করার মুহূর্ত থেকে অ্যাপ্লিকেশনের প্রথম ফ্রেম আবির্ভাব পর্যন্ত পরিমাপ করা হয়। iOS বিলম্বিত আরম্ভিকরণের জন্য `dispatch_async` ব্যবহার করে, যা দৃশ্য লোন্চ সময় হ্রাস করে। Android cold start প্রক্রিয়া তৈরি, Application আরম্ভিকরণ এবং Activity লোন্চ অন্তর্ভুক্ত করে। Google Performance (2024) অনুযায়ী, cold start এ প্রতি 100 মিলিসেকেন্ড বিলম্ব ঈ-কমার্স অ্যাপ্লিকেশনে Conversion Rate 1.2% কমিয়ে দেয়।

ফ্রেম হার (FPS)

FPS (Frames Per Second) এনিমেশন এবং তালিকা স্ক্রোলিংয়ের সময় ফ্রেম হার। একটি মসৃণ ইন্টারফেসের জন্য স্থির 60 FPS প্রয়োজন। Android Studio Profiler এবং Xcode GPU Report ভারী কাজের সময় FPS পতন দেখায় — ইমেজ লোডিং, JSON পার্সিং বা জটিল লেআউট রেন্ডারিং। 30 FPS এর নীচে পতন ব্যবহারকারী ল্যাগ হিসেবে অনুভব করে এবং Adjust (2025) অনুযায়ী Retention Rate 22% কমিয়ে দেয়।

RAM ব্যবহার

RAM ব্যবহার তৃতীয় গুরুত্বপূর্ণ মেট্রিক। মেমরি লিক দীর্ঘ সেশনে পারফরম্যান্স অবনতির প্রধান কারণ। Instruments Allocations এবং Android Memory Profiler Swift এ বৃত্তিক রেফারেন্স এবং Android এ মুক্ত না করা Activity শনাক্ত করতে সাহায্য করে। ব্যাটারি ব্যবহার একটি মেট্রিক যা প্রায়ই টেস্টিংয়ের সময় অবহেলা করা হয়। Apple Developer (2024) অনুযায়ী, উচ্চ শক্তি ব্যবহারের অ্যাপ্লিকেশন iOS এ পেশকাই সীমাবদ্ধ হয়। Xcode এ Energy Log প্রতি সেশন অ্যাপ্লিকেশনের ওয়াটেজ প্রোফাইল রিকর্ড করে।

পারফরম্যান্স টেস্টিংয়ের প্রকার

লোড টেস্ট প্রত্যাশিত সমসাময়িক ব্যবহারকারীর সংখ্যার আধারে অ্যাপ্লিকেশনের আচরণ পরীক্ষা করে। একটি মোবাইল ব্যাকএন্ডের জন্য, এর অর্থ 1000–10000 সমসাময়িক API অনুরোধের অনুকরণ। সার্ভার পাশ উল্লেখযোগ্য মান হিসাবে বেস মানের থেকে 20% বেশি প্রতিক্রিয়া সময় বাড়ার বিনা পীক লোড সামাল করা উচিত। k6 বেঞ্চমার্ক (2024) অনুযায়ী, একটি সাধারণ Load Test কনফিগরেশনে 5 মিনিটে 0 থেকে 1000 VUs (ভার্চুয়াল ব্যবহারকারী) পর্যন্ত একটি র্যাম্প অন্তর্ভুক্ত থাকে।

স্ট্রেস টেস্ট অ্যাপ্লিকেশনের ব্রেকিং পয়েন্ট নির্ধারণ করে — মুহূর্ত যখন সিস্টেম অনুরোধে সাড়া দেওয়া বন্ধ করে দেয় বা গ্রহণযোগ্যভাবে অবনত হয়। লোড টেস্টের বিপরীতে, স্ট্রেস টেস্ট সিস্টেমকে সাধারণ সীমার বাইরে লোড করে। ব্রেকিং পয়েন্ট যেকোনো একটি মানদণ্ডের উপর ভিত্তি করে রিকর্ড করা হয়: প্রতিক্রিয়া সময় 10 সেকেন্ড অতিক্রম করলে, 5XX ত্রুটির শতাংশ 5% অতিক্রম করলে, বা RAM ব্যবহার উপলব্ধ মেমরির 90% এ পৌছায়।

ভোলিউম টেস্ট বড় ডেটা পরিমাণের সাথে কাজ করার সময় অ্যাপ্লিকেশনের আচরণ মূল্যায়ন করে। মোবাইল প্রাসঙ্গিকে, এটি একটি স্থানীয় ডেটাবেসে হাজার রিকর্ড, ডজন গিগাবাইট ক্যাচ, বা লাখ পুশ নটিফিকেশনের সাথে পরীক্ষা অন্তর্ভুক্ত করে। Android এ SQLite এবং iOS এ Core Data 100,000 রিকর্ড অতিক্রম করলে ভিন্ন পারফরম্যান্স দেখায়।

Performance Test এর টুল

Xcode Instruments

Xcode Instruments হল iOS অ্যাপ্লিকেশন প্রোফাইলিংয়ের প্রধান টুল। Time Profiler দেখায় কোন পদ্ধতিগুলি সবচেয়ে বেশি CPU ব্যবহার করে, যখন Allocations মেমরি বণ্টন এবং মুক্তি ট্রেক করে। Instruments দীর্ঘ সেশন (একবারে 30 মিনিট পর্যন্ত) এ রিকর্ডিং এবং বিল্ডের মধ্যে তুলনার জন্য ট্রেস এক্সপোর্ট সমর্থন করে। Instruments এর ভিতরে Activity Monitor রিয়াল টাইমে সিস্টেমের সামগ্রিক লোড দেখায়।

Android Studio Profiler

Android Studio Profiler হল Android এর বিল্ট-ইন প্রোফাইলার। এটি CPU, মেমরি, নেটওয়ার্ক এবং এনার্জি প্রোফাইলারকে একটি ইন্টারফেসে সংযুক্ত করে। Android Profiler এর একটি বৈশিষ্ট্য হল ইন্টর্যাক্টিভ সেশনের সমর্থন: ডেভেলপাররা অ্যাপ্লিকেশনে কাজ করতে পারে এবং মেট্রিক্সের তাড়াতাড়ি প্রতিক্রিয়া দেখতে পারে। Google I/O (2024) অনুযায়ী, Profiler .perf ফরম্যাটে রিকর্ডিং সমর্থন করে, যা CI এ বেসলাইনের সাথে তুলনা করা যায়।

Charles Proxy

Charles Proxy এবং Proxyman নেটওয়ার্ক ট্রেফিক বিশ্লেষণের টুল। এরা প্রতিটি HTTP অনুরোধের সময়, প্রতিক্রিয়ার আকার এবং হেডার দেখায়। Performance Test এর জন্য, যে অনুরোধগুলি 500 মিলিসেকেন্ডের বেশি সময় নেয় সেগুলি ক্যাপচার করা গুরুত্বপূর্ণ — এগুলি ক্যাশিং বা অপ্টিমাইজেশনের জন্য প্রার্থী। Charles ধীর নেটওয়ার্ক অনুকরণের জন্য থ্রটল মোড সমর্থন করে: 3G, Edge এবং LTE। Proxyman হল দেশীয় Swift আর্কিটেক্চার সহ macOS এর জন্য একটি হালকা বিকল্প।

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

CI/CD পাইপলাইনে Performance Test

CI/CD এ Performance Test সমন্বিত করা 2025–2026 এর জন্য শিল্প মান হলেও দাঁড়িয়েছে। পারফরম্যান্স পাইপলাইন তিনটি ধাপ অন্তর্ভুক্ত করে: pre-commit (pull request এ দ্রুত পরিমাপ), nightly (সম্পূর্ণ টেস্ট সুট), এবং pre-release (রেফারেন্স ডিভাইসে বেসলাইনের সাথে তুলনা)। Bitrise এবং GitHub Actions Xcode Instruments CLI এবং Gradle Profiler চালানো সমর্থন করে।

GitHub Actions (2024) `xcodebuild test-without-building` ব্যবহার করে iOS Performance Test এর জন্য একটি দাপতরিক টেমপলেট প্রকাশ করেছে। টেমপলেটটি GitHub এর একটি মশিনে টেস্ট চালায় এবং আর্টিফ্যাক্ট হিসেবে রিপোর্ট প্রকাশ করে। বেসলাইন রিপোজিটরিতে একটি JSON ফাইলে সংরক্ষিত থাকে: যদি সীমা 10% অতিক্রম করা হয়, তবে পাইপলাইন একটি ত্রুটি সহ ব্যর্থ হয়। এই পদ্ধতি প্রতিটি বিল্ড ম্যানুয়াল পর্যালোচনা ছাড়াই পারফরম্যান্স অবনতি প্রতিরোধ করে।

CI এ মোবাইল Performance Test এর সমস্যা হল বিভিন্ন মশিনে ফলাফলের অস্থিরতা। Apple Silicon (M1–M4) এবং Intel Xeon ভিন্ন নিষ্পাদন সময় দেয়। সমাধান হল পরিপূর্ণ মানের পরিবর্তে বেসলাইনের সাথে শতাংশ অনুপাত ব্যবহার করা। যদি একটি টেস্ট বেসলাইন থেকে 15% বেশি সময় নেয়, তবে বিল্ডটি পর্যালোচনা প্রয়োজন বলে চিহ্নিত করা হয়।

iOS এবং Android এ Performance Test লেখা

iOS এ XCTest Performance `measure(metrics:)` পদ্ধতি ব্যবহার করে, যা একটি কোড ব্লক 10 বার চালায় এবং পরিসংখ্যান ফেরত দেয়: গড়, মধ্যমান, মানক বিচ্যুতি। ডেটাবেস পারফরম্যান্স টেস্টিংয়ের জন্য, XCTest সুবিধাজনক XCTMemoryMetric ব্যবহার করে, যা পীক RAM ব্যবহার ক্যাপচার করে। সীমা টেস্ট শেষে `XCTPerformanceReport` এর মাধ্যমে নির্ধারিত করা হয়।

Android Macrobenchmark হল Google এর একটি লাইব্রেরি যা অ্যাপ্লিকেশন স্তরে পারফরম্যান্স পরিমাপের জন্য। Macrobenchmark ব্যবহারকξারী পরিদৃশ্য (Activity শুরু, RecyclerView স্ক্রোলিং, WebView খোলা) চালায় এবং নিষ্পাদন সময় পরিমাপ করে। Baseline Profile হল ক্লাস এবং মেথডের একটি সেট যা Android কম্পাইলার প্রাক-অপ্টিমাইজ করে। Google Play প্রথম লোন্চ 30% তারাতারিত করতে Baseline Profile ব্যবহার করে।

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

উভয় পদ্ধতি — XCTest Performance এবং Android Macrobenchmark — একই ধারণা ব্যবহার করে: গড় করে পুনরাবৃত্তি পরিমাপ এবং একটি সীমার বিরুদ্ধে তুলনা। পারফরম্যান্স কে একটি সংখ্যায় কমানো যায় না। প্রতিটি রিলিজ়ের সাথে একটি পারফরম্যান্স রিপোর্ট থাকা উচিত যাতে শেষ 5 বিল্ডের মেট্রিক্স ধারা থাকে। এমন একটি রিপোর্ট দলকে ব্যবহারকারীদের দ্বারা লক্ষ্য করার আগেই অবনতি দেখতে অনুমতি দেয়।