میموری لیک اور پھولنا — یہ کیا ہے، اسباب اور بچاؤ کے طریقے

میموری لیک اور ایپ کا پھولنا کیا ہے؟

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

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

Android میں، ہر ایپ کو ایک محدود ہیپ مختص کیا جاتا ہے (عام طور پر ڈیوائس اور OS ورژن کے لحاظ سے 64–512 MB)۔ iOS میں، حد کم سخت ہے، لیکن حد کے قریب پہنچنے پر سسٹم میموری وارننگ بھیجتا ہے۔

Facebook Engineering Blog کے مطابق، میموری لیک موبائل ایپس میں تقریباً ~15% کریش رپورٹس کا سبب بنتی ہیں۔ Android میں، میموری کم ہونے پر بار بار GC رکنے کی وجہ سے ANR بھی شامل ہو جاتے ہیں۔

Android اور iOS میں عام میموری لیک پیٹرن

Activity کا جامد حوالہ — ایک کلاسک Android لیک۔ اگر کوئی جامد فیلڈ یا سنگلٹن Activity کا حوالہ رکھتا ہے، تو singleton زندہ رہنے تک finish() کے بعد بھی GC اسے جمع نہیں کرے گا۔ Activity ایک بھاری آبجیکٹ ہے جس میں ویو کا درجہ بندی، وسائل اور Context شامل ہوتے ہیں۔

object LeakHolder {
    var activityRef: Activity ?= null // leak: static reference to Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity will never be GC'd
    }
}

گمنام کلاسز اور لیمبڈا — بیرونی کلاس کا ایک حوالہ واضح طور پر رکھتے ہیں۔ اگر Runnable یا Callback کسی بیرونی سروس کو بھیجا جائے اور Activity تباہ ہو جائے، تو گمنام کلاس کا آبجیکٹ ابھی بھی قطار میں رہتا ہے اور Activity کو کوڑا کرکٹ میں جمع ہونے سے روکتا ہے۔

• Handler تاخیر کے ساتھ — اگر Activity تباہ ہو جائے لیکن Handler.postDelayed ابھی عمل میں نہ آیا ہو، تو Activity لیک ہو جاتی ہے
• Thread اور AsyncTask — اسکرین گھمانے پر، Activity دوبارہ بنتی ہے جبکہ پرانا Thread پرانی Activity کا حوالہ رکھتا ہے
• Retrofit/Callback — گمنام Callback پریزینٹر یا فریگمنٹ کا حوالہ رکھتا ہے
• مشاہدہ کرنے والے — onDestroy پر بغیر منسوخی کے LiveData یا RxJava سبسکرپشنز

iOS میں اصل مسئلہ برقرار رکھنے کے چکر ہیں: دو آبجیکٹ ایک دوسرے کے مضبوط حوالہ جات رکھتے ہیں اور ARC کسی کے لیے بھی حوالہ شمار صفر نہیں کر سکتا۔ عام مثال: ایک closure جو self کو مضبوطی سے پکڑتا ہے، اور self جو closure کا حوالہ رکھتا ہے۔

میموری لیک کا پتہ کیسے لگائیں؟

LeakCanary — Android میں خودکار لیک کھوج کے لیے Square کی لائبریری۔ Activity یا Fragment تباہ ہونے کے بعد، یہ چیک کرتی ہے کہ آبجیکٹ GC نے جمع کیا یا نہیں۔ اگر نہیں، تو یہ ہیپ ڈمپ لیتی ہے اور لیک ٹریس دکھاتی ہے۔

// LeakCanary 2.x — auto-integration via Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary auto-installs in debug build
        // via ContentProvider — zero code setup
    }
}

// Force check invocation
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — ریئل ٹائم میموری مانیٹرنگ کے لیے بلٹ ان ٹول۔ یہ ہیپ ڈمپ ریکارڈ کرنے، مشکوک آبجیکٹ (Retained Size > 1 MB) تلاش کرنے اور ہر آبجیکٹ تک GC روٹ پاتھ ٹریس کرنے کی اجازت دیتا ہے۔

iOS کے لیے Xcode Memory Graph Debugger استعمال کریں۔ یہ میموری میں آبجیکٹ گراف کو دیکھتا ہے، برقرار رکھنے کے چکر دکھاتا ہے اور فوری طور پر سرکلر حوالوں کا پتہ لگانے کی اجازت دیتا ہے۔ طویل مدتی مانیٹرنگ کے لیے Instruments > Allocations بھی دستیاب ہے۔

روک تھام کی حکمت عملی

WeakReference — ان حوالوں کے لیے بنیادی طریقہ کار جو کوڑا کرکٹ جمع کرنے میں رکاوٹ نہیں بننے چاہئیں۔ اگر GC کسی آبجیکٹ کو جمع کرنے کا فیصلہ کرتا ہے، تو WeakReference null لوٹاتا ہے۔ یہ کال بیکس، سننے والوں اور بیک گراؤنڈ تھریڈز سے UI اجزاء کے حوالوں کے لیے استعمال ہوتا ہے۔

Lifecycle-aware اجزاء — Android Jetpack (Lifecycle, LiveData, Flow, coroutines) میں نافذ کردہ ایک آرکیٹیکچرل نقطہ نظر۔ onDestroy پر سبسکرپشنز خود بخود منسوخ ہو جاتی ہیں، جو لیک کی مرکزی کلاس کو ختم کر دیتی ہیں۔

class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<List<User>>()
    val data: LiveData<List<User>> get() = _data

    fun loadData() {
        viewModelScope.launch {
            val result = repository.fetchData()
            _data.postValue(result)
            // coroutine auto-cancels on onCleared()
        }
    }
}

viewModelScope اور lifecycleScope — Android میں بلٹ ان CoroutineScope جو متعلقہ لائف سائیکل ایونٹ پر منسوخ ہو جاتے ہیں۔ یہ coroutines کے ذریعے لیک کو ختم کرتا ہے — جدید Android ڈویلپمنٹ میں سب سے عام منظرنامہ۔

• استعمال نہ کریں Context، Activity، View یا Fragment کے جامد حوالہ جات
• منسوخ کریں onDestroy پر disposeBag / CompositeDisposable میں تمام RxJava سبسکرپشنز
• استعمال کریں iOS closures میں [weak self] / [unowned self] برقرار رکھنے کے چکروں کو روکنے کے لیے
• چیک کریں Bitmap اور بڑے آبجیکٹ — انہیں ری سائیکل یا null کیا جانا چاہیے

میموری پروفائلنگ کے اوزار

Android Studio میں Memory Profiler — ہیپ مانیٹرنگ کے لیے بنیادی آلہ۔ یہ لائیو ایلوکیشن، ہیپ سنیپ شاٹس اور قسم کے لحاظ سے آبجیکٹ کی گنتی دکھاتا ہے۔ یہ ڈمپ ریکارڈ کرنے اور مشکوک آبجیکٹ تلاش کرنے کے لیے MAT (Memory Analyzer Tool) میں تجزیہ کرنے کی اجازت دیتا ہے۔

Eclipse MAT — ڈیسک ٹاپ ہیپ ڈمپ تجزیہ کار۔ Android Studio سے HPROF فائل لوڈ کرنے کے بعد، MAT ایک ڈومینیٹر ٹری بناتا ہے، ہر آبجیکٹ کا retain size دکھاتا ہے اور Leak Suspects Report کے ذریعے خودکار مشکوک لیک تجزیہ پیش کرتا ہے۔

Xcode Memory Graph — برقرار رکھنے کے چکروں کا بصری ڈیبگر۔ Memory Graph Debugger بٹن پر کلک کرنے پر، Xcode ایپ کو روکتا ہے، میموری میں ایک مکمل آبجیکٹ گراف بناتا ہے اور برقرار رکھنے کے چکروں کو سرخ رنگ میں نمایاں کرتا ہے۔

Google I/O 2023 کے مطابق، ڈیبگ بلڈ میں LeakCanary استعمال کرنے والی ایپس اپنانے کے پہلے 2 مہینوں میں میموری سے متعلق کریشز کو 30–50% کم کرتی ہیں۔ پروجیکٹ آن بورڈنگ مرحلے میں LeakCanary شامل کرنے کی سفارش کی جاتی ہے۔