میموری لیک: یہ کیا ہے، عام منظرنامے اور تشخیص

موبائل ایپلیکیشنز میں میموری لیک کیا ہے؟

میموری لیک — ایک ایسی صورت حال جہاں مختص کردہ میموری پروگرام کے آبجیکٹ کی مزید ضرورت نہ ہونے کے بعد بھی سسٹم کو واپس نہیں کی جاتی۔ کوڑا کرکٹ جمع کرنے والا اس آبجیکٹ کو زندہ سمجھتا ہے کیونکہ GC Root سے ایک فعال حوالہ زنجیر اس کی طرف اشارہ کر رہی ہے۔

Java/Kotlin میں، کوڑا کرکٹ جمع کرنے والا خود بخود کام کرتا ہے، لیکن یہ تعین نہیں کر سکتا کہ کوئی آبجیکٹ منطقی طور پر غیر ضروری ہے اگر اس کا تکنیکی حوالہ موجود ہو۔ ڈویلپر کو غیر ضروری رابطوں کو واضح طور پر توڑنا چاہیے۔ Swift/Objective-C میں، ARC خود بخود حوالوں کو گنتا ہے، لیکن retain cycles کاؤنٹر کو صفر ہونے سے روکتی ہیں۔

لیک کا بنیادی خطرہ مجموعی اثر ہے۔ ہر لیک تھوڑی مقدار میں میموری استعمال کرتا ہے، لیکن بار بار اسکرین ٹرانزیشن (اسکرین گھماؤ، Activity کھلنا/بند ہونا) کے ساتھ لیک جمع ہوتے رہتے ہیں جب تک کہ heap کی حد ختم نہ ہو جائے۔

لیک بلاٹ سے کیسے مختلف ہے؟

لیک — آبجیکٹ کوڈ کے لیے ناقابل رسائی ہے لیکن GC کے ذریعے ہٹایا نہیں گیا۔ بلاٹ — آبجیکٹ منطقی طور پر ضروری ہے لیکن ضرورت سے زیادہ مقدار میں محفوظ ہے۔ بلاٹ کی مثال: 30 MB کے ورکنگ سیٹ کے ساتھ 100 MB کی تصویر کیش۔ دونوں مسائل OOM کی طرف لے جاتے ہیں، لیکن اسباب اور علاج کے طریقے مختلف ہیں۔

کوڑا کرکٹ جمع کرنے والا کیسے کام کرتا ہے اور لیک کیوں ہوتے ہیں؟

ART (Android Runtime) ہم آہنگ کمپیکشن کے ساتھ نسلی کوڑا کرکٹ جمع کرنے کا استعمال کرتا ہے۔ میموری کو نوجوان نسل (Young)، پرانی نسل (Old) اور بڑی اشیاء (Large) میں تقسیم کیا گیا ہے۔ متعدد GC سائیکل سے بچنے والی اشیاء Old نسل میں منتقل ہو جاتی ہیں، جہاں جمع کرنا کم بار بار ہوتا ہے — اس سے عام سائیکل تیز ہو جاتے ہیں۔

GC اس وقت شروع ہوتا ہے جب heap ایک خاص قبضے کی حد (عام طور پر 75-85%) تک پہنچ جاتا ہے۔ GC کے دوران، ایپلیکیشن کے تمام تھریڈ روک دیے جاتے ہیں (STW — Stop The World)۔ جتنی زیادہ زندہ اشیاء، اتنا ہی طویل وقفہ۔ لیک زندہ اشیاء کی تعداد بڑھاتے ہیں، GC کے وقفوں کو لمبا کرتے ہیں۔

جمع کرنے والا GC Roots سے گراف کو گھوم کر زندہ اشیاء کا تعین کرتا ہے: جامد فیلڈز، فعال تھریڈ کے اسٹیک متغیرات، JNI حوالہ جات۔ ان جڑوں سے حوالوں کے ذریعے قابل رسائی کوئی بھی آبجیکٹ زندہ سمجھا جاتا ہے — چاہے ڈویلپر جانتا ہو کہ اس کی مزید ضرورت نہیں ہے۔

// مثال: GC Root کے طور پر جامد مجموعہ — مستقل لیک
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference GC کو نہیں روکتا — صحیح رویہ
    }
}

WeakReference مسئلہ حل کرتا ہے: GC زندہ اشیاء کا تعین کرتے وقت کمزور حوالوں کو نظر انداز کرتا ہے۔ اگر کسی آبجیکٹ پر صرف کمزور حوالے باقی ہیں، تو یہ قریب ترین GC سائیکل میں جمع کر لیا جائے گا۔

Android اور iOS میں عام لیک کے منظرنامے

Activity Context — Android میں سب سے وسیع لیک منظرنامہ۔ اگر سنگلٹن، جامد فیلڈ یا طویل المدت سروس Activity Context کا حوالہ محفوظ کرتی ہے، تو تمام Views سمیت پوری Activity GC کے ذریعے جمع نہیں کی جا سکتی۔ حل: طویل المدت اشیاء کے لیے Application Context استعمال کریں۔

Handler اور بھیجے گئے پیغامات — Handler.postDelayed(runnable, delay) Main Looper قطار میں ایک پیغام ڈالتا ہے۔ اگر تاخیر ختم ہونے سے پہلے Activity تباہ ہو جاتی ہے، تو پیغام اب بھی قطار میں ہے اور Runnable → گمنام کلاس → بیرونی کلاس (Activity) کے ذریعے حوالہ رکھتا ہے۔

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // لازمی: قطار صاف کریں
        super.onPause()
    }
}

اندرونی کلاسیں — ایک غیر جامد اندرونی کلاس کا بیرونی کلاس کے نمونے پر ایک مضمر حوالہ ہوتا ہے۔ اگر بیرونی کلاس Activity ہے اور اندرونی کلاس باہر کہیں منتقل کی جاتی ہے (مثال کے طور پر، RecyclerView.Adapter میں)، تو Activity جمع نہیں کی جا سکتی۔

• TimerTask اور ScheduledExecutorService — Activity تباہی سے پہلے طے شدہ کام
• BroadcastReceiver — onPause/onDestroy میں رجسٹریشن منسوخ نہ کرنے پر Context رکھتا رہتا ہے
• View حوالہ کے ساتھ ViewModel — ViewModel Activity سے زیادہ زندہ رہتا ہے، View کا حوالہ لیک کا سبب بنتا ہے
• Retrofit Call — اگر Call منسوخ نہ کیا جائے، تو جواب تباہ شدہ Fragment پر آتا ہے

میموری لیک تشخیصی ٹولز

Android Studio Memory Profiler — ریئل ٹائم heap نگرانی کے لیے بلٹ ان ٹول۔ استعمال شدہ میموری کا گراف، مختصات کی تعداد اور قسم کے لحاظ سے اشیاء دکھاتا ہے۔ MAT میں تجزیہ کے لیے heap dump ریکارڈ کرنے اور HPROF فارمیٹ میں برآمد کرنے کی اجازت دیتا ہے۔

Eclipse MAT (Memory Analyzer Tool) — ڈیسک ٹاپ heap dump تجزیہ کار۔ خود بخود Leak Suspects رپورٹس بناتا ہے، جو سب سے بڑے retained size والی اشیاء کو نمایاں کرتا ہے اور ہر مشکوک آبجیکٹ کے لیے ممکنہ GC root chain تجویز کرتا ہے۔

Xcode Memory Graph Debugger — iOS کے لیے۔ ایپلیکیشن روکتا ہے اور آبجیکٹ گراف کو بصری بناتا ہے۔ Retain cycles کو سرخ رنگ میں نمایاں کیا جاتا ہے؛ کسی بھی آبجیکٹ پر کلک کر کے اس کا retain count اور حوالے دیکھ سکتے ہیں۔

Uber Engineering Blog کے مطابق، CI/CD پائپ لائن میں خودکار میموری پروفائلنگ (LeakCanary + heap dump تجزیہ) کو ضم کرنے سے 3 ماہ کے اندر پروڈکشن میں میموری سے متعلق واقعات میں 60% کمی آتی ہے۔

لیک ختم کرنے کے طریقے

Context تبدیل کریں — اگر کوئی آبجیکٹ Activity سے زیادہ زندہ رہتا ہے، تو applicationContext استعمال کریں۔ تمام طویل المدت اشیاء (سنگلٹن، ریپوزیٹری، ڈیٹا بیس ہیلپر) کو Activity Context نہیں بلکہ Application Context ملنا چاہیے۔ مستثنیٰ: UI اجزاء جنہیں Activity کے مخصوص تھیم یا وسائل تک رسائی کی ضرورت ہے۔

Lifecycle-aware اجزاء — LifecycleObserver، DefaultLifecycleObserver یا ری ایکٹو ایکسٹینشنز کا استعمال onDestroy پر خود بخود سبسکرپشنز منسوخ کرتا ہے۔ Android Jetpack lifecycleScope اور viewModelScope فراہم کرتا ہے، جو متعلقہ لائف سائیکل ایونٹ کے ذریعے صاف کیے جاتے ہیں۔

جامد اندرونی کلاس — اگر اندرونی کلاس کو بیرونی کلاس کے فیلڈز تک رسائی کی ضرورت نہیں ہے، تو اسے static بنائیں۔ جامد اندرونی کلاس کا بیرونی کلاس پر کوئی مضمر حوالہ نہیں ہوتا۔ اگر رسائی کی ضرورت ہو، تو واضح حوالہ کے لیے WeakReference استعمال کریں۔

class MyActivity : AppCompatActivity() {

    // ❌ غیر جامد اندرونی کلاس — MyActivity کا مضمر حوالہ
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ جامد اندرونی کلاس — کوئی مضمر حوالہ نہیں
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

iOS میں، کیپچر فہرستیں استعمال کریں: closure میں [weak self] جو اپنے بنانے والے سے زیادہ زندہ رہ سکتے ہیں۔ مندوبین کے لیے، کمزور حوالے استعمال کریں (weak var delegate)۔ ان closure کے لیے جن کے صرف self کی زندگی کے دوران بلائے جانے کی ضمانت ہے، [unowned self] استعمال کیا جا سکتا ہے، لیکن احتیاط سے — ختم شدہ آبجیکٹ تک رسائی کریش کا سبب بنے گی۔