onStop — apa itu, menyembunyikan Activity dalam siklus hidup Android

Apa itu onStop di Android?

onStop — adalah metode callback dari kelas AppCompatActivity (dan pendahulunya Activity), yang dipanggil oleh sistem operasi Android ketika Activity berhenti terlihat sepenuhnya oleh pengguna. Pada saat ini, Activity disembunyikan oleh Activity lain, jendela dialog, peluncur sistem, atau layar kunci. Dari sudut pandang siklus hidup, onStop mengikuti onPause dan menandakan bahwa Activity tidak lagi terlihat di layar, meskipun objek Activity dan statusnya tetap berada di memori.

Ketika Activity beralih ke status Stopped (berhenti), ia mempertahankan statusnya di memori RAM — semua field, hierarki View, dan ViewModel tetap dapat diakses. Ini membedakan Stopped dari status hancur (Destroyed), di mana Activity dihapus sepenuhnya. System UI dapat mematikan proses aplikasi yang berada dalam status Stopped saat kekurangan memori — ini yang disebut process death. Pengembang wajib menyimpan data kritis (draf, posisi gulir) di onSaveInstanceState(), yang dipanggil sebelum onStop, untuk menjamin pemulihan saat proses dimatikan.

Menurut spesifikasi Android Compatibility Definition Document (CDD) untuk versi 14+, proses dalam status Stopped memiliki prioritas lebih rendah saat dimatikan oleh OOM Killer — lebih rendah dari proses dalam fase Background, tetapi lebih tinggi dari proses yang di-cache. Menurut statistik Google, 68% kasus pemutusan proses terjadi ketika Activity berada dalam status Stopped, bukan Paused.

Kapan onStop dipanggil: skenario dan urutan

onStop dipanggil saat Activity kehilangan visibilitas sepenuhnya, terlepas dari penyebabnya: meluncurkan Activity baru di atas Activity saat ini, meminimalkan aplikasi (menekan Home), mengunci layar, panggilan masuk, atau membuka dialog sistem. Dalam semua kasus ini, Activity pertama-tama menerima onPause (kehilangan fokus sebagian), lalu onStop (kehilangan visibilitas sepenuhnya).

Skenario utama pemanggilan onStop:

• Meluncurkan Activity baru di atas Activity saat ini — Activity saat ini menerima onPause, lalu onStop; Activity baru melalui onCreate → onStart → onResume.
• Meminimalkan aplikasi (Home) — Activity beralih ke onPause → onStop dalam 200–300 md, tetap di memori dalam status Stopped.
• Mengunci layar — sistem memanggil onPause → onStop, karena layar kunci menutupi Activity sepenuhnya.
• Panggilan masuk — Activity telepon (Dialer) diluncurkan di atas, Activity saat ini beralih ke onStop.
• Beralih ke aplikasi lain (Recent Apps) — Activity disembunyikan, menerima onStop, tetapi tetap dalam cache proses.

Penting untuk dipahami bahwa onStop tidak dipanggil saat rotasi layar — dalam kasus ini, Activity dihancurkan (onPause → onStop → onDestroy) dan dibuat ulang (onCreate → onStart → onResume). Pengecualian — flag android:configChanges="orientation" di manifes, di mana Activity tidak dibuat ulang, melainkan menerima panggilan onConfigurationChanged().

onStop dalam siklus hidup Activity

onStop menempati posisi sentral dalam urutan siklus hidup Activity antara status terlihat dan tidak terlihat. Urutan lengkap: onCreate → onStart → onResume → (status aktif) → onPause → onStop → onDestroy (atau onRestart → onStart → onResume saat kembali).

*Dalam status Stopped, Activity disimpan di memori, tetapi dapat dimatikan oleh sistem saat kekurangan sumber daya. Prioritas pemutusan proses Stopped — kedua dari terakhir, hanya lebih tinggi dari proses kosong yang di-cache.

onStop dan onSaveInstanceState: Sistem memanggil onSaveInstanceState(Bundle) sebelum onStop untuk menyimpan status dinamis UI. Pengembang menimpa metode ini untuk menyimpan di Bundle nilai field input, posisi RecyclerView, item yang dipilih. Bahkan jika Activity tidak dihancurkan (pengguna hanya meminimalkan dan kembali), Bundle diteruskan ke onCreate saat perubahan konfigurasi. Google merekomendasikan untuk hanya menyimpan status UI sementara — bukan data repositori atau ViewModel yang hidup di luar Activity.

Sumber daya apa yang harus dibebaskan di onStop

Dalam onStop, pengembang wajib membebaskan semua sumber daya yang tidak diperlukan saat Activity tidak terlihat. Ini mengurangi beban baterai, prosesor, dan memori, serta mencegah ANR saat kembali ke aktivitas.

Apa yang harus dibebaskan di onStop:

• Animasi dan transisi — hentikan ObjectAnimator, ValueAnimator, ViewPropertyAnimator. Animasi yang berjalan pada Activity yang tidak terlihat adalah pemborosan siklus GPU.
• Sensor (Sensors) — berhenti berlangganan dari SensorManager (akselerometer, giroskop, magnetometer). Sensor mengkonsumsi energi bahkan saat Activity tersembunyi.
• Kamera dan mikrofon — bebaskan Camera2 atau CameraX, hentikan MediaRecorder. Membiarkan kamera aktif saat Activity tersembunyi dilarang oleh kebijakan Google Play.
• LocationListener — berhenti berlangganan dari FusedLocationProviderClient atau LocationManager. Geologi adalah sumber daya yang paling boros energi.
• Network listeners — tutup WebSocket, batalkan permintaan HTTP yang tidak diperlukan di latar belakang.
• MediaPlayer dan ExoPlayer — jeda atau hentikan jika pemutaran tidak boleh berlanjut di latar belakang.

Apa yang tidak boleh dilakukan di onStop: Jangan lakukan operasi panjang — menyimpan data besar di database, permintaan jaringan, perhitungan rumit. onStop dijalankan di thread utama dan memblokir kembali ke Activity. Untuk operasi panjang, gunakan WorkManager dengan penundaan atau coroutine di viewModelScope. Jangan bebaskan sumber daya ViewModel — ViewModel bertahan dari onStop dan akan digunakan saat kembali.

Perbedaan antara onStop dan onPause

onPause dan onStop berbeda dalam tingkat kehilangan visibilitas dan volume tindakan wajib. onPause dipanggil saat kehilangan fokus sebagian (misalnya, membuka jendela dialog atau menu sistem), onStop — saat kehilangan visibilitas sepenuhnya. Perbedaan ini penting untuk memilih sumber daya mana yang akan dibebaskan di setiap tahap.

Aturan umum: di onPause, bebaskan sumber daya sistem yang segera memengaruhi pengalaman pengguna aplikasi lain (kamera, pemutar media), di onStop — semua sumber daya lain yang tidak diperlukan saat Activity tersembunyi. Google merekomendasikan untuk menyimpan data kritis pengguna di onPause (draf email, pengaturan), karena onStop mungkin tidak terjadi saat peralihan cepat.

onStop → onRestart: kembali ke layar

Ketika pengguna kembali ke Activity yang tersembunyi, sistem memanggil onRestart → onStart → onResume. Metode onRestart menandakan bahwa Activity kembali dari status Stopped. Ini adalah tahap penting untuk memulihkan UI dan sumber daya yang telah dibebaskan di onStop.

Urutan panggilan saat kembali:

• onRestart() — Activity diberitahu bahwa akan ditampilkan kembali. Tindakan tipikal: memuat ulang data, memperbarui daftar.
• onStart() — Activity menjadi terlihat, tetapi belum aktif. Di sini sumber daya yang dibebaskan di onStop diinisialisasi ulang.
• onResume() — Activity menerima fokus dan siap untuk berinteraksi. Animasi dimulai, sensor didaftarkan.

Jika proses aplikasi dimatikan oleh sistem dalam status Stopped, onCreate dipanggil sebagai pengganti onRestart, dan Bundle dari onSaveInstanceState diteruskan untuk pemulihan status. Skenario ini (process death) — salah satu penyebab bug paling umum di aplikasi Android: pengembang mengimplementasikan onRestart tetapi lupa mempertimbangkan pemulihan melalui onCreate setelah proses dimatikan.

Contoh kode dengan onStop di Kotlin

Contoh 1: Implementasi dasar onStop dengan pembebasan sensor

Menunjukkan cara berhenti berlangganan sensor yang benar dan menghentikan animasi saat Activity disembunyikan. Setelah kembali ke layar, sumber daya dipulihkan di 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 kembali dari status Stopped")
    }

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

Kode mendaftarkan sensor akselerometer dan memulai animasi rotasi tak terbatas di onStart. Di onStop, sensor dimatikan dan animasi dibatalkan — ini mencegah konsumsi baterai saat Activity tersembunyi. Setelah kembali melalui onRestart → onStart, sumber daya dibuat ulang.

Contoh 2: onStop dengan penyimpanan status melalui SavedStateHandle

Pendekatan modern menggunakan ViewModel + SavedStateHandle. Data formulir disimpan secara otomatis di onStop tanpa Bundle manual.

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 disimpan di SavedStateHandle")
    }
}

SavedStateHandle secara otomatis menyimpan nilai di Bundle saat onSaveInstanceState, yang dipanggil sebelum onStop. Saat rotasi layar atau pemutusan proses, data dipulihkan tanpa kehilangan. Google merekomendasikan SavedStateHandle untuk formulir dan draf daripada onSaveInstanceState langsung.

Contoh 3: lifecycleScope untuk operasi di onStop

Menggunakan lifecycleScope dengan coroutine untuk penyimpanan data asinkron saat transisi ke onStop. Coroutine dimulai di dispatcher IO, tidak memblokir thread utama.

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", "Draf disimpan di onStop")
            }
        }
        super.onStop()
    }
}

Coroutine lifecycleScope.launch secara otomatis dibatalkan jika siklus hidup Activity berakhir. Penggunaan Dispatchers.IO menjamin bahwa penulisan ke database atau file tidak memblokir kembali ke Activity. Menurut Google, coroutine di lifecycleScope adalah cara yang lebih disukai untuk operasi asinkron di onStop.