onRestart — essensen, återställning av Activity i livscykeln

onRestart — essensen av metoden i Android-livscykeln

onRestart — en callback-metod som Android anropar strikt före onStart, när Activity återvänder från det osynliga Stopped-statusen tillbaka till den synliga. Denna metod är unik eftersom den endast anropas vid upprepad visning av Activity — vid första instansskapandet börjar sekvensen med onCreate och hoppar över onRestart. Fullständig cykel: onCreate → onStart → onResume (första start) eller onRestart → onStart → onResume (upprepad visning).

Ur Android-systemets perspektiv är onRestart en optimering som gör att Activity kan förbereda sig för återkomst: uppdatera data från arkivet, synkronisera UI-status, kontrollera nätverksanslutningen. Till skillnad från onResume, som anropas varje gång fokus erhålls (inklusive vid återkomst från en dialog eller systemmenyn), aktiveras onRestart endast vid den fullständiga cykeln av döljning-återkomst. Detta gör onRestart till den idealiska platsen för „tunga“ uppdateringsoperationer som inte behövs vid partiell fokusförlust.

Enligt specifikationen för Android Activity-livscykeln kan tidsintervallet mellan onStop och onRestart variera från några sekunder (användaren växlade snabbt) till flera timmar (appen var i bakgrunden och användaren återvände). Under denna tid kan data i den fjärrkällan (API, DB) ha ändrats, därför är onRestart den naturliga punkten för att kontrollera aktuallitet.

När anropas onRestart: villkor och ordning

onRestart anropas endast när Activity återvänder från Stopped-status, som Activity gick in i efter anrop av onStop. Nedan listas alla scenarier som leder till onRestart.

Scenarier för anrop av onRestart:

• Återkomst från ett annat Activity — användaren öppnade ett nytt Activity (t.ex. klickade på en notis) och återvände sedan (tryckte på „Tillbaka“). Stack: MainActivity.onPause → MainActivity.onStop → SecondActivity skapas → användaren trycker „Tillbaka“ → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Återkomst från minimering — användaren minimerade appen (Home) och efter en tid återvände. CurrentActivity.onPause → CurrentActivity.onStop → (app i bakgrunden) → användaren återvänder → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Återkomst från låsskärmen — låsskärmen täcker Activity; efter upplåsning får Activity onRestart om betydande tid har gått (mer än 5 sekunder).
• Återkomst från en app startad via Intent — kamera, galleri, webbläsare — alla tredjepartsappar startade via startActivityForResult() eller ActivityResultLauncher.

När onRestart ANROPAS INTE: vid skärmrotation (Activity förstörs och skapas på nytt via onCreate), vid återkomst från en dialogruta (Activity går inte till onStop, bara onPause → onResume), vid process death (Activity skapas på nytt).

Skillnad mellan onRestart och onCreate: vad man väljer

onRestart och onCreate är två olika tillvägagångssätt för att återställa Activity. Valet mellan dem beror på om Activity har förstörts helt eller bara dolts.

Urvalsregel: initialisering av View och prenumeration på LiveData/StateFlow gör i onCreate (eller onViewCreated för Fragment). Datauppdatering, omladdning av listor och statuskontroll — i onRestart. Om data laddas via ViewModel kan onRestart helt enkelt anropa metoden refresh() på ViewModel, och View prenumererar på uppdaterade data via den reaktiva strömmen.

Google rekommenderar: duplicera inte logiken från onCreate i onRestart. Separera i ViewModel metoderna refresh() som laddar aktuella data och anropa dem i onRestart. Detta bevarar renheten i MVVM-arkitekturen och eliminerar kodduplicering.

Användningsscenarier för onRestart: uppdatering av data och UI

onRestart — den idealiska platsen för operationer som ska utföras vid varje återkomst till skärmen, men inte behövs vid första öppnandet. Här är typiska scenarier:

• Uppdatera lista från DB eller API — användaren gick till ett annat Activity, ändrade data där, återvände — listan måste vara aktuell. Anropa viewModel.refreshItems() i onRestart.
• Kontrollera auktorisering — om Activity var dolt under lång tid kan åtkomsttoken ha löpt ut. onRestart är punkten för att kontrollera tokenets giltighet och omdirigera till inloggningsskärmen.
• Synkronisera UI-status — växla teman, ändra språk, uppdatera inställningar — ändringarna ska tillämpas vid återkomst till skärmen.
• Ladda om media — om Activity visar innehåll som kan ha ändrats (nyhetsflöde, valutakurs, väder), uppdatera data i onRestart.
• Kontrollera nätverksanslutning — vid återkomst från offlineläge bör Activity kontrollera nätverkstillgänglighet och växla UI.
• Återställ animationer — animationer som frigjorts i onStop, starta om i onRestart före onStart.

Vad man INTE ska göra i onRestart: initiera inte View på nytt — de lever eftersom Activity inte har förstörts. Prenumerera inte på LiveData igen — prenumerationen i onCreate lever. Skapa inte nya fragment — de finns redan i FragmentManager.

onRestart och process death: viktigt undantag

Det viktigaste undantaget: onRestart anropas inte om applikationsprocessen har dödats av systemet. Detta är den avgörande punkten som utvecklare ofta missar genom att förlita sig på onRestart för statusåterställning.

Vid process death:

• Appen var i bakgrunden, Android dödade processen för att frigöra minne.
• Användaren återvänder — systemet startar en ny process.
• Activity skapas på nytt: onCreate(Bundle) → onStart → onResume.
• onRestart anropas INTE — för systemet är detta en ny Activity-instans.

Hur man skyddar sig: spara alltid kritisk status i onSaveInstanceState(Bundle) (anropas före onStop) eller använd SavedStateHandle i ViewModel. I onCreate, kontrollera savedInstanceState: om den inte är null, återställ status från Bundle, om den är null — ladda färska data.

Enligt Google Android Vitals sker cirka 7% av återkomsterna till Activity efter lång vistelse i bakgrunden efter process death. Detta innebär att var 15:e Activity som borde ha anropat onRestart i själva verket går igenom onCreate. Att ignorera detta scenario är en av huvudorsakerna till buggar med „tom skärm efter återkomst“.

Kodexempel med onRestart i Kotlin

Exempel 1: onRestart med listuppdatering via ViewModel

Activity anropar viewModel.refreshTasks() i onRestart för att uppdatera uppgiftslistan efter återkomst från redigeringsskärmen.

class TaskListActivity : AppCompatActivity() {
    private val viewModel: TaskViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_task_list)
        viewModel.tasks.observe(this) { tasks ->
            Log.d("TaskList", "${tasks.size} uppgifter mottagna")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: uppdatering av uppgiftslistan")
        viewModel.refreshTasks()
    }
}

class TaskViewModel : ViewModel() {
    private val _tasks = MutableLiveData<List<Task>>()
    val tasks: LiveData<List<Task>> get() = _tasks

    fun refreshTasks() {
        viewModelScope.launch {
            _tasks.value = TaskRepository().getAllTasks()
        }
    }
}

ViewModel.refreshTasks() laddar aktuella data från arkivet. LiveData meddelar automatiskt Activity om dataändring — UI uppdateras utan extra kod. OnRestart skapar ingen ny prenumeration — den är redan inställd i onCreate.

Exempel 2: onRestart med auktoriseringskontroll

Activity kontrollerar tokenets giltighet vid återkomst och omdirigerar till inloggning om det behövs.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Återvände från inloggningsskärmen") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Token har löpt ut — omdirigering till inloggning")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

class AuthManager {
    fun isTokenValid(): Boolean {
        val expiry = SharedPreferencesManager().getTokenExpiry()
        return System.currentTimeMillis() < expiry
    }
}

Om användaren minimerade appen under lång tid och återvände efter att token löpt ut, kommer onRestart att omdirigera till inloggningsskärmen. Detta förhindrar API-fel vid försök att utföra en begäran med en utgången token. Observera: kontroll i onRestart, inte i onResume, för att undvika onödig kontroll vid återkomst från en dialog.

Exempel 3: onRestart i Fragment med ViewLifecycleOwner

Fragment använder onRestart via LifecycleObserver för datauppdatering.

class FeedFragment : Fragment() {
    private val viewModel: FeedViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycle.addObserver(object : LifecycleObserver {
            @OnLifecycleEvent(Lifecycle.Event.ON_RESTART)
            fun onRestart() {
                Log.d("FeedFragment", "onRestart via LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

Istället för att åsidosätta onRestart i Fragment används LifecycleObserver — ett mer flexibelt tillvägagångssätt som gör det möjligt att lägga till logik till livscykelhändelser utan arv. ViewLifecycleOwner garanterar att observatören lever inom View-omfånget (överlever inte onDestroyView).