Activity Lifecycle är en samling callback-metoder som Android anropar när Activity övergår mellan tillstånd: skapande, synlighet, inmatningsfokus, partiell förlust av synlighet, fullständig döljning och förstörelse. Systemet hanterar livscykeln för varje skärm i applikationen, från anrop av onCreate() till onDestroy. Förståelse av dessa tillstånd är ett obligatoriskt krav för stabil drift av en Android-applikation, eftersom felaktig hantering av övergången mellan metoder leder till minnesläckor, förlust av användardata och oväntade krascher. Läs mer om Android-arkitekturen i den allmänna artikeln om Android.
Huvudpunkter
Activity Lifecycle (livscykeln för Activity) — en ändlig tillståndsmaskin som varje skärm i en Android-applikation går igenom från skapandet till fullständig förstörelse. Android-systemet hanterar denna process baserat på användarens åtgärder: öppna applikationen, minimera, rotera skärmen, svara på inkommande samtal, växla mellan applikationer och avsluta.
Förståelse av livscykeln är nödvändig för varje Android-utvecklare, eftersom systemet när som helst kan förstöra Activity vid minnesbrist — och applikationen måste korrekt återställa sitt tillstånd. Enligt Google Android Vitals (2025) uppvisar applikationer som inte hanterar tillståndssparande i onSaveInstanceState() 42 % fler krascher vid återskapande av Activity.
Livscykeln omfattar sex huvudsakliga callback-metoder: onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(). Dessutom finns metoden onRestart() som anropas före onStart() när Activity återvänder från stoppat tillstånd. Varje metod har ett strikt definierat syfte och exekveringstid — systemet anropar dem sekventiellt och utvecklaren kan åsidosätta vilken som helst för att utföra sin egen logik.
Cykeln kan delas in i tre nyckelfaser: hela livstiden (onCreate → onDestroy), synlig livstid (onStart → onStop) och livstid i förgrunden (onResume → onPause). Förståelse av dessa tre nivåer hjälper till att korrekt fördela initialiseringskod och frigörande av resurser.
Varje livscykelmetod utför en strikt definierad uppgift. Systemet anropar dem i en fast ordning och utvecklaren bör endast åsidosätta de metoder som behövs för den specifika logiken. Det rekommenderas inte att anropa livscykelmetoder direkt — detta görs av Android Runtime.
Typisk sekvens vid start av applikationen: onCreate → onStart → onResume. Vid tryck på knappen “Tillbaka”: onPause → onStop → onDestroy. Vid minimering: onPause → onStop, sedan vid återkomst: 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()
}
}
Varje åsidosatt metod måste anropa super-versionen — utan detta kan systemet inte korrekt slutföra övergången mellan tillstånd. Denna regel är fastställd i Android Developers dokumentation och kontrolleras av lint-regler i Android Studio.
Första nivån — hela livstiden (entire lifetime): intervallet mellan onCreate och onDestroy. Här utförs engångsinitialisering och slutlig frigöring av globala resurser. Andra nivån — synlig livstid (visible lifetime): mellan onStart och onStop. Activity är synligt på skärmen men kan vara delvis täckt av ett annat fönster. Tredje nivån — livstid i förgrunden (foreground lifetime): mellan onResume och onPause. Activity är överst i aktivitetsstacken och interagerar med användaren.
onCreate() — den första och enda obligatoriska metoden i Activitys livscykel. Den anropas en gång av systemet vid skapandet av en Activity-instans. Denna metod tar emot parametern savedInstanceState: Bundle? som innehåller det tidigare sparade tillståndet, om Activity återskapas efter förstörelse — till exempel vid skärmrotation.
Inuti onCreate utförs följande uppgifter: initialisering av användargränssnittet via setContentView() med överföring av layoutresurs, bindning av View-element via findViewById(), inställning av adaptrar för RecyclerView och ViewPager, återställning av tillstånd från savedInstanceState, initialisering av ViewModel och LiveData, inställning av klick- och gestlyssnare. Metoden måste slutföras så snabbt som möjligt — långvariga operationer här blockerar renderingen av den första bildrutan, vilket ökar applikationens starttid.
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()
}
}
Om Activity skapas för första gången är savedInstanceState null. Vid återskapande efter skärmrotation innehåller Bundle data som sparats i onSaveInstanceState(). Null-kontroll är standardpraxis för korrekt återställning av UI utan förlust av användarinmatade data.
onStart() anropas omedelbart efter onCreate() eller efter onRestart(), när Activity blir synligt för användaren. I detta tillstånd är Activity ännu inte i förgrunden och kan inte interagera med användaren, men dess användargränssnitt är redan synligt på skärmen. Till exempel, vid start av applikationen, mellan anropet av onStart och onResume, renderar systemet den första bildrutan av gränssnittet.
I metoden onStart utförs vanligtvis följande åtgärder: start av animationer som ska fungera medan Activity är synligt; bindning av BroadcastReceivers; anslutning till geolokaliseringstjänster och sensorer; uppdatering av data från ViewModel eller Room. Här utförs även bindning till Bound-tjänster via bindService(), om applikationen använder klient-server-arkitektur inom processen.
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)
}
Viktig regel: resurser som anslutits i onStart måste frigöras i onStop. Detta garanterar att när Activity inte är synligt på skärmen, förbrukar det inte batteri och systemresurser. Google Play Store kontrollerar applikationer för läckage av LocationListener och andra systemtjänster vid moderering av uppdateringar.
onResume() — tillståndet där Activity är i förgrunden och redo för interaktion med användaren. Detta är skärmens arbetstillstånd: systemet överlämnar inmatningsfokus till Activity och alla beröringshändelser, tangentbordsinmatning och gester dirigeras till denna skärm. Metoden onResume anropas varje gång Activity återvänder till förgrunden — efter slutförande av en annan Activity, efter stängning av ett dialogfönster, efter upplåsning av enheten.
I onResume utförs: återupptagning av animationer som pausades i onPause; öppning av kamera och andra exklusiva resurser; registrering av sensorlyssnare (accelerometer, gyroskop); start av timer och stoppur för UI; uppdatering av skärminnehåll med aktuella data. I paret onResume / onPause arbetar man med resurser som endast ska vara aktiva vid fokus — till exempel kontinuerlig taligenkänning eller videoinspelning.
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)
}
Skillnaden mellan onStart och onResume är betydande: Activity kan vara synligt (onStart) men inte aktivt (onResume) — till exempel när ett popup-dialogfönster eller en transparent låsskärm visas ovanför det. Just i onResume, inte i onStart, bör exklusiva resurser som kräver monopolåtkomst öppnas.
onPause() anropas när Activity förlorar inmatningsfokus men förblir delvis synligt. Typiska scenarier: öppning av dialogfönster, tryck på knappen “Senaste applikationer”, inkommande samtal, tryck på knappen “Hem” (i detta fall följer onStop efter onPause). Metoden onPause är den sista pålitliga platsen för att spara data som användaren inte bör förlora.
I onPause utförs: sparande av e-postutkast och inmatningsformulär i Room eller SharedPreferences; stopp av animationer och videouppspelning; stängning av kamera och frigöring av monopolresurser; avbrytning av kostsamma operationer som inte är kritiska för bakgrunden. Metoden onPause måste slutföras på mindre än 100 millisekunder — systemet blockerar övergången till nästa Activity tills onPause returnerar kontrollen, och överskridande av gränsen leder till 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()
}
Viktigt: onPause exekveras i UI-tråden, därför måste alla blockerande operationer, såsom skrivning till databasen via Room med en synkron fråga, ersättas med asynkrona (koroutiner) eller utföras i en bakgrundstråd. Använd apply() istället för commit() för SharedPreferences — apply skriver data asynkront och blockerar inte UI-tråden.
onStop() anropas när Activity inte längre är synligt för användaren. Detta inträffar i följande fall: Activity är helt täckt av ett annat Activity; användaren tryckte på knappen “Hem” eller växlade till en annan applikation; Activity avslutas (därefter anropas onDestroy). I tillståndet onStop förblir Activity i minnet och behåller alla sina fält — det är varken förstört eller aktivt.
I onStop utförs: avregistrering från BroadcastReceivers som registrerats i onStart; frånkoppling från Bound-tjänster; frigöring av LocationListener, SensorListener och andra systemlyssnare; stopp av långvariga bakgrundsoperationer som inte behövs när applikationen är dold; skrivning av aktuellt UI-tillstånd till Bundle via onSaveInstanceState(), om detta inte gjorts i onPause.
override fun onStop() {
super.onStop()
unregisterReceiver(connectivityReceiver)
unbindService(serviceConnection)
if (isChangingConfigurations()) {
Log.d("Lifecycle", "Activity återskapas på grund av konfiguration")
}
}
Systemet kan förstöra Activity i tillståndet onStop utan att anropa onDestroy vid minnesbrist. Därför måste alla kritiska data sparas före övergången till onStop. Flaggan isChangingConfigurations() gör det möjligt att avgöra om anropet av onStop är relaterat till skärmrotation — i detta fall kommer Activity att återskapas, inte avslutas.
onDestroy() — den sista metoden i livscykeln, anropas före fullständig förstörelse av Activity. Systemet anropar onDestroy i två fall: Activity avslutas genom anrop av finish() eller användaren trycker på knappen “Tillbaka”; Activity förstörs av systemet på grund av konfigurationsändring (t.ex. skärmrotation) och kommer att återskapas. Metoden onDestroy möjliggör slutlig rensning av resurser: frånkoppling av trådar och koroutiner, stängning av permanent öppna cursorer och sockets, frigöring av native-minne via NDK.
override fun onDestroy() {
super.onDestroy()
backgroundJob.cancel()
dbHelper.close()
if (isFinishing) {
Log.d("Lifecycle", "Activity avslutas slutgiltigt")
} else {
Log.d("Lifecycle", "Activity kommer att återskapas")
}
}
Viktig anmärkning: onDestroy är inte garanterat om applikationens process dödas av systemet (out-of-memory kill). Därför kan man inte förlita sig på onDestroy för att spara data — denna uppgift löses i onPause eller onStop. Egenskapen isFinishing gör det möjligt att skilja avslutning av Activity via finish() från återskapande vid konfigurationsändring.
onRestart() anropas före onStart(), när Activity återvänder från stoppat tillstånd (onStop) tillbaka till förgrunden. Detta inträffar när användaren öppnar applikationen igen från menyn “Senaste” eller återvänder till Activity genom att trycka på “Tillbaka” på en underordnad skärm. Metoden onRestart gör det möjligt att utföra logik som skiljer sig från onCreate — till exempel uppdatering av data som kan ha ändrats medan Activity var dolt.
override fun onRestart() {
super.onRestart()
refreshDataFromNetwork()
Log.d("Lifecycle", "Activity startas om från stacken")
}
Typiskt scenario: användaren öppnade applikationen, växlade till en annan uppgift och återvände en timme senare. I onRestart kan applikationen kontrollera datans aktualitet och, om mycket tid har gått, erbjuda att ladda om innehållet. Detta förbättrar användarupplevelsen och minskar sannolikheten för att visa inaktuell information.
Skärmrotation — det vanligaste scenariot för återskapande av Activity. Som standard förstör Android det aktuella Activity och skapar ett nytt vid varje orienteringsändring. Om tillståndet inte sparas förlorar användaren all inmatad data. För detta tillhandahåller Android två mekanismer: onSaveInstanceState() för serialiserbara data och ViewModel för data som överlever konfigurationsändringar.
onSaveInstanceState() anropas före förstörelse av Activity för att spara temporärt tillstånd. Sparade data överförs till onCreate via parametern savedInstanceState och till metoden onRestoreInstanceState() som anropas efter onStart. Bundle har en storleksbegränsning — cirka 500 KB, därför sparas stora datamängder (till exempel bitmappar) via ViewModel.
<!-- AndroidManifest.xml — fixering av orientering -->
<activity android:name=".MainActivity"
android:configChanges="orientation|screenSize" />
Fixering av orientering via android:configChanges förhindrar återskapande av Activity, men anses vara ett antimönster om applikationen måste stödja båda orienteringarna. Modern rekommendation från Google — använd ViewModel i kombination med onSaveInstanceState för data som användaren matar in i UI.
Fragment har sin egen livscykel, liknande Activity, men med ytterligare metoder: onAttach, onCreate, onCreateView, onViewCreated, onStart, onResume, onPause, onStop, onDestroyView, onDestroy, onDetach. Fragment existerar alltid inuti ett Activity och dess livscykel är bunden till livscykeln för container-Activity. Om Activity förstörs följer Fragment efter.
Huvudskillnad: Fragment hanterar inte bara komponentens tillstånd utan även View-hierarkin. Metoden onCreateView returnerar fragmentets rot-View och onDestroyView förstör denna hierarki. Detta gör att Fragment kan överleva återskapande av Activity vid skärmrotation: Fragmentet bevaras och dess View återskapas i 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)
}
}
Att förstå skillnaden mellan onCreate och onCreateView är kritiskt viktigt: onCreate anropas en gång under Fragmentets livstid (även vid återskapande av View), medan onCreateView anropas varje gång Fragment skapar eller återskapar sin View-hierarki. Datainitialisering utförs i onCreate och UI-bindning i onViewCreated.
LifecycleObserver — en komponent i Android Jetpack-biblioteket som gör det möjligt att reagera på livscykelförändringar utan att åsidosätta metoder i Activity eller Fragment. Istället för att duplicera kod i varje livscykelmetod skapar utvecklaren en separat klass med anteckningar @OnLifecycleEvent och skickar den till lifecycle.addObserver().
Jetpack tillhandahåller också klassen LifecycleOwner — ett gränssnitt som implementeras av AppCompatActivity och Fragment. Varje objekt som implementerar LifecycleOwner kan hantera LiveData-prenumerationer, koroutiner via lifecycleScope och WorkManager-arbete i förhållande till livscykeln. Detta är hörnstenen i modern Android-arkitektur baserad på MVVM och Jetpack.
class MyLocationObserver(private val context: Context) : DefaultLifecycleObserver {
override fun onStart(owner: LifecycleOwner) {
startLocationUpdates()
}
override fun onStop(owner: LifecycleOwner) {
stopLocationUpdates()
}
}
// I Activity:
lifecycle.addObserver(MyLocationObserver(this))
Användning av DefaultLifecycleObserver förenklar testning, minskar kodduplicering och gör livscykellogiken återanvändbar mellan olika skärmar. Detta är ett modernt alternativ till manuell åsidosättning av onStart/onStop i varje Activity. I Android-applikationer utvecklade av IT Sectr tillämpar vi LifecycleObserver för geolokalisering, Bluetooth-skanning och analys — detta minskar mängden boilerplate-kod med 30–40%.
Vanliga frågor
Om super.onCreate() eller någon annan super-metod i livscykeln inte anropas, kommer systemet att kasta undantaget SuperNotCalledException och applikationen kraschar. Detta är ett strikt krav från Android Runtime — varje metod måste delegera exekvering till basklassen, annars kan den interna ändliga tillståndsmaskinen inte övergå till nästa tillstånd.
Activity återskapas vid skärmrotation eftersom orienteringsändring är en konfigurationsändring av enheten (configuration change). Som standard förstör Android Activity och skapar ett nytt för att ladda alternativa resurser (layout-land, values-land). För att inaktivera återskapande kan man lägga till attributet android:configChanges i manifestet, men Google rekommenderar att använda ViewModel för att spara data.
Kritiska data sparas i onPause(), eftersom detta är den sista metoden som garanterat anropas innan applikationen kan dödas av systemet. Efter onStop och onDestroy kan systemet avsluta processen utan att anropa ytterligare metoder. För utkast och temporära data, använd SharedPreferences med apply() eller Room med koroutiner.
onPause anropas när Activity förlorar fokus men förblir delvis synligt (till exempel är ett dialogfönster öppet). onStop anropas när Activity är helt dolt från skärmen av ett annat Activity eller genom att trycka på knappen “Hem”. Den huvudsakliga praktiska skillnaden: onPause är den sista punkten för datasparande, onStop är platsen för frigöring av lyssnare och systemtjänster som inte behövs i bakgrunden.
ViewModel — en Android Jetpack-komponent som lagrar UI-data och automatiskt överlever konfigurationsändringar (skärmrotation). ViewModel förstörs inte vid återskapande av Activity: den lever tills LifecycleOwner (Activity eller Fragment) slutligen avslutas. Detta löser problemet med datasparande vid skärmrotation utan att använda Bundle och onSaveInstanceState. ViewModel är ett obligatoriskt element i MVVM-arkitekturen som rekommenderas av Google.
Sammanfattning
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också