onStop — co to jest, ukrywanie Activity w cyklu życia Androida

Czym jest onStop w Androidzie?

onStop — to callback metody klasy AppCompatActivity (i jej poprzednika Activity), który jest wywoływany przez system operacyjny Android, gdy Activity przestaje być całkowicie widoczne dla użytkownika. W tym momencie Activity jest zasłonięte przez inne Activity, okno dialogowe, program uruchamiający systemu lub ekran blokady. Z punktu widzenia cyklu życia, onStop następuje po onPause i sygnalizuje, że Activity nie jest już widoczne na ekranie, chociaż sam obiekt Activity i jego stan pozostają w pamięci.

Gdy Activity przechodzi w stan Stopped (zatrzymane), zachowuje swój stan w pamięci RAM — wszystkie pola, hierarchia widoków i ViewModel pozostają dostępne. To odróżnia Stopped od stanu zniszczonego (Destroyed), w którym Activity jest całkowicie usuwane. System UI może zabić proces aplikacji znajdującej się w stanie Stopped przy braku pamięci — jest to tak zwany process death. Programista jest zobowiązany zapisać krytyczne dane (wersje robocze, pozycję przewijania) w onSaveInstanceState(), które jest wywoływane przed onStop, aby zagwarantować przywrócenie przy zabiciu procesu.

Według specyfikacji Android Compatibility Definition Document (CDD) dla wersji 14+, proces w stanie Stopped ma obniżony priorytet przy zabijaniu przez OOM Killer — niższy niż procesy w fazie Background, ale wyższy niż procesy w pamięci podręcznej. Według statystyk Google, 68% przypadków zabijania procesów ma miejsce, gdy Activity znajduje się w stanie Stopped, a nie Paused.

Kiedy wywoływane jest onStop: scenariusze i kolejność

onStop jest wywoływane przy całkowitej utracie widoczności Activity, niezależnie od przyczyny: uruchomienie nowego Activity nad bieżącym, zminimalizowanie aplikacji (naciśnięcie Home), blokada ekranu, przychodzące połączenie lub otwarcie okna systemowego. We wszystkich tych przypadkach Activity najpierw otrzymuje onPause (częściowa utrata fokusu), a następnie onStop (całkowita utrata widoczności).

Główne scenariusze wywołania onStop:

• Uruchomienie nowego Activity nad bieżącym — bieżące Activity otrzymuje onPause, następnie onStop; nowe Activity przechodzi onCreate → onStart → onResume.
• Zminimalizowanie aplikacji (Home) — Activity przechodzi w onPause → onStop w ciągu 200–300 ms, pozostaje w pamięci w stanie Stopped.
• Blokada ekranu — system wywołuje onPause → onStop, ponieważ ekran blokady całkowicie zasłania Activity.
• Przychodzące połączenie — Activity telefonu (Dialer) uruchamia się na wierzchu, bieżące Activity przechodzi w onStop.
• Przełączenie na inną aplikację (Recent Apps) — Activity jest ukrywane, otrzymuje onStop, ale pozostaje w pamięci podręcznej procesów.

Ważne jest, aby zrozumieć, że onStop nie jest wywoływane przy obrocie ekranu — w tym przypadku Activity jest niszczone (onPause → onStop → onDestroy) i tworzone od nowa (onCreate → onStart → onResume). Wyjątkiem jest flaga android:configChanges="orientation" w manifeście, przy której Activity nie jest odtwarzane, a otrzymuje wywołanie onConfigurationChanged().

onStop w cyklu życia Activity

onStop zajmuje centralne miejsce w sekwencji cyklu życia Activity między stanem widocznym a niewidocznym. Pełna sekwencja: onCreate → onStart → onResume → (stan aktywny) → onPause → onStop → onDestroy (lub onRestart → onStart → onResume przy powrocie).

*W stanie Stopped Activity jest przechowywane w pamięci, ale może zostać zabite przez system przy braku zasobów. Priorytet zabijania procesów Stopped — przedostatni, wyższy tylko niż puste procesy w pamięci podręcznej.

onStop i onSaveInstanceState: System wywołuje onSaveInstanceState(Bundle) przed onStop, aby zapisać dynamiczny stan UI. Programista nadpisuje tę metodę, aby zapisać w Bundle wartości pól wejściowych, pozycję RecyclerView, wybrane elementy. Nawet jeśli Activity nie zostanie zniszczone (użytkownik po prostu zminimalizował i wrócił), Bundle jest przekazywany do onCreate przy zmianach konfiguracyjnych. Google zaleca zapisywanie tylko przejściowego stanu UI — nie danych repozytorium ani ViewModel, które żyją poza Activity.

Jakie zasoby zwalniać w onStop

W onStop programista jest zobowiązany zwolnić wszystkie zasoby, które nie są potrzebne, gdy Activity nie jest widoczne. Zmniejsza to obciążenie baterii, procesora i pamięci, a także zapobiega ANR przy powrocie do aktywności.

Co zwalniać w onStop:

• Animacje i transitions — zatrzymać ObjectAnimator, ValueAnimator, ViewPropertyAnimator. Działająca animacja niewidocznego Activity to marnowanie cykli GPU.
• Czujniki (Sensors) — wypisać się z SensorManager (akcelerometr, żyroskop, magnetometr). Czujniki pobierają energię nawet przy ukrytym Activity.
• Aparat i mikrofon — zwolnić Camera2 lub CameraX, zatrzymać MediaRecorder. Pozostawianie aparatu aktywnego przy ukrytym Activity jest zabronione przez politykę Google Play.
• LocationListener — wypisać się z FusedLocationProviderClient lub LocationManager. Geolokalizacja — najbardziej energochłonny zasób.
• Network listeners — zamknąć WebSocket, anulować żądania HTTP, które nie są potrzebne w tle.
• MediaPlayer i ExoPlayer — wstrzymać lub zatrzymać, jeśli odtwarzanie nie powinno być kontynuowane w tle.

Czego nie robić w onStop: Nie wykonuj długotrwałych operacji — zapisywanie dużych danych w BD, żądania sieciowe, złożone obliczenia. onStop wykonuje się na głównym wątku i blokuje powrót do Activity. Do długotrwałych operacji używaj WorkManager z opóźnieniem lub korutyn w viewModelScope. Nie zwalniaj zasobów ViewModel — ViewModel przetrwa onStop i zostanie użyty przy powrocie.

Różnica między onStop a onPause

onPause i onStop różnią się stopniem utraty widoczności i zakresem obowiązkowych działań. onPause jest wywoływane przy częściowej utracie fokusu (na przykład otwarcie okna dialogowego lub menu systemowego), onStop — przy całkowitej utracie widoczności. Ta różnica jest ważna przy wyborze, które zasoby zwalniać na każdym etapie.

Ogólna zasada: w onPause zwalniaj zasoby systemowe, które natychmiast wpływają na doświadczenie użytkownika innej aplikacji (aparat, odtwarzacz multimedialny), w onStop — wszystkie pozostałe zasoby, niepotrzebne przy ukrytym Activity. Google zaleca w onPause zapisywać krytyczne dane użytkownika (wersja robocza e-maila, ustawienia), ponieważ onStop może nie wystąpić przy szybkim przełączaniu.

onStop → onRestart: powrót na ekran

Gdy użytkownik wraca do ukrytego Activity, system wywołuje onRestart → onStart → onResume. Metoda onRestart sygnalizuje, że Activity wraca ze stanu Stopped. To ważny etap do przywrócenia UI i zasobów, które zostały zwolnione w onStop.

Sekwencja wywołań przy powrocie:

• onRestart() — Activity jest powiadamiane, że zostanie ponownie pokazane. Typowe działania: przeładowanie danych, aktualizacja list.
• onStart() — Activity staje się widoczne, ale jeszcze nie aktywne. Tutaj ponownie inicjalizowane są zasoby zwolnione w onStop.
• onResume() — Activity otrzymuje fokus i jest gotowe do interakcji. Uruchamiane są animacje, rejestrowane czujniki.

Jeśli proces aplikacji został zabity przez system w stanie Stopped, onCreate jest wywoływane zamiast onRestart, a Bundle z onSaveInstanceState jest przekazywany do przywrócenia stanu. Ten scenariusz (process death) — jeden z najczęstszych powodów błędów w aplikacjach Android: programiści implementują onRestart, ale zapominają uwzględnić przywrócenie przez onCreate po zabiciu procesu.

Przykłady kodu z onStop w Kotlin

Przykład 1: Podstawowa implementacja onStop z zwalnianiem czujników

Pokazuje poprawne wypisanie się z czujników i zatrzymanie animacji przy ukrywaniu Activity. Po powrocie na ekran zasoby są przywracane w 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 powraca ze stanu Stopped")
    }

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

Kod rejestruje czujnik akcelerometru i uruchamia nieskończoną animację obrotu w onStart. W onStop czujnik jest wyłączany i animacja anulowana — zapobiega to zużyciu baterii przy ukrytym Activity. Po powrocie przez onRestart → onStart zasoby są odtwarzane.

Przykład 2: onStop z zapisywaniem stanu przez SavedStateHandle

Nowoczesne podejście z użyciem ViewModel + SavedStateHandle. Dane formularza są zapisywane automatycznie przy onStop bez ręcznego 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: dane zapisane w SavedStateHandle")
    }
}

SavedStateHandle automatycznie zapisuje wartości w Bundle przy onSaveInstanceState, które jest wywoływane przed onStop. Przy obrocie ekranu lub zabiciu procesu dane są przywracane bez utraty. Google zaleca SavedStateHandle dla formularzy i wersji roboczych zamiast bezpośredniego onSaveInstanceState.

Przykład 3: lifecycleScope dla operacji w onStop

Użycie lifecycleScope z korutynami do asynchronicznego zapisywania danych przy przejściu w onStop. Korutyna uruchamiana jest w dyspozytorze IO, nie blokując głównego wątku.

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", "Wersja robocza zapisana w onStop")
            }
        }
        super.onStop()
    }
}

Korutyna lifecycleScope.launch jest automatycznie anulowana, jeśli cykl życia Activity się zakończy. Użycie Dispatchers.IO gwarantuje, że zapis w BD lub pliku nie blokuje powrotu do Activity. Według Google, korutyny w lifecycleScope — preferowany sposób asynchronicznych operacji w onStop.