موبائل ڈیولپمنٹ میں 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 (فریم فی سیکنڈ) اینیمیشن اور فھرست اور کھسکاو کے دوران فریم ریٹ ہے۔ ایک ہموار انٹرفیس کے لیے مستحکم 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–1000 ہم زمان API درخواستوں کی نقل ہے۔ سرِور کو بنیادی قیمت سے 20% سے زیادہ ریسپانس ٹائم میں اضافہ کے بغیر عارضی لوڈ کو سنبھالنا چاہیے۔ k6 بینچ مارک (2024) کے مطابق، ایک طرزی Load Test ترتیب میں 5 منٹ میں 0 سے 1000 VUs (فرضی صارف)‎ تک ایک ریمپ شامل ہے۔

اسٹریس ٹیسٹ ایپلیکیشن کے بریکنگ پائنٹ کا تعین کرتا ہے — وہ لمحہ جب سسٹم درخواستوں کا جواب دینا بند کر دے یا ناقابل قبول طور پر خراب ہو جائے۔ لوڈ ٹیسٹ کے برعکس، اسٹریس ٹیسٹ سسٹم کو عام حدوں سے باہر لوڈ کرتا ہے۔ بریکنگ پائنٹ کسی ایک معیار کے بنیاد پر ریکارڈ کیا جاتا ہے: ریسپانس ٹائم 10 سیکنڈ سے تجاوز کرا، 5XX غلطیوں کا فیصد 5% سے تجاوز کرنا، یا RAM کی کھپت دستیاب میمری کے 90% تک پہنچنا۔

والیوم ٹیسٹ بڑے ڈیٹا حجوم کے ساتھ کام کرتے وقت ایپلیکیشن کے رویہ کا جائزہ لگاتا ہے۔ موبائل سیاق میں، اس میں مقامی ڈیٹابیس میں ہزاروں ریکارڈ، درجنوں گگابائٹ کی کیش، یا لاکھوں push نوٹفکیشنز کے ساتھ ٹیسٹنگ شامل ہے۔ 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

Performance Test کو CI/CD میں ضم کرنا 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 بلڈوں کے میٹرکس کے رجحانات ہوں۔ ایسی ریپورٹ ٹیم کو صارفین کے نوٹس کرنے سے پہلے گیراوٹ دیکھنے کی اجازت دیتی ہے۔