onStop — mi ez, az Activity elrejtése az Android életciklusában

Mi az onStop Androidban?

onStop — az AppCompatActivity osztály (és elődje, az Activity) callback metódusa, amelyet az Android operációs rendszer hív meg, amikor az Activity teljesen láthatatlanná válik a felhasználó számára. Ekkor az Activity-t egy másik Activity, párbeszédablak, rendszerindító vagy zárolási képernyő takarja el. Az életciklus szempontjából az onStop az onPause után következik, és jelzi, hogy az Activity már nem látható a képernyőn, bár maga az Activity objektum és annak állapota a memóriában marad.

Amikor az Activity Stopped (megállított) állapotba kerül, megtartja állapotát a RAM-ban — minden mező, View-hierarchia és ViewModel elérhető marad. Ez különbözteti meg a Stopped-ot a megsemmisített (Destroyed) állapottól, ahol az Activity teljesen eltávolításra kerül. A System UI megölheti a Stopped állapotban lévő alkalmazás folyamatát memóriahiány esetén — ez az úgynevezett process death. A fejlesztő köteles a kritikus adatokat (piszkozatok, görgetési pozíció) elmenteni az onSaveInstanceState()-ben, amely az onStop előtt hívódik meg, hogy garantálja a helyreállítást a folyamat megszakadásakor.

Az Android Compatibility Definition Document (CDD) 14+ verziójának specifikációja szerint a Stopped állapotban lévő folyamat alacsonyabb prioritással rendelkezik az OOM Killer általi megszakításkor — alacsonyabb, mint a Background fázisban lévő folyamatok, de magasabb, mint a gyorsítótárazott folyamatok. A Google statisztikái szerint a folyamatmegszakítások 68%-a akkor történik, amikor az Activity Stopped állapotban van, nem Paused.

Mikor hívódik meg az onStop: forgatókönyvek és sorrend

Az onStop az Activity teljes láthatóságának elvesztésekor hívódik meg, függetlenül az okától: új Activity indítása a jelenlegi felett, az alkalmazás minimalizálása (Home gomb), képernyőzárolás, bejövő hívás vagy rendszerpárbeszédablak megnyitása. Mindezekben az esetekben az Activity először onPause-t (részleges fókuszvesztés), majd onStop-ot (teljes láthatóságvesztés) kap.

Az onStop meghívásának fő forgatókönyvei:

• Új Activity indítása a jelenlegi felett — a jelenlegi Activity onPause-t, majd onStop-ot kap; az új Activity onCreate → onStart → onResume-ot jár végig.
• Alkalmazás minimalizálása (Home) — az Activity 200–300 ms alatt onPause → onStop állapotba kerül, a memóriában Stopped állapotban marad.
• Képernyőzárolás — a rendszer onPause → onStop-ot hív, mivel a zárolási képernyő teljesen eltakarja az Activity-t.
• Bejövő hívás — a telefon Activity (Dialer) elindul felette, a jelenlegi Activity onStop-ba kerül.
• Váltás másik alkalmazásra (Recent Apps) — az Activity elrejtőzik, onStop-ot kap, de a folyamat gyorsítótárban marad.

Fontos megérteni, hogy az onStop nem hívódik meg a képernyő elforgatásakor — ebben az esetben az Activity megsemmisül (onPause → onStop → onDestroy) és újra létrejön (onCreate → onStart → onResume). Kivétel — az android:configChanges="orientation" jelző a manifestben, amelynél az Activity nem jön létre újra, hanem az onConfigurationChanged() hívást kapja.

onStop az Activity életciklusában

Az onStop központi helyet foglal el az Activity életciklusának sorrendjében a látható és láthatatlan állapot között. Teljes sorrend: onCreate → onStart → onResume → (aktív állapot) → onPause → onStop → onDestroy (vagy onRestart → onStart → onResume visszatéréskor).

*Stopped állapotban az Activity a memóriában marad, de erőforráshiány esetén a rendszer megölheti. A Stopped folyamatok megszakításának prioritása — utolsó előtti, csak az üres gyorsítótárazott folyamatokénál magasabb.

onStop és onSaveInstanceState: A rendszer az onSaveInstanceState(Bundle)-t az onStop előtt hívja meg a dinamikus UI-állapot mentésére. A fejlesztő felülírja ezt a metódust, hogy a Bundle-ben elmentse a beviteli mezők értékeit, a RecyclerView pozícióját, a kiválasztott elemeket. Még ha az Activity nem is semmisül meg (a felhasználó csak minimalizálta és visszatért), a Bundle átadásra kerül az onCreate-nek konfigurációs változások esetén. A Google csak az átmeneti UI-állapot mentését javasolja — nem a repository vagy ViewModel adatait, amelyek az Activity-n kívül élnek.

Milyen erőforrásokat szabadítsunk fel az onStop-ban

Az onStop-ban a fejlesztő köteles felszabadítani minden olyan erőforrást, amely nem szükséges, amikor az Activity nem látható. Ez csökkenti az akkumulátor, processzor és memória terhelését, valamint megakadályozza az ANR-t az aktivitásra való visszatéréskor.

Mit szabadítsunk fel az onStop-ban:

• Animációk és transitions — állítsa le az ObjectAnimator, ValueAnimator, ViewPropertyAnimator elemeket. Egy láthatatlan Activity futó animációja a GPU-ciklusok pazarlása.
• Érzékelők (Sensors) — iratkozzon le a SensorManager-ről (gyorsulásmérő, giroszkóp, magnetométer). Az érzékelők még rejtett Activity esetén is fogyasztanak energiát.
• Kamera és mikrofon — szabadítsa fel a Camera2 vagy CameraX eszközt, állítsa le a MediaRecorder-t. A kamera aktívan hagyása rejtett Activity esetén a Google Play irányelvei által tiltott.
• LocationListener — iratkozzon le a FusedLocationProviderClient vagy LocationManager szolgáltatásról. A geolokáció a legenergiaigényesebb erőforrás.
• Network listeners — zárja be a WebSocket-et, szakítsa meg a HTTP-kéréseket, amelyek nem szükségesek a háttérben.
• MediaPlayer és ExoPlayer — szüneteltesse vagy állítsa le, ha a lejátszásnak nem szabad folytatódnia a háttérben.

Mit ne tegyen az onStop-ban: Ne végezzen hosszú műveleteket — nagy adatok mentése adatbázisba, hálózati kérések, összetett számítások. Az onStop a fő szálon fut, és blokkolja az Activity-re való visszatérést. Hosszú műveletekhez használjon WorkManager-t késleltetéssel vagy korutinokat a viewModelScope-ban. Ne szabadítsa fel a ViewModel erőforrásait — a ViewModel túléli az onStop-ot, és visszatéréskor használatba kerül.

Különbség az onStop és onPause között

Az onPause és onStop a láthatóságvesztés mértékében és a kötelező műveletek mennyiségében különböznek. Az onPause részleges fókuszvesztéskor hívódik meg (például párbeszédablak vagy rendszermenü megnyitásakor), az onStop — teljes láthatóságvesztéskor. Ez a különbség fontos annak eldöntésében, hogy mely erőforrásokat szabadítsuk fel az egyes szakaszokban.

Általános szabály: az onPause-ban szabadítsa fel azokat a rendszererőforrásokat, amelyek azonnal befolyásolják egy másik alkalmazás felhasználói élményét (kamera, média lejátszó), az onStop-ban — az összes többi erőforrást, amelyek nem szükségesek rejtett Activity esetén. A Google azt javasolja, hogy az onPause-ban mentse el a kritikus felhasználói adatokat (e-mail-piszkozat, beállítások), mivel az onStop gyors váltáskor nem feltétlenül következik be.

onStop → onRestart: visszatérés a képernyőre

Amikor a felhasználó visszatér a rejtett Activity-hez, a rendszer meghívja az onRestart → onStart → onResume-ot. Az onRestart metódus jelzi, hogy az Activity visszatér a Stopped állapotból. Ez fontos szakasz a UI és az onStop-ban felszabadított erőforrások helyreállításához.

A hívások sorrendje visszatéréskor:

• onRestart() — az Activity értesítést kap, hogy újra megjelenik. Tipikus műveletek: adatok újratöltése, listák frissítése.
• onStart() — az Activity láthatóvá válik, de még nem aktív. Itt az onStop-ban felszabadított erőforrások újrainicializálása történik.
• onResume() — az Activity fókuszt kap és készen áll az interakcióra. Az animációk elindulnak, az érzékelők regisztrálásra kerülnek.

Ha az alkalmazás folyamatát a rendszer megölte Stopped állapotban, az onCreate hívódik meg az onRestart helyett, és az onSaveInstanceState-ból származó Bundle átadásra kerül az állapot helyreállításához. Ez a forgatókönyv (process death) — az egyik leggyakoribb hibaforrás Android-alkalmazásokban: a fejlesztők implementálják az onRestart-ot, de elfelejtik figyelembe venni a helyreállítást az onCreate-en keresztül a folyamat megszakadása után.

Kódpéldák onStop-pal Kotlinban

1. példa: Alap onStop implementáció érzékelők felszabadításával

Bemutatja az érzékelőkről való helyes leiratkozást és az animáció leállítását az Activity elrejtésekor. A képernyőre való visszatérés után az erőforrások helyreállnak az onStart-ban.

class MainActivity : AppCompatActivity() {
    private lateinit var sensorManager: SensorManager
    private var accelerometer: Sensor? = null
    private var rotationAnimator: ObjectAnimator? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
        accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    }

    override fun onStart() {
        super.onStart()
        accelerometer?.let {
            sensorManager.registerListener(sensorListener, it, SensorManager.SENSOR_DELAY_NORMAL)
        }
        rotationAnimator = ObjectAnimator.ofFloat(findViewById(R.id.icon), "rotation", 0f, 360f)
        rotationAnimator?.apply {
            duration = 3000
            repeatMode = ValueAnimator.RESTART
            repeatCount = ValueAnimator.INFINITE
            start()
        }
    }

    override fun onStop() {
        super.onStop()
        sensorManager.unregisterListener(sensorListener)
        rotationAnimator?.cancel()
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("MainActivity", "Activity visszatér a Stopped állapotból")
    }

    private val sensorListener = SensorEventListener { event, _ ->
        Log.d("MainActivity", "Accel: x=${event.values[0]}, y=${event.values[1]}, z=${event.values[2]}")
    }
}

A kód regisztrálja a gyorsulásmérő érzékelőt és elindít egy végtelen forgási animációt az onStart-ban. Az onStop-ban az érzékelő kikapcsolásra és az animáció törlésre kerül — ez megakadályozza az akkumulátor fogyasztását rejtett Activity esetén. Az onRestart → onStart-on keresztüli visszatérés után az erőforrások újra létrejönnek.

2. példa: onStop állapotmentéssel SavedStateHandle segítségével

Modern megközelítés ViewModel + SavedStateHandle használatával. Az űrlapadatok automatikusan mentésre kerülnek az onStop-ban kézi Bundle nélkül.

class FormViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    var email: String
        get() = savedStateHandle["email"] ?: ""
        set(value) { savedStateHandle["email"] = value }

    var message: String
        get() = savedStateHandle["message"] ?: ""
        set(value) { savedStateHandle["message"] = value }
}

class FormActivity : AppCompatActivity() {
    private val viewModel: FormViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_form)
        Log.d("FormActivity", "onCreate: email=${viewModel.email}")
    }

    override fun onStop() {
        super.onStop()
        Log.d("FormActivity", "onStop: adatok mentve a SavedStateHandle-ba")
    }
}

A SavedStateHandle automatikusan elmenti az értékeket a Bundle-be az onSaveInstanceState során, amely az onStop előtt hívódik meg. Képernyőelforgatáskor vagy folyamatmegszakításkor az adatok veszteség nélkül helyreállnak. A Google a SavedStateHandle-t ajánlja űrlapokhoz és piszkozatokhoz a közvetlen onSaveInstanceState helyett.

3. példa: lifecycleScope az onStop-beli műveletekhez

A lifecycleScope használata korutinokkal az aszinkron adatmentéshez az onStop-ba való átmenet során. A korutin az IO diszpécserben indul, nem blokkolva a fő szálat.

class NoteActivity : AppCompatActivity() {
    private val noteRepository = NoteRepository()

    override fun onStop() {
        lifecycleScope.launch(Dispatchers.IO) {
            val text = findViewById<EditText>(R.id.note_content).text.toString()
            noteRepository.saveDraft(text)
            withContext(Dispatchers.Main) {
                Log.d("NoteActivity", "Piszkozat elmentve az onStop-ban")
            }
        }
        super.onStop()
    }
}

A lifecycleScope.launch korutin automatikusan törlődik, ha az Activity életciklusa véget ér. A Dispatchers.IO használata garantálja, hogy az adatbázisba vagy fájlba írás nem blokkolja az Activity-re való visszatérést. A Google szerint a lifecycleScope-ban lévő korutinok az előnyben részesített módszer az aszinkron műveletekhez az onStop-ban.