موبائل ڈیولپمنٹ میں کارکردگی: یہ کیا ہے، کون سے میٹرکس اور کیسے بہتر بنائیں

ایپ سست کیوں ہے؟

ایپ کی کارکردگی کا تعلق براہ راست jank سے ہے — صارف کے عمل اور UI کے ردعمل کے درمیان نمایاں تاخیر۔ بنیادی وجوہات: مین تھریڈ بلاکنگ (UI تھریڈ پر بھاری آپریشنز)، بار بار لے آؤٹ دوبارہ ڈرائینگ (overdraw)، میموری لیک (بار بار GC)، غیر بہتر الگورتھم (بڑے ڈیٹا پر O(n²))۔ فریم ریٹ (FPS) — فی سیکنڈ فریموں کی تعداد۔ آرام دہ تجربے کے لیے مستحکم 60 FPS (Android) یا 120 FPS (iPhone Pro, iPad Pro) کی ضرورت ہے۔ VSync — اسکرین ریفریش ریٹ کے ساتھ رینڈرنگ کو ہم آہنگ کرتا ہے۔

Jank اس وقت ہوتا ہے جب ایک فریم کی رینڈرنگ 16.6 ms (60 FPS کے لیے) یا 8.3 ms (120 FPS کے لیے) سے تجاوز کر جائے۔ GPU profiling (Android پر Profile GPU Rendering، iOS پر Core Animation) دکھاتا ہے کہ رینڈرنگ کے کون سے مراحل سب سے زیادہ وقت لیتے ہیں۔ بنیادی مراحل: Layout (عناصر کی ترتیب)، Draw (ڈرائینگ)، Display (فریم بفر میں منتقلی)۔ سب سے عام مسئلہ XML میں لے آؤٹ inflation ہے، خاص طور پر پیچیدہ nested ConstraintLayout استعمال کرتے وقت۔

Time-to-Interactive (TTI) — وہ وقت جس میں ایپ مکمل طور پر تعامل کے لیے تیار ہو جاتی ہے۔ TTI میں کولڈ اسٹارٹ، ڈیٹا لوڈنگ اور لائبریری ابتدا شامل ہے۔ Google TTI کو 5 سیکنڈ سے کم، Apple — اہم اسکرینوں کے لیے 2 سیکنڈ سے کم رکھنے کی سفارش کرتا ہے۔ Lazy Loading — مواد اور لائبریریوں کی تاخیر سے لوڈنگ کی تکنیک، TTI کو بہتر بنانے کے لیے اہم۔ IT Sectr میں ہم تمام پروجیکٹس میں ڈیفالٹ طور پر سست ابتدا استعمال کرتے ہیں۔

ANR اور کریش

ANR اور کریش — موبائل ایپ کارکردگی کے اہم دشمن۔ ANR (Application Not Responding) — Android پر ظاہر ہونے والا ڈائیلاگ باکس جو اس وقت ظاہر ہوتا ہے جب مین تھریڈ 5 سیکنڈ سے زیادہ بلاک ہو۔ وجوہات: UI تھریڈ پر ہم وقت ساز نیٹ ورک درخواستیں، کوروٹین کے بغیر ڈیٹا بیس کے ساتھ کام، ڈاؤن سیمپلنگ کے بغیر بڑی bitmap ڈی کوڈ، مین تھریڈ پر ڈیڈ لاک۔ ANR کال اسٹیک /data/anr/traces.txt میں محفوظ ہوتا ہے اور عین بلاک ہونے کی جگہ کا تعین کرنے دیتا ہے۔

کریش — ایپ کا غیر متوقع خاتمہ۔ Android پر — Exception (Java/Kotlin) یا Signal (اصلی کوڈ)۔ iOS پر — NSException یا سگنل (EXC_BAD_ACCESS — آزاد کردہ میموری تک رسائی)۔ کریش رپورٹنگ ٹولز: Firebase Crashlytics, Sentry, BugSnag۔ یہ stacktrace، ڈیوائس ڈیٹا اور تولیدی اقدامات جمع کرتے ہیں۔ Stack Overflow — لامتناہی تکرار کی وجہ سے کال اسٹیک اوور فلو۔ OutOfMemoryError — جب ہیپ بھر جائے۔

StrictMode — تھریڈ سیفٹی کی خلاف ورزیاں دریافت کرنے کا Android ٹول۔ یہ قواعد طے کرنے دیتا ہے: ThreadPolicy (مین تھریڈ پر ڈسک/نیٹ ورک ممنوع)، VmPolicy (Activity, SQLite, CloseGuard لیک دریافت کریں)۔ StrictMode صرف ڈیبگ بلڈ میں فعال کرنے کی سفارش کی جاتی ہے — ریلیز میں اسے کام نہیں کرنا چاہیے۔ iOS پر مساوی Main Thread Checker (Xcode) ہے، جو خود بخود مین تھریڈ پر نہ ہونے والی UIKit کالز کا پتہ لگاتا ہے۔

میموری مینجمنٹ (GC, ARC, Retain Cycle)

میموری لیک

میموری لیک — وہ صورت حال جب ایک آبجیکٹ میموری میں رہتا ہے حالانکہ ایپ اسے مزید استعمال نہیں کر رہی۔ یہ براہ راست ایپ کی کارکردگی کو کم کرتا ہے۔ Android پر، GC (Garbage Collection) کسی آبجیکٹ کو جمع نہیں کر سکتا اگر اس پر مضبوط حوالہ (strong reference) ہو۔ عام وجوہات: Activity پر جامد حوالہ جات، صاف نہ کیے گئے کال بیک/مشاہدہ کنندگان، بیرونی کلاس کے لیے مضمر حوالہ والے اندرونی کلاس، صاف نہ کیے گئے پیغامات والا Handler۔ LeakCanary — خودکار لیک دریافت کرنے کے لیے لائبریری۔

Retain Cycle (برقرار رکھنے کا چکر)

ARC (Automatic Reference Counting) — iOS میں میموری مینجمنٹ ماڈل۔ ہر آبجیکٹ میں حوالہ شمار (retain count) ہوتا ہے۔ شمار صفر ہونے پر میموری آزاد ہو جاتی ہے۔ Retain Cycle اس وقت ہوتا ہے جب دو آبجیکٹ ایک دوسرے پر مضبوط حوالہ رکھتے ہوں (A → B اور B → A)۔ ARC کبھی شمار کنندگان کو صفر نہیں کرے گا۔ حل: کمزور (weak) یا بے مالک (unowned) حوالہ جات۔ Weak آبجیکٹ آزاد ہونے پر خود بخود nil ہو جاتا ہے۔ Unowned nil نہیں ہوتا لیکن ضمانت دیتا ہے کہ آبجیکٹ زندہ ہے۔

GC بمقابلہ ARC

GC (Garbage Collection) Android (Java/Kotlin) پر چلتا ہے۔ GC ناقابل رسائی آبجیکٹس کو ڈھونڈنے اور آزاد کرنے کے لیے وقتاً فوقتاً عملدرآمد روکتا ہے (Stop-the-World pause)۔ GC ٹرگر: جب ہیپ ایک خاص فیصد تک بھر جائے۔ ARC iOS (Swift/Objective-C) پر چلتا ہے اور اس میں کوئی وقفہ نہیں — شمار کنندگان ہر تفویض پر جوہری طور پر اپ ڈیٹ ہوتے ہیں۔ ARC زیادہ پیش قیاسی ہے لیکن زیادہ تفویض فریکوئنسی پر ضرورت سے زیادہ retain/release آپریشنز جمع کر سکتا ہے۔

کمزور حوالہ (Weak Reference) اور مضبوط حوالہ (Strong Reference) — حوالہ کی قسم طے کرتی ہے کہ آیا GC/ARC آبجیکٹ کو آزاد کر سکتا ہے۔ Strong Reference — جب تک یہ حوالہ موجود ہے، آبجیکٹ جمع نہیں کیا جائے گا۔ Weak Reference — GC/ARC آبجیکٹ جمع کر سکتا ہے؛ کمزور حوالہ nil ہو جاتا ہے (Swift/Java WeakReference میں)۔ Unowned Reference (Swift) — آزاد ہونے پر nil نہیں ہوتا؛ آبجیکٹ کے مرنے کے بعد اس تک رسائی کریش کا سبب بنتی ہے۔ Android پر کمزور حوالوں کے لیے java.lang.ref.WeakReference استعمال ہوتا ہے۔

LeakCanary کے ذریعے Android پر لیک دریافت کرنے کی مثال:

// Утечка: анонимный класс держит ссылку на Activity
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val handler = object : Handler(Looper.getMainLooper()) {
            override fun handleMessage(msg: Message) {
                // Используем `this@MainActivity`, сохраняя ссылку на Activity
                Log.d("TAG", "Handler received message")
            }
        }
        handler.sendEmptyMessageDelayed(0, 60000)
    }
}

// Исправление: статический Handler + WeakReference
class SafeHandler(activity: MainActivity) : Handler() {
    private val weakActivity =
        WeakReference(activity)

    override fun handleMessage(msg: Message) {
        weakActivity.get() ?: return
        Log.d("TAG", "Handler received message")
    }
}

Profiling (Instruments, Android Profiler)

Profiling — ایپ کی کارکردگی (CPU، میموری، نیٹ ورک، توانائی کی کھپت) کی پیمائش کا عمل۔ Profiling کے بغیر، اندھی اصلاح بے کار ہے — آپ نہیں جان پائیں گے کہ کوڈ کا کون سا حصہ حقیقتاً سست ہے۔

Instruments (Xcode) — iOS کے لیے سب سے طاقتور ٹول۔ Time Profiler دکھاتا ہے کہ کون سے فنکشن سب سے زیادہ CPU استعمال کرتے ہیں۔ Allocations آبجیکٹ کی تخلیق اور آزادی کو ٹریک کرتا ہے۔ Leaks خود بخود retain cycles ڈھونڈتا ہے۔ Profiling کے مراحل: (1) Instruments شروع کریں؛ (2) ٹیمپلیٹ منتخب کریں (CPU کے لیے Time Profiler)؛ (3) مسئلہ والا منظر نامہ چلائیں؛ (4) کال اسٹیک کا تجزیہ کریں — سب سے چوڑا کالم سب سے "ہاٹ" فنکشن ہے۔

Android Profiler Android Studio میں شامل ہے (View → Tool Windows → Profiler)۔ CPU Profiler ہر تھریڈ کا بوجھ دکھاتا ہے۔ Memory Profiler — ہیپ ڈمپ اور مختص ٹریکنگ۔ Network Profiler — اوقات کے ساتھ تمام HTTP درخواستیں۔ Energy Profiler — توانائی کی کھپت: WakeLock, Location, Network۔ تفصیلی ٹریسنگ کے لیے Systrace (Android 10+) یا Perfetto — مائیکرو سیکنڈ درستگی کے ساتھ نظام ٹریسنگ استعمال کریں۔

ایپ اسٹارٹ اپ (کولڈ/وارم/ہاٹ اسٹارٹ)

ایپ اسٹارٹ اپ — کارکردگی کے اہم اشارے میں سے ایک ہے۔ یہ تین اقسام میں تقسیم ہے: کولڈ اسٹارٹ — ایپ شروع سے شروع ہوتی ہے: عمل بنایا جاتا ہے، Application.onCreate (Android) / AppDelegate.applicationDidFinishLaunching (iOS)، کلاس لوڈنگ، لائبریری ابتدا۔ وارم اسٹارٹ — عمل موجود ہے لیکن Activity/ViewController تباہ ہو چکا ہے (مثال کے طور پر، اسکرین گھمانے یا میموری سے واپسی پر)۔ ہاٹ اسٹارٹ — Activity/ViewController میموری میں ہے، ایپ صرف دکھائی جاتی ہے (دوسری ایپ سے سوئچ کرنا)۔

کولڈ اسٹارٹ سب سے اہم میٹرک ہے۔ Android پر شامل ہے: (1) لانچ Activity — XML لوڈنگ، View ابتدا؛ (2) پہلا فریم — پہلی رینڈرنگ تک کا وقت۔ Google سفارش کرتا ہے: لانچ Activity < 200 ms، پہلا فریم < 500 ms، TTI < 5 سیکنڈ۔ کولڈ اسٹارٹ کی اصلاح: Application.onCreate کم کریں (سست ابتدا کے لیے کوروٹین)، SplashScreen API (Android 12+) استعمال کریں، لائبریری ابتدا مؤخر کریں (WorkManager, DI)، غیر ضروری ContentProviders ہٹائیں۔

iOS پر، کولڈ اسٹارٹ میں شامل ہے: Mach-O بائنری لوڈنگ، dyld (متحرک لنکر)، Objective-C رن ٹائم ابتدا، ایپلیکیشن ڈیلیگیٹ، پہلا کنٹرولر۔ Chrome Custom Tabs (Android) اور Universal Links (iOS) — مکمل کولڈ اسٹارٹ کے بغیر ایپ میں بیرونی مواد تیزی سے کھولنے کی ٹیکنالوجیز۔ درمیانی درجے کے اصلی آلات پر کولڈ اسٹارٹ کی جانچ کرنے کی سفارش کی جاتی ہے۔

سائز کی اصلاح

ایپ کا سائز — تنصیب اور اپ ڈیٹس کے لیے کارکردگی کا عنصر ہے۔ یہ تبدیلی کو متاثر کرتا ہے: ہر 10 MB تبدیلی کو 1% کم کرتا ہے۔ Google Play سفارش کرتا ہے APK سائز 150 MB سے کم؛ App Store — 200 MB سے کم (سیلولر نیٹ ورکس — 100 MB)۔ اہم اصلاح کے طریقے: تصویری کمپریشن (PNG کے بجائے WebP 25-35% بچاتا ہے)، ویکٹرائزیشن (Android پر VectorDrawable، iOS پر SF Symbols)، غیر استعمال شدہ کوڈ ہٹانا (R8/ProGuard)، غیر استعمال شدہ وسائل ہٹانا (lint → unused resources)۔

App Bundle (Android) — اشاعت کا فارمیٹ جس میں Google Play ہر ڈیوائس کے لیے بہتر کردہ APK تیار کرتا ہے۔ App Bundle ڈاؤن لوڈ سائز کو 20-40% کم کرتا ہے۔ Dynamic Delivery — ماڈیولز جو مانگ پر ڈاؤن لوڈ ہوتے ہیں (on-demand feature modules)۔ iOS پر مساوی On-Demand Resources (ODR) ہے: وہ وسائل جو پہلے لانچ کے بعد ڈاؤن لوڈ ہوتے ہیں (گیم کی سطحیں، ویڈیوز)۔

Lazy Loading — وہ تکنیک جس میں ماڈیولز اور لائبریریاں اسٹارٹ اپ پر لوڈ نہیں ہوتیں بلکہ ضرورت کے مطابق لوڈ ہوتی ہیں۔ Split APK (Android) اور App Slicing (iOS) — ایپ کو آرکیٹیکچر سلاٹس میں تقسیم کرنا: arm64-v8a, x86_64۔ ایپ سائز کی اصلاح — ایک مسلسل عمل: APK کی ساخت کا تجزیہ کریں (Android Studio میں Analyze APK)، ڈپلیکیٹ آئیکنز ہٹائیں، متعدد PNG کثافتوں کے بجائے SVG استعمال کریں۔ IT Sectr میں ہم ہر MR کے لیے CI/CD میں بلڈ سائز کی جانچ شامل کرتے ہیں۔