Activity Lifecycle: mi ez, onCreate onStart onResume Androidban

Mi az Activity Lifecycle

Activity Lifecycle (Activity életciklusa) — egy véges állapotgép, amelyen az Android-alkalmazás minden képernyője áthalad a létrehozástól a teljes megsemmisítésig. Az Android rendszer ezt a folyamatot a felhasználói műveletek alapján kezeli: alkalmazás megnyitása, minimalizálás, képernyőforgatás, bejövő hívásra válaszolás, alkalmazások közötti váltás és befejezés.

Az életciklus megértése minden Android-fejlesztő számára elengedhetetlen, mivel a rendszer bármikor megsemmisítheti az Activity-t memóriahiány esetén — és az alkalmazásnak képesnek kell lennie az állapotának helyreállítására. A Google Android Vitals (2025) adatai szerint azok az alkalmazások, amelyek nem kezelik az állapotmentést az onSaveInstanceState()-ban, 42%-kal több összeomlást mutatnak az Activity újbóli létrehozásakor.

Az életciklus hat alapvető visszahívó metódust tartalmaz: onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(). Ezenkívül létezik az onRestart() metódus, amely az onStart() előtt hívódik meg, amikor az Activity visszatér a leállított állapotból. Minden metódusnak szigorúan meghatározott célja és végrehajtási ideje van — a rendszer sorrendben hívja meg őket, és a fejlesztő bármelyiket felülírhatja saját logikájának végrehajtásához.

A ciklus három kulcsfontosságú szakaszra osztható: teljes élettartam (onCreate → onDestroy), látható élettartam (onStart → onStop) és előtérbeli élettartam (onResume → onPause). E három szint megértése segít az inicializációs kód és az erőforrások felszabadításának helyes elosztásában.

Az Activity életciklusának metódusai

Minden életciklus-metódus szigorúan meghatározott feladatot lát el. A rendszer fix sorrendben hívja meg őket, és a fejlesztőnek csak azokat a metódusokat szabad felülírnia, amelyek az adott logikához szükségesek. Nem ajánlott közvetlenül meghívni az életciklus-metódusokat — ezt az Android Runtime végzi.

A hívások általános sémája

Tipikus sorrend az alkalmazás indításakor: onCreate → onStart → onResume. A „Vissza” gomb megnyomásakor: onPause → onStop → onDestroy. Minimalizáláskor: onPause → onStop, majd visszatéréskor: 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()
    }
}

Minden felülírt metódusnak meg kell hívnia a super verziót — enélkül a rendszer nem tudja helyesen befejezni az állapotok közötti átmenetet. Ezt a szabályt az Android Developers dokumentáció rögzíti, és az Android Studio lint szabályai ellenőrzik.

Az életciklus három szintje

Első szint — teljes élettartam (entire lifetime): az onCreate és onDestroy közötti intervallum. Itt történik az egyszeri inicializálás és a globális erőforrások végső felszabadítása. Második szint — látható élettartam (visible lifetime): az onStart és onStop között. Az Activity látható a képernyőn, de lehet, hogy részben eltakarja egy másik ablak. Harmadik szint — előtérbeli élettartam (foreground lifetime): az onResume és onPause között. Az Activity a feladatverem tetején található, és interakcióba lép a felhasználóval.

onCreate — Activity létrehozása

onCreate() — az Activity életciklusának első és egyetlen kötelező metódusa. A rendszer egyszer hívja meg az Activity példányának létrehozásakor. Ez a metódus fogadja a savedInstanceState: Bundle? paramétert, amely a korábban mentett állapotot tartalmazza, ha az Activity a megsemmisítés után újból létrejön — például képernyőforgatáskor.

Az onCreate-ben a következő feladatok hajtódnak végre: a felhasználói felület inicializálása a setContentView() segítségével a layout erőforrás átadásával, View elemek hozzákötése a findViewById()-on keresztül, adapterek beállítása RecyclerView és ViewPager számára, állapot helyreállítása a savedInstanceState-ből, ViewModel és LiveData inicializálása, kattintás- és gesztusfigyelők beállítása. A metódusnak a lehető leggyorsabban be kell fejeződnie — a hosszadalmas műveletek itt blokkolják az első képkocka megjelenítését, ami növeli az alkalmazás indítási idejét.

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()
    }
}

Ha az Activity első alkalommal jön létre, a savedInstanceState null értékű. A képernyőforgatás utáni újbóli létrehozáskor a Bundle az onSaveInstanceState()-ban mentett adatokat tartalmazza. A null ellenőrzése szabványos gyakorlat az UI helyes helyreállításához a felhasználó által bevitt adatok elvesztése nélkül.

onStart — megjelenés a képernyőn

Az onStart() közvetlenül az onCreate() után vagy az onRestart() után hívódik meg, amikor az Activity láthatóvá válik a felhasználó számára. Ebben az állapotban az Activity még nincs az előtérben, és nem tud interakcióba lépni a felhasználóval, de a felhasználói felülete már látható a képernyőn. Például az alkalmazás indításakor az onStart és onResume hívása között a rendszer megjeleníti a felület első képkockáját.

Az onStart metódusban általában a következő műveletek hajtódnak végre: animációk elindítása, amelyeknek addig kell működniük, amíg az Activity látható; BroadcastReceiver-ek hozzákötése; csatlakozás geolokációs szolgáltatásokhoz és érzékelőkhöz; adatok frissítése ViewModel-ből vagy Room-ból. Itt történik a Bound-szolgáltatásokhoz való kapcsolódás a bindService()-en keresztül is, ha az alkalmazás kliens-szerver architektúrát használ a folyamaton belül.

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)
}

Fontos szabály: az onStart-ben csatlakoztatott erőforrásokat az onStop-ban kell felszabadítani. Ez garantálja, hogy amikor az Activity nem látható a képernyőn, ne fogyasszon akkumulátort és rendszererőforrásokat. A Google Play Store ellenőrzi az alkalmazásokat a LocationListener és más rendszerszolgáltatások szivárgására a frissítések moderálásakor.

onResume — fókusz szerzése

onResume() — az az állapot, amelyben az Activity az előtérben van és készen áll a felhasználóval való interakcióra. Ez a képernyő munkaállapota: a rendszer átadja a beviteli fókuszt az Activity-nek, és minden érintési, billentyűzet-beviteli és gesztus esemény erre a képernyőre irányul. Az onResume metódus minden alkalommal meghívódik, amikor az Activity visszatér az előtérbe — egy másik Activity befejezése után, párbeszédablak bezárása után, a készülék feloldása után.

Az onResume-ben történik: az onPause-ben felfüggesztett animációk folytatása; a kamera és más exkluzív erőforrások megnyitása; érzékelőfigyelők regisztrálása (gyorsulásmérő, giroszkóp); időzítők és stopper indítása az UI-hoz; a képernyő tartalmának frissítése aktuális adatokkal. Az onResume / onPause párban olyan erőforrásokkal dolgozunk, amelyeknek csak fókusz esetén szabad aktívnak lenniük — például folyamatos beszédfelismerés vagy videórögzítés.

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)
}

Az onStart és onResume közötti különbség jelentős: az Activity lehet látható (onStart), de nem aktív (onResume) — például amikor egy felugró párbeszédablak vagy átlátszó zárolási képernyő jelenik meg fölötte. Pontosan az onResume-ben, nem az onStart-ben kell megnyitni azokat az exkluzív erőforrásokat, amelyek monopol hozzáférést igényelnek.

onPause — fókusz elvesztése

Az onPause() akkor hívódik meg, amikor az Activity elveszti a beviteli fókuszt, de részben látható marad. Tipikus forgatókönyvek: párbeszédablak megnyitása, a „Legutóbbi alkalmazások” gomb megnyomása, bejövő hívás, a „Kezdőlap” gomb megnyomása (ebben az esetben az onPause után onStop következik). Az onPause metódus az utolsó megbízható hely azoknak az adatoknak a mentésére, amelyeket a felhasználónak nem szabad elveszítenie.

Az onPause-ben történik: e-mail-vázlatok és beviteli űrlapok mentése Room-ba vagy SharedPreferences-be; animációk és videólejátszás leállítása; a kamera bezárása és a monopol erőforrások felszabadítása; költséges műveletek megszakítása, amelyek nem kritikusak a háttér számára. Az onPause metódusnak kevesebb mint 100 ezredmásodperc alatt kell befejeződnie — a rendszer blokkolja a következő Activity-re való átmenetet, amíg az onPause vissza nem adja a vezérlést, és a határérték túllépése ANR-hez (Application Not Responding) vezet.

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

Fontos: az onPause az UI szálon hajtódik végre, ezért minden blokkoló műveletet, mint például a Room-on keresztüli adatbázis-írás szinkron lekérdezéssel, aszinkronra (korutin) kell cserélni vagy háttérszálon kell végrehajtani. Használja az apply()-t a commit() helyett a SharedPreferences esetében — az apply aszinkron módon írja az adatokat, és nem blokkolja az UI szálat.

onStop — elrejtés a képernyőről

Az onStop() akkor hívódik meg, amikor az Activity már nem látható a felhasználó számára. Ez a következő esetekben történik: az Activity-t teljesen eltakarja egy másik Activity; a felhasználó megnyomta a „Kezdőlap” gombot vagy átváltott egy másik alkalmazásra; az Activity befejeződik (ezt követően az onDestroy hívódik meg). Az onStop állapotban az Activity a memóriában marad, és megőrzi minden mezőjét — nem semmisült meg, de nem is aktív.

Az onStop-ban történik: az onStart-ben regisztrált BroadcastReceiver-ekről való leiratkozás; a Bound-szolgáltatásokról való leválás; a LocationListener, SensorListener és más rendszerfigyelők felszabadítása; hosszú háttérműveletek leállítása, amelyekre nincs szükség, amikor az alkalmazás rejtve van; az aktuális UI állapot Bundle-be írása az onSaveInstanceState()-on keresztül, ha ez nem történt meg az onPause-ban.

override fun onStop() {
    super.onStop()
    unregisterReceiver(connectivityReceiver)
    unbindService(serviceConnection)
    if (isChangingConfigurations()) {
        Log.d("Lifecycle", "Az Activity újból létrejön a konfiguráció miatt")
    }
}

A rendszer megsemmisítheti az Activity-t az onStop állapotban az onDestroy meghívása nélkül memóriahiány esetén. Ezért az összes kritikus adatot menteni kell az onStop-ba való átmenet előtt. Az isChangingConfigurations() jelző segítségével megállapítható, hogy az onStop hívása összefügg-e a képernyő forgatásával — ebben az esetben az Activity újból létrejön, nem pedig befejeződik.

onDestroy — Activity megsemmisítése

onDestroy() — az életciklus utolsó metódusa, amely az Activity teljes megsemmisítése előtt hívódik meg. A rendszer két esetben hívja meg az onDestroy-t: az Activity a finish() meghívásával fejeződik be, vagy a felhasználó megnyomja a „Vissza” gombot; az Activity-t a rendszer megsemmisíti konfigurációs változás (például képernyőforgatás) miatt, és újból létrejön. Az onDestroy metódus lehetővé teszi az erőforrások végső tisztítását: szálak és korutinok leválasztása, véglegesen nyitott kurzorok és socketek bezárása, natív memória felszabadítása NDK-n keresztül.

override fun onDestroy() {
    super.onDestroy()
    backgroundJob.cancel()
    dbHelper.close()
    if (isFinishing) {
        Log.d("Lifecycle", "Az Activity véglegesen befejeződik")
    } else {
        Log.d("Lifecycle", "Az Activity újból létrejön")
    }
}

Fontos megjegyzés: az onDestroy nem garantált, ha az alkalmazás folyamatát a rendszer megöli (out-of-memory kill). Ezért nem lehet az onDestroy-ra hagyatkozni az adatok mentéséhez — ezt a feladatot az onPause-ban vagy az onStop-ban kell megoldani. Az isFinishing tulajdonság lehetővé teszi az Activity finish()-en keresztüli befejezésének megkülönböztetését a konfigurációs változás miatti újbóli létrehozástól.

onRestart — visszatérés a leállított állapotból

Az onRestart() az onStart() előtt hívódik meg, amikor az Activity visszatér a leállított állapotból (onStop) az előtérbe. Ez akkor történik, amikor a felhasználó újra megnyitja az alkalmazást a „Legutóbbiak” menüből, vagy visszatér az Activity-hez a „Vissza” gomb megnyomásával egy gyermekképernyőn. Az onRestart metódus lehetővé teszi az onCreate-től eltérő logika végrehajtását — például azon adatok frissítését, amelyek megváltozhattak, amíg az Activity rejtve volt.

override fun onRestart() {
    super.onRestart()
    refreshDataFromNetwork()
    Log.d("Lifecycle", "Az Activity újraindul a veremből")
}

Tipikus forgatókönyv: a felhasználó megnyitotta az alkalmazást, átváltott egy másik feladatra, majd egy óra múlva visszatért. Az onRestart-ban az alkalmazás ellenőrizheti az adatok aktualitását, és ha sok idő telt el, felajánlhatja a tartalom újratöltését. Ez javítja a felhasználói élményt és csökkenti az elavult információk megjelenítésének valószínűségét.

Képernyőforgatás és állapotmentés

Képernyőforgatás — az Activity újbóli létrehozásának leggyakoribb forgatókönyve. Alapértelmezés szerint az Android minden tájolásváltozáskor megsemmisíti az aktuális Activity-t, és újat hoz létre. Ha az állapot nem kerül mentésre, a felhasználó elveszíti az összes bevitt adatot. Ehhez az Android két mechanizmust biztosít: onSaveInstanceState() a szerializálható adatokhoz és ViewModel a konfigurációs változásokat túlélő adatokhoz.

onSaveInstanceState és onRestoreInstanceState

Az onSaveInstanceState() az Activity megsemmisítése előtt hívódik meg az ideiglenes állapot mentésére. A mentett adatok az onCreate-be a savedInstanceState paraméteren keresztül, valamint az onRestoreInstanceState() metódusba kerülnek, amely az onStart után hívódik meg. A Bundle méretkorlátozással rendelkezik — körülbelül 500 KB, ezért a nagy adatmennyiségeket (például bitképeket) a ViewModel-en keresztül mentik.

<!-- AndroidManifest.xml — tájolás rögzítése -->
<activity android:name=".MainActivity"
    android:configChanges="orientation|screenSize" />

A tájolás rögzítése az android:configChanges segítségével megakadályozza az Activity újbóli létrehozását, de antimintának számít, ha az alkalmazásnak mindkét tájolást támogatnia kell. A modern Google-ajánlás — használja a ViewModel-t az onSaveInstanceState-val együtt a felhasználó által az UI-ba bevitt adatokhoz.

Fragment életciklusa

A Fragment saját életciklussal rendelkezik, hasonlóan az Activity-hez, de kiegészítő metódusokkal: onAttach, onCreate, onCreateView, onViewCreated, onStart, onResume, onPause, onStop, onDestroyView, onDestroy, onDetach. A Fragment mindig egy Activity-n belül létezik, és életciklusa a konténer Activity életciklusához van kötve. Ha az Activity megsemmisül, a Fragment követi.

A fő különbség: a Fragment nemcsak a komponens állapotát, hanem a View hierarchiát is kezeli. Az onCreateView metódus visszaadja a fragment gyökér View-ját, az onDestroyView pedig megsemmisíti ezt a hierarchiát. Ez lehetővé teszi a Fragment számára, hogy túlélje az Activity újbóli létrehozását képernyőforgatáskor: a Fragment megmarad, a View-ja pedig újból létrejön az onCreateView-ben.

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)
    }
}

Az onCreate és onCreateView közötti különbség megértése kritikus fontosságú: az onCreate egyszer hívódik meg a Fragment életében (még a View újbóli létrehozásakor is), míg az onCreateView minden alkalommal meghívódik, amikor a Fragment létrehozza vagy újból létrehozza a View hierarchiáját. Az adatok inicializálása az onCreate-ben, az UI hozzákötése pedig az onViewCreated-ben történik.

LifecycleObserver és Jetpack

LifecycleObserver — az Android Jetpack könyvtár komponense, amely lehetővé teszi az életciklus-változásokra való reagálást anélkül, hogy metódusokat kellene felülírni az Activity-ben vagy Fragment-ben. Ahelyett, hogy kódot duplikálna minden életciklus-metódusban, a fejlesztő létrehoz egy külön osztályt @OnLifecycleEvent annotációkkal, és átadja azt a lifecycle.addObserver()-nak.

A Jetpack emellett biztosítja a LifecycleOwner osztályt — egy interfészt, amelyet az AppCompatActivity és a Fragment implementál. Bármely objektum, amely implementálja a LifecycleOwner-t, kezelheti a LiveData-előfizetéseket, a korutinokat a lifecycleScope-on keresztül és a WorkManager munkáját az életciklushoz kötve. Ez a modern, MVVM-en és Jetpack-en alapuló Android-architektúra sarokköve.

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

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

// Az Activity-ben:
lifecycle.addObserver(MyLocationObserver(this))

A DefaultLifecycleObserver használata leegyszerűsíti a tesztelést, csökkenti a kódsokszorozást, és az életciklus-logikát újrafelhasználhatóvá teszi a különböző képernyők között. Ez a manuális onStart/onStop felülírás modern alternatívája minden Activity-ben. Az IT Sectr által fejlesztett Android-alkalmazásokban a LifecycleObserver-t használjuk geolokációhoz, Bluetooth-kereséshez és analitikához — ez 30–40%-kal csökkenti a boilerplate kód mennyiségét.