onStop — vad är det, dölja Activity i Androidens livscykel

Vad är onStop i Android?

onStop — är en callback-metod för klassen AppCompatActivity (och dess föregångare Activity), som anropas av Android-operativsystemet när Activity upphör att vara helt synlig för användaren. I detta ögonblick är Activity dolt av ett annat Activity, dialogruta, systemstartare eller låsskärm. Ur livscykelperspektiv följer onStop efter onPause och signalerar att Activity inte längre är synligt på skärmen, även om Activity-objektet och dess tillstånd finns kvar i minnet.

När Activity övergår till Stopped-tillståndet (stoppat), behåller det sitt tillstånd i RAM-minnet — alla fält, View-hierarkin och ViewModel förblir tillgängliga. Detta skiljer Stopped från förstört (Destroyed) tillstånd, där Activity tas bort helt. System UI kan döda processen för en applikation i Stopped-tillstånd vid minnesbrist — detta kallas process death. Utvecklaren är skyldig att spara kritiska data (utkast, scrollposition) i onSaveInstanceState(), som anropas före onStop, för att garantera återställning vid processdöd.

Enligt Android Compatibility Definition Document (CDD) för version 14+ har en process i Stopped-tillstånd lägre prioritet vid dödning av OOM Killer — lägre än processer i Background-fasen, men högre än cachade processer. Enligt Google-statistik sker 68% av processdödningar när Activity är i Stopped-tillstånd, inte Paused.

När anropas onStop: scenarier och ordning

onStop anropas vid fullständig förlust av synlighet för Activity, oavsett orsak: start av ett nytt Activity ovanför det aktuella, minimering av applikationen (tryck på Home), låsning av skärmen, inkommande samtal eller öppning av systemdialog. I alla dessa fall får Activity först onPause (delvis förlust av fokus), sedan onStop (fullständig förlust av synlighet).

Huvudscenarier för anrop av onStop:

• Start av ett nytt Activity ovanför det aktuella — det aktuella Activity får onPause, sedan onStop; det nya Activity går igenom onCreate → onStart → onResume.
• Minimering av applikationen (Home) — Activity övergår till onPause → onStop inom 200–300 ms, finns kvar i minnet i Stopped-tillstånd.
• Låsning av skärmen — systemet anropar onPause → onStop, eftersom låsskärmen helt täcker Activity.
• Inkommande samtal — telefon-activity (Dialer) startas ovanför, det aktuella Activity går till onStop.
• Växling till annan applikation (Recent Apps) — Activity döljs, får onStop, men finns kvar i processcachen.

Det är viktigt att förstå att onStop inte anropas vid skärmrotation — i detta fall förstörs Activity (onPause → onStop → onDestroy) och skapas på nytt (onCreate → onStart → onResume). Undantag — flaggan android:configChanges="orientation" i manifestet, där Activity inte återskapas utan får anropet onConfigurationChanged().

onStop i Activitys livscykel

onStop har en central plats i sekvensen av Activitys livscykel mellan synligt och osynligt tillstånd. Full sekvens: onCreate → onStart → onResume → (aktivt tillstånd) → onPause → onStop → onDestroy (eller onRestart → onStart → onResume vid återgång).

*I Stopped-tillståndet bevaras Activity i minnet, men kan dödas av systemet vid resursbrist. Prioriteten för dödning av Stopped-processer — näst sist, högre endast än tomma cachade processer.

onStop och onSaveInstanceState: Systemet anropar onSaveInstanceState(Bundle) före onStop för att spara dynamiskt UI-tillstånd. Utvecklaren åsidosätter denna metod för att spara i Bundle värdena för inmatningsfält, RecyclerView-position, valda element. Även om Activity inte förstörs (användaren har bara minimerat och återvänt), skickas Bundle till onCreate vid konfigurationsändringar. Google rekommenderar att endast spara temporärt UI-tillstånd — inte datalager eller ViewModel-data som lever utanför Activity.

Vilka resurser ska frigöras i onStop

I onStop är utvecklaren skyldig att frigöra alla resurser som inte behövs när Activity inte är synligt. Detta minskar belastningen på batteri, processor och minne, samt förhindrar ANR vid återgång till aktiviteten.

Vad ska frigöras i onStop:

• Animationer och transitions — stoppa ObjectAnimator, ValueAnimator, ViewPropertyAnimator. En animering som körs på ett osynligt Activity är slöseri med GPU-cykler.
• Sensorer (Sensors) — avregistrera från SensorManager (accelerometer, gyroskop, magnetometer). Sensorer förbrukar energi även när Activity är dolt.
• Kamera och mikrofon — frigör Camera2 eller CameraX, stoppa MediaRecorder. Att lämna kameran aktiv vid dolt Activity är förbjudet enligt Google Play-policy.
• LocationListener — avregistrera från FusedLocationProviderClient eller LocationManager. Geolokalisering är den mest energikrävande resursen.
• Network listeners — stäng WebSocket, avbryt HTTP-förfrågningar som inte behövs i bakgrunden.
• MediaPlayer och ExoPlayer — pausa eller stoppa om uppspelning inte ska fortsätta i bakgrunden.

Vad man inte ska göra i onStop: Utför inte långvariga operationer — spara stora data i databas, nätverksförfrågningar, komplexa beräkningar. onStop körs på huvudtråden och blockerar återgång till Activity. För långvariga operationer, använd WorkManager med fördröjning eller korutiner i viewModelScope. Frigör inte ViewModel-resurser — ViewModel överlever onStop och kommer att användas vid återgång.

Skillnad mellan onStop och onPause

onPause och onStop skiljer sig i grad av synlighetsförlust och omfattning av obligatoriska åtgärder. onPause anropas vid delvis förlust av fokus (till exempel öppning av dialogruta eller systemmeny), onStop — vid fullständig förlust av synlighet. Denna skillnad är viktig för valet av vilka resurser som ska frigöras i varje steg.

Allmän regel: i onPause, frigör systemresurser som omedelbart påverkar användarupplevelsen av en annan applikation (kamera, mediaspelare), i onStop — alla andra resurser som inte behövs när Activity är dolt. Google rekommenderar att spara kritiska användardata i onPause (e-postutkast, inställningar), eftersom onStop kanske inte inträffar vid snabb växling.

onStop → onRestart: återgång till skärmen

När användaren återvänder till dolt Activity, anropar systemet onRestart → onStart → onResume. Metoden onRestart signalerar att Activity återvänder från Stopped-tillståndet. Detta är en viktig fas för att återställa UI och resurser som frigjordes i onStop.

Anropssekvens vid återgång:

• onRestart() — Activity får meddelande om att det kommer att visas igen. Typiska åtgärder: omladdning av data, uppdatering av listor.
• onStart() — Activity blir synligt men är ännu inte aktivt. Här återinitialiseras resurser som frigjordes i onStop.
• onResume() — Activity får fokus och är redo för interaktion. Animationer startas, sensorer registreras.

Om applikationsprocessen dödades av systemet i Stopped-tillstånd, anropas onCreate istället för onRestart, och Bundle från onSaveInstanceState skickas för återställning av tillstånd. Detta scenario (process death) — en av de vanligaste orsakerna till buggar i Android-applikationer: utvecklare implementerar onRestart men glömmer att ta hänsyn till återställning via onCreate efter processdöd.

Kodexempel med onStop i Kotlin

Exempel 1: Grundläggande implementering av onStop med frigöring av sensorer

Visar korrekt avregistrering från sensorer och stopp av animation vid döljande av Activity. Efter återgång till skärmen återställs resurser i 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 återvänder från Stopped-tillstånd")
    }

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

Koden registrerar accelerometersensorn och startar en oändlig rotationsanimation i onStart. I onStop stängs sensorn av och animationen annulleras — detta förhindrar batteriförbrukning när Activity är dolt. Efter återgång via onRestart → onStart återskapas resurser.

Exempel 2: onStop med tillståndssparning via SavedStateHandle

Modernt tillvägagångssätt med ViewModel + SavedStateHandle. Formulärdata sparas automatiskt vid onStop utan manuell 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: data sparade i SavedStateHandle")
    }
}

SavedStateHandle sparar automatiskt värden i Bundle vid onSaveInstanceState, som anropas före onStop. Vid skärmrotation eller processdöd återställs data utan förlust. Google rekommenderar SavedStateHandle för formulär och utkast istället för direkt onSaveInstanceState.

Exempel 3: lifecycleScope för operationer i onStop

Användning av lifecycleScope med korutiner för asynkron datasparning vid övergång till onStop. Korutinen startas i IO-dispatch, blockerar inte huvudtråden.

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", "Utkast sparat i onStop")
            }
        }
        super.onStop()
    }
}

Korutinen lifecycleScope.launch annulleras automatiskt om Activitys livscykel avslutas. Användning av Dispatchers.IO garanterar att skrivning till databas eller fil inte blockerar återgång till Activity. Enligt Google är korutiner i lifecycleScope det föredragna sättet för asynkrona operationer i onStop.