onStop — wat is het, verbergen van Activity in de Android-levenscyclus

Wat is onStop in Android?

onStop — is een callback-methode van de klasse AppCompatActivity (en zijn voorganger Activity), die wordt aangeroepen door het Android-besturingssysteem wanneer Activity volledig onzichtbaar wordt voor de gebruiker. Op dit moment wordt Activity verborgen door een andere Activity, een dialoogvenster, de systeemstartprogramma of het vergrendelscherm. Vanuit het oogpunt van de levenscyclus volgt onStop na onPause en geeft aan dat Activity niet langer op het scherm zichtbaar is, hoewel het Activity-object en zijn status in het geheugen blijven.

Wanneer Activity naar de Stopped-status gaat, behoudt het zijn status in het RAM-geheugen — alle velden, de View-hiërarchie en ViewModel blijven toegankelijk. Dit onderscheidt Stopped van de vernietigde (Destroyed) status, waarbij Activity volledig wordt verwijderd. System UI kan het proces van een app in de Stopped-status doden bij geheugengebrek — dit is de zogenaamde process death. De ontwikkelaar moet kritieke gegevens (concepten, scrollpositie) opslaan in onSaveInstanceState(), dat vóór onStop wordt aangeroepen, om herstel bij het doden van het proces te garanderen.

Volgens de Android Compatibility Definition Document (CDD)-specificatie voor versie 14+ heeft een proces in de Stopped-status een lagere prioriteit bij het doden door OOM Killer — lager dan processen in de Background-fase, maar hoger dan gecachte processen. Volgens Google-statistieken vindt 68% van de process-dodingen plaats wanneer Activity in de Stopped-status is, niet Paused.

Wanneer wordt onStop aangeroepen: scenario's en volgorde

onStop wordt aangeroepen bij volledig verlies van zichtbaarheid van Activity, ongeacht de oorzaak: starten van een nieuwe Activity boven de huidige, minimaliseren van de app (indrukken Home), vergrendelen van scherm, inkomend gesprek of openen van systeemdialoog. In al deze gevallen krijgt Activity eerst onPause (gedeeltelijk verlies van focus) en daarna onStop (volledig verlies van zichtbaarheid).

Belangrijkste scenario's voor het aanroepen van onStop:

• Starten van een nieuwe Activity boven de huidige — huidige Activity krijgt onPause, daarna onStop; nieuwe Activity doorloopt onCreate → onStart → onResume.
• Minimaliseren van de app (Home) — Activity gaat in 200–300 ms naar onPause → onStop, blijft in geheugen in Stopped-status.
• Vergrendelen van scherm — systeem roept onPause → onStop aan omdat het vergrendelscherm Activity volledig bedekt.
• Inkomend gesprek — telefoon-Activity (Dialer) start erboven, huidige Activity gaat naar onStop.
• Overschakelen naar andere app (Recent Apps) — Activity wordt verborgen, krijgt onStop, maar blijft in de procescache.

Het is belangrijk te begrijpen dat onStop niet wordt aangeroepen bij het draaien van het scherm — in dit geval wordt Activity vernietigd (onPause → onStop → onDestroy) en opnieuw aangemaakt (onCreate → onStart → onResume). Uitzondering — de vlag android:configChanges="orientation" in het manifest, waarbij Activity niet opnieuw wordt aangemaakt maar de aanroep onConfigurationChanged() krijgt.

onStop in de Activity-levenscyclus

onStop neemt een centrale plaats in de volgorde van de Activity-levenscyclus tussen zichtbare en onzichtbare status. Volledige volgorde: onCreate → onStart → onResume → (actieve status) → onPause → onStop → onDestroy (of onRestart → onStart → onResume bij terugkeer).

*In de Stopped-status wordt Activity in het geheugen bewaard, maar kan door het systeem worden gedood bij gebrek aan bronnen. Prioriteit van doden van Stopped-processen — op één na laatste, alleen hoger dan lege gecachte processen.

onStop en onSaveInstanceState: Het systeem roept onSaveInstanceState(Bundle) aan vóór onStop om de dynamische UI-status op te slaan. De ontwikkelaar overschrijft deze methode om in Bundle de waarden van invoervelden, de RecyclerView-positie, geselecteerde items op te slaan. Zelfs als Activity niet wordt vernietigd (gebruiker heeft geminimaliseerd en is teruggekeerd), wordt Bundle doorgegeven aan onCreate bij configuratiewijzigingen. Google raadt aan alleen tijdelijke UI-status op te slaan — niet repository-gegevens of ViewModel die buiten Activity leven.

Welke bronnen vrijgeven in onStop

In onStop moet de ontwikkelaar alle bronnen vrijgeven die niet nodig zijn wanneer Activity niet zichtbaar is. Dit vermindert de belasting van batterij, processor en geheugen, en voorkomt ANR bij terugkeer naar de activiteit.

Wat vrijgeven in onStop:

• Animaties en transitions — stop ObjectAnimator, ValueAnimator, ViewPropertyAnimator. Een werkende animatie van een onzichtbare Activity is verspilling van GPU-cycli.
• Sensoren (Sensors) — uitschrijven van SensorManager (accelerometer, gyroscoop, magnetometer). Sensoren verbruiken energie, zelfs wanneer Activity verborgen is.
• Camera en microfoon — Camera2 of CameraX vrijgeven, MediaRecorder stoppen. De camera actief laten bij verborgen Activity is verboden door het Google Play-beleid.
• LocationListener — uitschrijven van FusedLocationProviderClient of LocationManager. Geolocatie is de meest energie-intensieve bron.
• Network listeners — WebSocket sluiten, HTTP-verzoeken annuleren die niet nodig zijn op de achtergrond.
• MediaPlayer en ExoPlayer — pauzeren of stoppen als afspelen niet op de achtergrond moet doorgaan.

Wat niet doen in onStop: Voer geen langdurige operaties uit — opslaan van grote gegevens in database, netwerkverzoeken, complexe berekeningen. onStop wordt uitgevoerd op de hoofdthread en blokkeert terugkeer naar Activity. Gebruik voor langdurige operaties WorkManager met vertraging of coroutines in viewModelScope. Geef ViewModel-bronnen niet vrij — ViewModel overleeft onStop en wordt gebruikt bij terugkeer.

Verschil tussen onStop en onPause

onPause en onStop verschillen in mate van zichtbaarheidsverlies en omvang van verplichte acties. onPause wordt aangeroepen bij gedeeltelijk focusverlies (bijvoorbeeld openen van dialoogvenster of systeemmenu), onStop — bij volledig verlies van zichtbaarheid. Dit verschil is belangrijk voor het kiezen welke bronnen vrij te geven in elke fase.

Algemene regel: geef in onPause systeembronnen vrij die onmiddellijk de gebruikerservaring van een andere app beïnvloeden (camera, mediaspeler), in onStop — alle andere bronnen die niet nodig zijn bij verborgen Activity. Google raadt aan in onPause kritieke gebruikersgegevens op te slaan (e-mailconcept, instellingen), omdat onStop mogelijk niet optreedt bij snel schakelen.

onStop → onRestart: terugkeer naar scherm

Wanneer de gebruiker terugkeert naar verborgen Activity, roept het systeem onRestart → onStart → onResume aan. De methode onRestart geeft aan dat Activity terugkeert uit de Stopped-status. Dit is een belangrijke fase voor het herstellen van UI en bronnen die in onStop zijn vrijgegeven.

Aanroepvolgorde bij terugkeer:

• onRestart() — Activity wordt op de hoogte gesteld dat het opnieuw wordt weergegeven. Typische acties: gegevens herladen, lijsten bijwerken.
• onStart() — Activity wordt zichtbaar maar is nog niet actief. Hier worden bronnen die in onStop zijn vrijgegeven opnieuw geïnitialiseerd.
• onResume() — Activity krijgt focus en is klaar voor interactie. Animaties worden gestart, sensoren worden geregistreerd.

Als het app-proces door het systeem is gedood in de Stopped-status, wordt onCreate aangeroepen in plaats van onRestart, en wordt Bundle uit onSaveInstanceState doorgegeven voor statusherstel. Dit scenario (process death) — een van de meest voorkomende oorzaken van bugs in Android-apps: ontwikkelaars implementeren onRestart maar vergeten herstel via onCreate na het doden van het proces mee te nemen.

Codevoorbeelden met onStop in Kotlin

Voorbeeld 1: Basisimplementatie van onStop met vrijgeven van sensoren

Toont correct uitschrijven van sensoren en stoppen van animatie bij verbergen van Activity. Na terugkeer op het scherm worden bronnen hersteld in onStart.

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 keert terug uit Stopped-status")
    }

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

De code registreert de accelerometersensor en start een oneindige rotatieanimatie in onStart. In onStop wordt de sensor uitgeschakeld en de animatie geannuleerd — dit voorkomt batterijverbruik bij verborgen Activity. Na terugkeer via onRestart → onStart worden bronnen opnieuw aangemaakt.

Voorbeeld 2: onStop met statusopslag via SavedStateHandle

Moderne aanpak met ViewModel + SavedStateHandle. Formuliergegevens worden automatisch opgeslagen bij onStop zonder handmatige Bundle.

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: gegevens opgeslagen in SavedStateHandle")
    }
}

SavedStateHandle slaat automatisch waarden op in Bundle bij onSaveInstanceState, dat vóór onStop wordt aangeroepen. Bij schermrotatie of procesdoding worden gegevens zonder verlies hersteld. Google beveelt SavedStateHandle aan voor formulieren en concepten in plaats van directe onSaveInstanceState.

Voorbeeld 3: lifecycleScope voor operaties in onStop

Gebruik van lifecycleScope met coroutines voor asynchrone gegevensopslag bij overgang naar onStop. De coroutine wordt gestart in de IO-dispatcher en blokkeert de hoofdthread niet.

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", "Concept opgeslagen in onStop")
            }
        }
        super.onStop()
    }
}

De coroutine lifecycleScope.launch wordt automatisch geannuleerd als de Activity-levenscyclus eindigt. Gebruik van Dispatchers.IO garandeert dat schrijven naar database of bestand de terugkeer naar Activity niet blokkeert. Volgens Google zijn coroutines in lifecycleScope de voorkeursmanier voor asynchrone operaties in onStop.