Activity Lifecycle: ما هو، onCreate onStart onResume في Android

ما هو Activity Lifecycle

Activity Lifecycle (دورة حياة Activity) هي آلة حالات يمر بها كل شاشة من تطبيق Android منذ لحظة الإنشاء حتى التدمير الكامل. يدير نظام Android هذه العملية بناءً على إجراءات المستخدم: فتح التطبيق، التصغير، تدوير الشاشة، الرد على مكالمة واردة، التبديل بين التطبيقات وإنهاء العمل.

فهم دورة الحياة ضروري لكل مطور Android، حيث يمكن للنظام تدمير Activity في أي لحظة عند نقص الذاكرة — ويجب على التطبيق استعادة حالته بشكل صحيح. وفقاً لبيانات Google Android Vitals (2025)، التطبيقات التي لا تتعامل مع حفظ الحالة في onSaveInstanceState() تظهر 42% أكثر من الأعطال عند إعادة إنشاء Activity.

تتضمن دورة الحياة ست طرق استدعاء رئيسية: onCreate() و onStart() و onResume() و onPause() و onStop() و onDestroy(). بالإضافة إلى ذلك، توجد طريقة onRestart() التي تُستدعى قبل onStart() عندما تعود Activity من الحالة الموقوفة. لكل طريقة غرض ووقت تنفيذ محدد بدقة — يستدعيها النظام بالتسلسل، ويمكن للمطور إعادة تعريف أي منها لتنفيذ منطقه الخاص.

يمكن تقسيم الدورة إلى ثلاث مراحل رئيسية: العمر الكامل (onCreate ← onDestroy)، العمر المرئي (onStart ← onStop) والعمر في المقدمة (onResume ← onPause). فهم هذه المستويات الثلاثة يساعد في توزيع كود التهيئة وتحرير الموارد بشكل صحيح.

طرق دورة حياة Activity

كل طريقة من دورة الحياة تؤدي مهمة محددة بدقة. يستدعيها النظام بترتيب ثابت، ويجب على المطور إعادة تعريف فقط الطرق اللازمة للمنطق المحدد. لا يُنصح باستدعاء طرق دورة الحياة مباشرة — فهذا من مسؤولية Android Runtime.

المخطط العام للاستدعاءات

التسلسل النموذجي عند تشغيل التطبيق: onCreate ← onStart ← onResume. عند الضغط على زر الرجوع: onPause ← onStop ← onDestroy. عند التصغير: onPause ← onStop، ثم عند العودة: onRestart ← onStart ← onResume.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }

    override fun onStart() {
        super.onStart()
    }

    override fun onResume() {
        super.onResume()
    }

    override fun onPause() {
        super.onPause()
    }

    override fun onStop() {
        super.onStop()
    }

    override fun onDestroy() {
        super.onDestroy()
    }

    override fun onRestart() {
        super.onRestart()
    }
}

كل طريقة معاد تعريفها يجب أن تستدعي نسختها super — بدون ذلك، لن يتمكن النظام من إكمال انتقال الحالة بشكل صحيح. هذه القاعدة مثبتة في وثائق Android Developers ويتم التحقق منها بواسطة قواعد lint في Android Studio.

ثلاثة مستويات من دورة الحياة

المستوى الأول — العمر الكامل: الفاصل بين onCreate و onDestroy. هنا يتم التهيئة لمرة واحدة والتحرير النهائي للموارد العالمية. المستوى الثاني — العمر المرئي: بين onStart و onStop. Activity مرئية على الشاشة ولكن قد تكون مغطاة جزئياً بنافذة أخرى. المستوى الثالث — العمر في المقدمة: بين onResume و onPause. Activity في قمة مكدس المهام وتتفاعل مع المستخدم.

onCreate — إنشاء Activity

onCreate() — أول وأهم طريقة إلزامية في دورة حياة Activity. يستدعيها النظام مرة واحدة عند إنشاء مثيل Activity. تقبل هذه الطريقة معامل savedInstanceState: Bundle? الذي يحتوي على الحالة المحفوظة سابقاً إذا كانت Activity تُعاد إنشاؤها بعد التدمير — على سبيل المثال، عند تدوير الشاشة.

داخل onCreate تُنفذ المهام التالية: تهيئة واجهة المستخدم عبر setContentView() مع مورد التخطيط، ربط عناصر View عبر findViewById()، إعداد محولات RecyclerView و ViewPager، استعادة الحالة من savedInstanceState، تهيئة ViewModel و LiveData، إعداد مستمعي النقر والإيماءات. يجب أن يكتمل الطريقة في أسرع وقت ممكن — العمليات الطويلة هنا تمنع عرض الإطار الأول، مما يزيد من وقت بدء التطبيق.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_profile)

    val userNameText: TextView = findViewById(R.id.user_name)
    val loadButton: Button = findViewById(R.id.load_button)

    if (savedInstanceState != null) {
        userNameText.text = savedInstanceState.getString("user_name")
    }

    loadButton.setOnClickListener {
        loadUserProfile()
    }
}

إذا كانت Activity تُنشأ لأول مرة، فإن savedInstanceState يساوي null. عند إعادة الإنشاء بعد تدوير الشاشة، يحتوي Bundle على البيانات المحفوظة في onSaveInstanceState(). التحقق من null هو ممارسة قياسية لاستعادة واجهة المستخدم بشكل صحيح دون فقدان البيانات التي أدخلها المستخدم.

onStart — الظهور على الشاشة

onStart() يُستدعى مباشرة بعد onCreate() أو بعد onRestart()، عندما تصبح Activity مرئية للمستخدم. في هذه الحالة، Activity ليست بعد في المقدمة ولا يمكنها التفاعل مع المستخدم، لكن واجهة المستخدم الخاصة بها مرئية بالفعل على الشاشة. على سبيل المثال، عند تشغيل التطبيق، يقوم النظام بعرض الإطار الأول للواجهة بين استدعاء onStart و onResume.

في طريقة onStart تُنفذ عادةً الإجراءات التالية: بدء الرسوم المتحركة التي يجب أن تعمل طالما Activity مرئية؛ ربط مستقبلات البث (BroadcastReceiver)؛ الاتصال بخدمات تحديد المواقع وأجهزة الاستشعار؛ تحديث البيانات من ViewModel أو Room. هنا أيضاً يتم ربط الخدمات المرتبطة عبر bindService() إذا كان التطبيق يستخدم بنية خادم-عميل داخل العملية.

override fun onStart() {
    super.onStart()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.requestLocationUpdates(
        LocationManager.GPS_PROVIDER,
        5000L,
        10f,
        locationListener
    )
}

override fun onStop() {
    super.onStop()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.removeUpdates(locationListener)
}

قاعدة مهمة: الموارد المتصلة في onStart يجب تحريرها في onStop. هذا يضمن أنه عندما لا تكون Activity مرئية على الشاشة، فإنها لا تستهلك البطارية وموارد النظام. يتحقق Google Play Store من التطبيقات بحثاً عن تسرب LocationListener وخدمات النظام الأخرى عند مراجعة التحديثات.

onResume — الحصول على التركيز

onResume() — الحالة التي تكون فيها Activity في المقدمة وجاهزة للتفاعل مع المستخدم. هذه هي حالة العمل للشاشة: ينقل النظام تركيز الإدخال إلى Activity، ويتم توجيه جميع أحداث اللمس وإدخال لوحة المفاتيح والإيماءات إلى هذه الشاشة. تُستدعى طريقة onResume في كل مرة تعود فيها Activity إلى المقدمة — بعد انتهاء Activity أخرى، بعد إغلاق مربع حوار، أو بعد فتح الجهاز.

في onResume تُنفذ: استئناف الرسوم المتحركة التي تم إيقافها مؤقتاً في onPause؛ فتح الكاميرا والموارد الحصرية الأخرى؛ تسجيل مستمعي أجهزة الاستشعار (مقياس التسارع، الجيروسكوب)؛ بدء الموقتات وساعة الإيقاف لواجهة المستخدم؛ تحديث محتوى الشاشة بالبيانات الحالية. يُستخدم زوج onResume/onPause للموارد التي يجب أن تكون نشطة فقط عند وجود التركيز — على سبيل المثال، التعرف المستمر على الكلام أو التقاط الفيديو.

override fun onResume() {
    super.onResume()
    cameraHolder.openCamera()
    animator.resume()
    sensorManager.registerListener(
        stepCounter,
        sensorManager.getDefaultSensor(Sensor.TYPE_STEP_COUNTER),
        SensorManager.SENSOR_DELAY_NORMAL
    )
}

override fun onPause() {
    super.onPause()
    cameraHolder.closeCamera()
    animator.pause()
    sensorManager.unregisterListener(stepCounter)
}

الفرق بين onStart و onResume جوهري: يمكن أن تكون Activity مرئية (onStart) ولكن غير نشطة (onResume) — على سبيل المثال، عند عرض مربع حوار منبثق أو شاشة قفل شفافة فوقها. في onResume وليس في onStart يجب فتح الموارد الحصرية التي تتطلب وصولاً حصرياً.

onPause — فقدان التركيز

onPause() يُستدعى عندما تفقد Activity تركيز الإدخال ولكن تبقى مرئية جزئياً. السيناريوهات النموذجية: فتح مربع حوار، الضغط على زر التطبيقات الأخيرة، مكالمة واردة، الضغط على زر الرئيسية (في هذه الحالة سيتبع onPause onStop). طريقة onPause هي آخر مكان موثوق لحفظ البيانات التي لا يجب أن يفقدها المستخدم.

في onPause تُنفذ: حفظ مسودات البريد الإلكتروني ونماذج الإدخال في Room أو SharedPreferences؛ إيقاف الرسوم المتحركة وتشغيل الفيديو؛ إغلاق الكاميرا وتحرير الموارد الحصرية؛ إلغاء العمليات المكلفة غير الحرجة في الخلفية. يجب أن تكتمل طريقة onPause في أقل من 100 مللي ثانية — يحجب النظام الانتقال إلى Activity التالية حتى يعيد onPause التحكم، وتجاوز الحد يؤدي إلى ANR (Application Not Responding).

override fun onPause() {
    super.onPause()
    val editor = SharedPreferences.Manager ...
    editor.putString("draft_text", draftEditText.text.toString())
    editor.apply()
    videoView.pause()
    cameraHolder.release()
}

مهم: onPause يُنفذ في سلسلة واجهة المستخدم، لذلك يجب استبدال أي عمليات حظر مثل الكتابة في قاعدة البيانات عبر Room باستعلام متزامن بعمليات غير متزامنة (coroutines) أو تنفيذها في سلسلة خلفية. استخدم apply() بدلاً من commit() لـ SharedPreferences — apply يكتب البيانات بشكل غير متزامن ولا يحجب سلسلة واجهة المستخدم.

onStop — الاختفاء من الشاشة

onStop() يُستدعى عندما تتوقف Activity عن أن تكون مرئية للمستخدم. يحدث هذا في الحالات التالية: Activity مغطاة بالكامل بواسطة Activity أخرى؛ ضغط المستخدم على زر الرئيسية أو التبديل إلى تطبيق آخر؛ Activity تنتهي (سيتم استدعاء onDestroy بعد ذلك). في حالة onStop، تبقى Activity في الذاكرة وتحتفظ بجميع حقولها — لم يتم تدميرها ولكنها غير نشطة أيضاً.

في onStop تُنفذ: إلغاء تسجيل BroadcastReceiver المسجلين في onStart؛ فصل الخدمات المرتبطة؛ تحرير LocationListener و SensorListener ومستمعي النظام الآخرين؛ إيقاف عمليات الخلفية الطويلة غير الضرورية عند إخفاء التطبيق؛ كتابة حالة واجهة المستخدم الحالية في Bundle عبر onSaveInstanceState() إذا لم يتم ذلك في onPause.

override fun onStop() {
    super.onStop()
    unregisterReceiver(connectivityReceiver)
    unbindService(serviceConnection)
    if (isChangingConfigurations()) {
        Log.d("Lifecycle", "يتم إعادة إنشاء Activity بسبب التكوين")
    }
}

يمكن للنظام تدمير Activity في حالة onStop دون استدعاء onDestroy عند نقص الذاكرة. لذلك يجب حفظ جميع البيانات الحرجة قبل الانتقال إلى onStop. يسمح العلم isChangingConfigurations() بتحديد ما إذا كان استدعاء onStop مرتبطاً بتدوير الشاشة — في هذه الحالة، سيتم إعادة إنشاء Activity، وليس إنهاؤها.

onDestroy — تدمير Activity

onDestroy() — آخر طريقة في دورة الحياة تُستدعى قبل التدمير الكامل لـ Activity. يستدعي النظام onDestroy في حالتين: Activity تنتهي باستدعاء finish() أو يضغط المستخدم على زر الرجوع؛ Activity تُدمر بواسطة النظام بسبب تغيير التكوين (على سبيل المثال، تدوير الشاشة) وسيتم إنشاؤها من جديد. تسمح طريقة onDestroy بتنظيف الموارد النهائي: فك ربط السلاسل والكوروتينات، إغلاق المؤشرات والمآخذ المفتوحة بشكل دائم، تحرير الذاكرة الأصلية عبر NDK.

override fun onDestroy() {
    super.onDestroy()
    backgroundJob.cancel()
    dbHelper.close()
    if (isFinishing) {
        Log.d("Lifecycle", "Activity تنتهي بشكل دائم")
    } else {
        Log.d("Lifecycle", "سيتم إعادة إنشاء Activity")
    }
}

ملاحظة مهمة: لا يُضمن استدعاء onDestroy إذا تم قتل عملية التطبيق بواسطة النظام (out-of-memory kill). لذلك لا يمكن الاعتماد على onDestroy لحفظ البيانات — هذه المهمة تُحل في onPause أو onStop. الخاصية isFinishing تسمح بتمييز إنهاء Activity عبر finish() عن إعادة الإنشاء عند تغيير التكوين.

onRestart — العودة من الحالة الموقوفة

onRestart() يُستدعى قبل onStart() عندما تعود Activity من الحالة الموقوفة (onStop) إلى المقدمة. يحدث هذا عندما يعيد المستخدم فتح التطبيق من قائمة التطبيقات الأخيرة أو يعود إلى Activity بالضغط على زر الرجوع في شاشة فرعية. تسمح طريقة onRestart بتنفيذ منطق مختلف عن onCreate — على سبيل المثال، تحديث البيانات التي قد تغيرت بينما كانت Activity مخفية.

override fun onRestart() {
    super.onRestart()
    refreshDataFromNetwork()
    Log.d("Lifecycle", "يتم إعادة تشغيل Activity من المكدس")
}

السيناريو النموذجي: فتح المستخدم التطبيق، التبديل إلى مهمة أخرى، والعودة بعد ساعة. في onRestart، يمكن للتطبيق التحقق من حداثة البيانات، وإذا مر وقت طويل، اقتراح إعادة تحميل المحتوى. هذا يحسن تجربة المستخدم ويقلل احتمال عرض معلومات قديمة.

تدوير الشاشة وحفظ الحالة

تدوير الشاشة هو السيناريو الأكثر شيوعاً لإعادة إنشاء Activity. بشكل افتراضي، يدمر Android Activity الحالية وينشئ جديدة مع كل تغيير في الاتجاه. إذا لم يتم حفظ الحالة، سيفقد المستخدم جميع البيانات المدخلة. يوفر Android آليتين لهذا: onSaveInstanceState() للبيانات القابلة للتسلسل و ViewModel للبيانات التي تنجو من تغييرات التكوين.

onSaveInstanceState و onRestoreInstanceState

onSaveInstanceState() يُستدعى قبل تدمير Activity لحفظ الحالة المؤقتة. تُمرر البيانات المحفوظة إلى onCreate عبر معامل savedInstanceState وإلى طريقة onRestoreInstanceState() التي تُستدعى بعد onStart. Bundle له حد حجم — حوالي 500 كيلوبايت، لذلك يتم حفظ كميات كبيرة من البيانات (مثل الصور النقطية) عبر ViewModel.

<!-- AndroidManifest.xml — تثبيت الاتجاه -->
<activity android:name=".MainActivity"
    android:configChanges="orientation|screenSize" />

تثبيت الاتجاه عبر android:configChanges يمنع إعادة إنشاء Activity، لكنه يعتبر نمطاً معادياً إذا كان التطبيق يجب أن يدعم كلا الاتجاهين. التوصية الحديثة من Google هي استخدام ViewModel مع onSaveInstanceState للبيانات التي يدخلها المستخدم في واجهة المستخدم.

دورة حياة Fragment

Fragment له دورة حياة خاصة به، مشابهة لـ Activity ولكن مع طرق إضافية: onAttach و onCreate و onCreateView و onViewCreated و onStart و onResume و onPause و onStop و onDestroyView و onDestroy و onDetach. Fragment موجود دائماً داخل Activity، ودورة حياته مرتبطة بدورة حياة Activity الحاوية. إذا تم تدمير Activity، يتبعه Fragment.

الفرق الرئيسي: Fragment لا يدير فقط حالة المكون ولكن أيضاً تسلسل View. طريقة onCreateView تُرجع الجذر View للـ Fragment، و onDestroyView تدمر هذا التسلسل. هذا يسمح لـ Fragment بالنجاة من إعادة إنشاء Activity عند تدوير الشاشة: يتم الاحتفاظ بـ Fragment وإعادة إنشاء View في onCreateView.

class ProfileFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        return inflater.inflate(R.layout.fragment_profile, container, false)
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        val avatarImage: ImageView = view.findViewById(R.id.avatar_image)
        loadAvatar(avatarImage)
    }
}

فهم الفرق بين onCreate و onCreateView أمر بالغ الأهمية: onCreate يُستدعى مرة واحدة طوال عمر Fragment (حتى عند إعادة إنشاء View)، بينما onCreateView يُستدعى في كل مرة ينشئ أو يعيد إنشاء Fragment تسلسل View الخاص به. تتم تهيئة البيانات في onCreate بينما يتم ربط واجهة المستخدم في onViewCreated.

LifecycleObserver و Jetpack

LifecycleObserver — مكون من مكتبة Android Jetpack يسمح بالتفاعل مع تغييرات دورة الحياة دون إعادة تعريف الطرق في Activity أو Fragment. بدلاً من تكرار الكود في كل طريقة من دورة الحياة، ينشئ المطور فئة منفصلة مع تعليقات @OnLifecycleEvent ويمررها إلى lifecycle.addObserver().

يوفر Jetpack أيضاً واجهة LifecycleOwner التي تنفذها AppCompatActivity و Fragment. أي كائن ينفذ LifecycleOwner يمكنه إدارة اشتراكات LiveData والكوروتينات عبر lifecycleScope و WorkManager المرتبطة بدورة الحياة. هذه حجر الزاوية في بنية Android الحديثة القائمة على MVVM و Jetpack.

class MyLocationObserver(private val context: Context) : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        startLocationUpdates()
    }

    override fun onStop(owner: LifecycleOwner) {
        stopLocationUpdates()
    }
}

// في Activity:
lifecycle.addObserver(MyLocationObserver(this))

استخدام DefaultLifecycleObserver يبسط الاختبار، ويقلل من تكرار الكود، ويجعل منطق دورة الحياة قابلاً لإعادة الاستخدام عبر شاشات مختلفة. هذا بديل حديث لإعادة تعريف onStart/onStop يدوياً في كل Activity. في تطبيقات Android التي طورتها IT Sectr، نطبق LifecycleObserver لتحديد المواقع ومسح Bluetooth والتحليلات — وهذا يقلل حجم كود boilerplate بنسبة 30-40%.