onDestroy: یہ کیا ہے، Android میں Activity کے کام کا خاتمہ

onDestroy: Android میں یہ کیا ہے؟

onDestroy — ایک کال بیک طریقہ ہے جسے Android Activity یا Fragment کو مکمل طور پر تباہ کرنے سے پہلے کال کرتا ہے۔ یہ ڈیویلپر کے لیے وسائل جاری کرنے، پس منظر کے آپریشنز منسوخ کرنے اور ڈیٹا کے کام کو ختم کرنے کا آخری موقع ہے۔ onDestroy کے عمل درآمد کے بعد، Activity/Fragment مثال کو کوڑا کرکٹ جمع کرنے (GC) کے لیے نشان زد کیا جاتا ہے اور مزید استعمال نہیں کیا جا سکتا۔

onDestroy کال کرنے کی وجوہات:

• واضح finish() کال — صارف نے «واپس» دبایا یا ڈیویلپر نے finishActivity() کال کیا۔
• اسکرین گھماؤ — Activity تباہ ہو جاتی ہے اور نئی ترتیب کے ساتھ دوبارہ بنائی جاتی ہے۔
• ترتیب میں تبدیلی — کی بورڈ، زبان کی تبدیلی، اسکرین کے سائز میں تبدیلی (ملٹی ونڈو)۔
• نظام کا فیصلہ — Android وسائل خالی کرنے کے لیے Activity کو مار دیتا ہے (لیکن onDestroy کال نہیں ہو سکتا)۔

Google Android Vitals کے اعدادوشمار (2025) کے مطابق، Activity کی تباہی کے تمام معاملات میں سے تقریباً 12% اسکرین گھماؤ کی وجہ سے، 65% finish() کی وجہ سے اور 23% ترتیب میں تبدیلیوں کی وجہ سے ہوتے ہیں۔ onDestroy چھوڑے جانے والی عمل کی موت کا فیصد کم RAM (4 GB سے کم) والے آلات کے لحاظ سے تقریباً 5–8% ہے۔

onDestroy کب کال کیا جاتا ہے — اور کب نہیں کال کیا جاتا

onDestroy زیادہ تر معیاری منظرناموں میں کال کیا جاتا ہے، لیکن اہم استثنات ہیں جنہیں ڈیویلپر کو مدنظر رکھنا چاہیے۔ onDestroy کال کی ضمانتوں کو سمجھنا ایپلیکیشن فن تعمیر کے لیے اہم ہے، خاص طور پر ڈیٹا کو محفوظ کرنے اور WorkManager کے کاموں کو منسوخ کرنے کے لیے۔

onDestroy کب کال کیا جاتا ہے:

• صارف «واپس» بٹن دباتا ہے — Activity.finish() → onPause → onStop → onDestroy۔
• اسکرین گھماؤ — Activity تباہ ہوتی ہے (onPause → onStop → onDestroy)، پھر دوبارہ بنائی جاتی ہے۔
• ترتیب میں تبدیلی — نظام کی ترتیب جس میں Activity کی دوبارہ تخلیق درکار ہے۔
• finishAffinity() کال کرنا — اسٹیک میں موجود تمام Activities کو ختم کرنا۔
• FragmentManager سے Fragment ہٹانا — Fragment وصول کرتا ہے: onPause → onStop → onDestroyView → onDestroy → onDetach۔

onDestroy کب نہیں کال کیا جاتا:

• نظام کی طرف سے عمل کی موت — Android میموری کم ہونے پر پوری ایپلیکیشن کے عمل کو مار دیتا ہے۔ Activity کو onDestroy نہیں ملتا کیونکہ عمل Linux کرنل کی سطح پر ختم ہوتا ہے۔
• غیر معمولی خاتمہ — مرکزی دھاگے میں نہ پکڑی جانے والی استثنا onDestroy کال کیے بغیر ایپلیکیشن کو مار دیتی ہے۔
• جبری روک — صارف ترتیبات میں ایپلیکیشن کو زبردستی روکتا ہے۔

onDestroy کال کی ضمانت کی کمی کی وجہ سے، Google تجویز کرتا ہے: اہم ڈیٹا محفوظ کرنے کے لیے کبھی بھی onDestroy پر انحصار نہ کریں۔ onSaveInstanceState()، WorkManager یا خودکار محفوظ کرنے والے Room کا استعمال کریں۔ onDestroy وسائل جاری کرنے کے لیے ہے، استقامت (persistence) کے لیے نہیں۔

Activity اور Fragment میں onDestroy: مشترکہ اور فرق

onDestroy Activity اور Fragment دونوں کے لیے موجود ہے، لیکن مختلف معاہدوں کے ساتھ۔ Fragment کا زندگی کا دورانیہ زیادہ تفصیلی ہے: onDestroy کے علاوہ، onDestroyView (View کا درجہ بندی تباہ کرنا) اور onDetach (Activity سے علیحدگی) بھی ہیں۔

بنیادی فرق: Fragment کا View خود Fragment سے زیادہ بار دوبارہ بنایا جاتا ہے۔ اسکرین گھماؤ کے دوران، Fragment onDestroyView (View تباہی) سے گزرتا ہے، لیکن Fragment خود اور اس کا ViewModel زندہ رہتے ہیں۔ onDestroyView میموری لیک سے بچنے کے لیے View حوالہ جات صاف کرنے کی صحیح جگہ ہے۔ Fragment کا onDestroy Activity کے onDestroy جیسا ہے، جو Fragment کے مکمل طور پر ہٹائے جانے پر کال کیا جاتا ہے۔

چائلڈ فریگمنٹس پیرنٹ Fragment کے onDestroy سے پہلے تباہ ہو جاتے ہیں۔ Activity میں، چائلڈ فریگمنٹس کو onDestroy اس وقت ملتا ہے جب پیرنٹ Activity کا onDestroy کال کیا جاتا ہے۔ ترتیب ضمانت شدہ ہے: فریگمنٹس ان پر مشتمل Activity سے پہلے ختم ہوتے ہیں۔

onDestroy میں کیا کریں: صفائی کی جانچ کی فہرست

onDestroy ان تمام وسائل کو جاری کرنے کے لیے ہے جو Activity یا Fragment سے زیادہ زندہ نہیں رہنے چاہئیں۔ onStop کے برعکس، جو واپسی تک وسائل جاری کرتا ہے، onDestroy حتمی صفائی کرتا ہے۔

onDestroy میں لازمی اقدامات کی جانچ کی فہرست:

• Coroutine اور Flow منسوخ کریں — ان کاموں کو منسوخ کریں جو viewModelScope سے منسلک نہیں ہیں۔ viewModelScope خودکار طور پر منسوخ ہو جاتا ہے، لیکن lifecycleScope Activity کے زندگی کے دورانیے سے منسلک ہے۔
• ساکٹ اور چینل بند کریں — WebSocket (OkHttp)، BluetoothSocket، ServerSocket۔ تباہی کے بعد انہیں کھلا رکھنا نظام کے وسائل کا لیک ہے۔
• فائلیں اور سٹریم بند کریں — FileInputStream، FileOutputStream، Cursor۔ Cursor بند نہ کرنے پر ContentProvider پر ANR کا سبب بن سکتا ہے۔
• ContentObserver کی رکنیت منسوخ کریں — اگر Activity مواد کی تبدیلیوں (رابطے، میڈیا لائبریری) کی نگرانی کر رہی ہے۔
• BroadcastReceiver کی رجسٹریشن منسوخ کریں — متحرک طور پر رجسٹرڈ وصول کنندگان کو منسوخ کرنا ضروری ہے۔
• ڈیٹابیس بند کریں — Room Application تباہ ہونے پر خودکار طور پر کنکشن بند کر دیتا ہے، لیکن براہ راست SQLiteDatabase کو دستی close() کی ضرورت ہے۔

onDestroy میں کیا نہ کریں: onDestroy میں ڈیٹا محفوظ نہ کریں — onPause یا onSaveInstanceState استعمال کریں۔ نیا Service یا WorkManager کام شروع نہ کریں — Activity تباہ ہو جائے گی اور آپ نتیجہ ٹریک نہیں کر سکیں گے۔ یوزر انٹرفیس کو اپ ڈیٹ کرنے کی کوشش نہ کریں — View کا درجہ بندی پہلے ہی تباہ ہو چکا ہے یا تباہی کے عمل میں ہے؛ findViewById() کال کرنے پر null واپس آئے گا۔

onDestroy اور ViewModel: ایک ساتھ کام کرنا

ViewModel اسکرین گھماؤ کے دوران Activity کے onDestroy سے بچنے کے لیے ڈیزائن کیا گیا ہے، لیکن finish() کے دوران Activity کے ساتھ تباہ ہو جاتا ہے۔ یہ غیر متناسب رویہ ڈیویلپرز کے درمیان الجھن کی بنیادی وجہ ہے۔

اسکرین گھماؤ کے دوران:

• Activity: onPause → onStop → onDestroy (Activity تباہ)۔
• ViewModel: تباہ نہیں ہوا — ViewModelStore محفوظ کیا جاتا ہے اور نئی Activity کو بھیجا جاتا ہے۔
• نئی Activity: onCreate → onStart → onResume، وہی ViewModel وصول کرتی ہے۔

finish() کے دوران (صارف نے «واپس» دبایا):

• Activity: onPause → onStop → onDestroy۔
• ViewModel: onCleared() — Activity کے onDestroy کے بعد کال کیا جاتا ہے۔
• تمام viewModelScope coroutine خودکار طور پر منسوخ ہو جاتے ہیں۔

لہذا، onDestroy میں viewModelScope منسوخ کرنا ضروری نہیں ہے — ViewModel خود یہ کرے گا۔ اگر آپ lifecycleScope (ViewModel سے نہیں، Activity سے منسلک) استعمال کر رہے ہیں، تو اسے onDestroy میں lifecycleScope.cancel() کے ذریعے منسوخ کریں یا Job کو دستی طور پر منظم کریں۔

Kotlin میں onDestroy کے ساتھ کوڈ کی مثالیں

مثال 1: lifecycleScope coroutine منسوخی کے ساتھ onDestroy Activity

Activity میں درست lifecycleScope انتظام کو ظاہر کرتا ہے: نیٹ ورک کی حیثیت کی نگرانی کے لیے ایک coroutine شروع کی جاتی ہے اور onDestroy میں منسوخ کی جاتی ہے۔

class NetworkMonitorActivity : AppCompatActivity() {
    private val networkCallback = object : ConnectivityManager.NetworkCallback() {
        override fun onAvailable(network: Network) {
            Log.d("NetworkMonitor", "نیٹ ورک دستیاب")
        }
        override fun onLost(network: Network) {
            Log.d("NetworkMonitor", "نیٹ ورک ختم ہو گیا")
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_network)
        val connectivityManager = getSystemService(ConnectivityManager::class.java)
        connectivityManager.registerDefaultNetworkCallback(networkCallback)
        lifecycleScope.launch {
            Log.d("NetworkMonitor", "نیٹ ورک کی نگرانی شروع ہو گئی")
        }
    }

    override fun onDestroy() {
        super.onDestroy()
        val connectivityManager = getSystemService(ConnectivityManager::class.java)
        connectivityManager.unregisterNetworkCallback(networkCallback)
        Log.d("NetworkMonitor", "onDestroy: کال بیک منسوخ کر دیا گیا")
    }
}

onDestroy میں، نیٹ ورک کال بیک کی رجسٹریشن منسوخ کی جاتی ہے۔ lifecycleScope زندگی کے دورانیے کے تباہ ہونے پر خودکار طور پر منسوخ ہو جاتا ہے — علیحدہ coroutine منسوخی کی ضرورت نہیں ہے۔ نیٹ ورک کال بیک کو ضرور منسوخ کرنا چاہیے، ورنہ یہ Activity تباہ ہونے کے بعد بھی نظام میں رہے گا۔

مثال 2: View حوالہ جات کی صفائی کے ساتھ onDestroy Fragment

ایک Fragment onDestroyView میں View حوالہ جات کو صحیح طریقے سے صاف کرتا ہے، بندشوں (closures) کی وجہ سے میموری لیک کو روکتا ہے۔

class ProfileFragment : Fragment() {
    private var avatarView: ImageView? = null
    private var progressBar: ProgressBar? = null
    private val imageLoader = ImageLoader()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        avatarView = view.findViewById(R.id.avatar)
        progressBar = view.findViewById(R.id.progress)
        loadProfile()
    }

    private fun loadProfile() {
        viewLifecycleOwner.lifecycleScope.launch {
            try {
                progressBar?.visibility = View.VISIBLE
                val bitmap = imageLoader.load("https://example.com/avatar.png")
                avatarView?.setImageBitmap(bitmap)
            } finally {
                progressBar?.visibility = View.GONE
            }
        }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        avatarView = null
        progressBar = null
        imageLoader.cancel()
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d("ProfileFragment", "onDestroy: Fragment مکمل طور پر تباہ ہو گیا")
    }
}

onDestroyView میں، View حوالہ جات null پر سیٹ کیے جاتے ہیں — یہ میموری لیک کو روکتا ہے اگر imageLoader میں بندش avatarView کا حوالہ رکھتی ہے۔ Fragment خود اور اس کا ViewModel onDestroy تک زندہ رہتے ہیں۔ imageLoader.cancel() لوڈنگ منسوخ کر دیتا ہے اگر Fragment اسکرین چھوڑ دیتا ہے۔

مثال 3: onDestroy میں isFinishing کی جانچ

isFinishing() کا استعمال یہ فرق کرنے کی اجازت دیتا ہے کہ Activity صارف کے حکم سے ختم ہو رہی ہے یا دوبارہ تخلیق کے لیے۔

class AnalyticsActivity : AppCompatActivity() {
    private val analytics = Analytics()

    override fun onDestroy() {
        if (isFinishing) {
            Log.d("AnalyticsActivity", "Activity finish() کے ساتھ ختم ہو رہی ہے — تجزیہ بھیجا جا رہا ہے")
            analytics.sendSessionEnd()
        } else {
            Log.d("AnalyticsActivity", "Activity دوبارہ بنائی جا رہی ہے (گھماؤ/ترتیب) — تجزیہ نہیں بھیجا جا رہا")
        }
        super.onDestroy()
    }
}

isFinishing() کی جانچ تجزیہ، لاگنگ اور سیشن ڈیٹا کی صفائی کے لیے ایک اہم نمونہ ہے۔ گھماؤ کے دوران، سیشن ختم ہونے کے واقعات نہیں بھیجے جانے چاہئیں — صارف ابھی بھی ایپلیکیشن کے ساتھ کام کر رہا ہے۔ Google Analytics کے مطابق، غلط isFinishing() جانچ 40% جھوٹے سیشن واقعات کی وجہ ہے۔