Siklus hidup aktivitas

Saat pengguna membuka, keluar, dan kembali ke aplikasi Anda, instance Activity dalam aplikasi Anda akan bertransisi melalui berbagai status dalam siklus prosesnya. Class Activity menyediakan sejumlah callback yang memberi tahu aktivitas saat status berubah atau saat sistem membuat, menghentikan, atau melanjutkan aktivitas atau menghancurkan proses tempat aktivitas berada.

Dalam metode callback siklus proses, Anda dapat mendeklarasikan perilaku aktivitas saat pengguna keluar dan masuk kembali ke aktivitas. Misalnya, jika Anda membuat pemutar video streaming, Anda dapat menjeda video dan menghentikan koneksi jaringan saat pengguna beralih ke aplikasi lain. Saat pengguna kembali, Anda dapat menghubungkan kembali ke jaringan dan mengizinkan pengguna melanjutkan video dari tempat yang sama.

Setiap callback memungkinkan Anda melakukan pekerjaan tertentu yang sesuai dengan perubahan status tertentu. Melakukan pekerjaan yang tepat pada waktu yang tepat dan menangani transisi dengan benar akan membuat aplikasi Anda lebih andal dan berperforma tinggi. Misalnya, penerapan callback siklus proses yang baik dapat membantu aplikasi Anda menghindari hal berikut:

• Error jika pengguna menerima panggilan telepon atau beralih ke aplikasi lain saat menggunakan aplikasi Anda.
• Menggunakan resource sistem yang berharga saat pengguna tidak menggunakannya secara aktif.
• Kehilangan progres pengguna jika mereka keluar dari aplikasi Anda dan kembali lagi di lain waktu.
• Error atau kehilangan progres pengguna saat layar diputar antara orientasi lanskap dan potret.

Dokumen ini menjelaskan siklus proses aktivitas secara detail. Dokumen ini dimulai dengan menjelaskan paradigma siklus proses. Selanjutnya, bagian ini menjelaskan setiap callback: apa yang terjadi secara internal saat callback dijalankan dan apa yang perlu Anda terapkan selama callback tersebut.

Kemudian, bagian ini akan memperkenalkan secara singkat hubungan antara status aktivitas dan kerentanan proses untuk dihentikan oleh sistem. Terakhir, bagian ini membahas beberapa topik terkait transisi antara status aktivitas.

Untuk mengetahui informasi tentang cara menangani siklus proses, termasuk panduan tentang praktik terbaik, lihat Siklus proses di Jetpack Compose dan Menyimpan status UI. Untuk mempelajari cara merancang aplikasi yang tangguh dan berkualitas produksi menggunakan aktivitas yang dikombinasikan dengan komponen arsitektur, lihat Panduan arsitektur aplikasi.

Konsep siklus proses aktivitas

Untuk mengarahkan transisi di antara tahap-tahap siklus proses aktivitas, class Activity menyediakan rangkaian inti yang terdiri dari enam callback: onCreate, onStart, onResume, onPause, onStop, dan onDestroy. Sistem memanggil setiap callback ini saat aktivitas memasuki status baru.

Gambar 1 menampilkan representasi visual paradigma ini.

Saat pengguna mulai keluar dari aktivitas, sistem akan memanggil metode untuk menghentikan aktivitas. Dalam beberapa kasus, aktivitas hanya dibongkar sebagian dan masih berada di memori, seperti saat pengguna beralih ke aplikasi lain. Dalam kasus ini, aktivitas masih dapat kembali ke latar depan.

Jika pengguna kembali ke aktivitas, aktivitas akan dilanjutkan dari tempat pengguna meninggalkannya. Dengan beberapa pengecualian, aplikasi dibatasi untuk memulai aktivitas saat berjalan di latar belakang.

Kemungkinan sistem menghentikan proses tertentu, beserta aktivitas di dalamnya, bergantung pada status aktivitas pada saat itu. Untuk informasi selengkapnya tentang hubungan antara status dan kerentanan terhadap pengeluaran, lihat bagian tentang status aktivitas dan pengeluaran dari memori.

Bergantung pada kompleksitas aktivitas, Anda mungkin tidak perlu mengimplementasikan semua metode siklus proses. Namun, Anda harus memahami masing-masing dan menerapkan yang membuat aplikasi Anda berperilaku sesuai harapan pengguna.

Compose dan Siklus Proses

Di Compose, hindari menempatkan logika bisnis atau penyiapan observer manual secara langsung dalam callback aktivitas seperti onStart atau onResume. Sebagai gantinya, gunakan efek berbasis Lifecycle dan observer berbasis status yang otomatis selaras dengan kehadiran UI di layar.

• Pengumpulan berbasis siklus proses: Gunakan collectAsStateWithLifecycle untuk menggunakan flow dari ViewModel Anda. API ini otomatis mulai mengumpulkan saat UI memasuki status Started dan berhenti saat UI beralih ke latar belakang, sehingga mencegah konsumsi resource yang tidak perlu. Setelah mengumpulkan flow sebagai status, Anda dapat menggunakan LifecycleEffects untuk menjalankan kode saat peristiwa Siklus Proses terjadi.
• Alur logika: Dengan menggunakan API ini, UI bereaksi terhadap status siklus proses secara alami melalui hierarki komposisi, sehingga memastikan bahwa logika bisnis hanya dijalankan saat pengguna berinteraksi secara aktif dengan komponen.

Untuk mengetahui informasi selengkapnya tentang Compose dan siklus proses, lihat Siklus proses di Jetpack Compose.

Callback siklus proses

Bagian ini memberikan informasi konseptual dan implementasi tentang metode callback yang digunakan selama siklus proses aktivitas.

Beberapa tindakan termasuk dalam metode siklus proses aktivitas. Namun, tempatkan kode yang mengimplementasikan tindakan komponen dependen dalam komponen, bukan metode siklus proses aktivitas. Untuk mencapai hal ini, Anda perlu membuat komponen dependen berbasis siklus proses. Untuk mempelajari cara membuat komponen dependen berbasis siklus proses, lihat Siklus proses di Jetpack Compose.

onCreate

Anda harus menerapkan callback ini, yang aktif saat sistem pertama kali membuat aktivitas. Pada pembuatan aktivitas, aktivitas memasuki status Dibuat. Dalam metode onCreate, jalankan logika startup aplikasi dasar yang hanya terjadi sekali selama seluruh siklus proses aktivitas.

Misalnya, implementasi onCreate Anda mungkin mengikat data ke daftar, mengaitkan aktivitas dengan ViewModel, dan membuat instance beberapa variabel cakupan class. Metode ini menerima parameter savedInstanceState, yang merupakan objek Bundle yang berisi status aktivitas yang disimpan sebelumnya. Jika aktivitas belum pernah ada sebelumnya, nilai objek Bundle adalah null.

Jika Anda memiliki komponen berbasis siklus proses yang terhubung ke siklus proses aktivitas, komponen tersebut akan menerima peristiwa ON_CREATE. Metode yang dianotasi dengan @OnLifecycleEvent dipanggil sehingga komponen berbasis siklus proses dapat menjalankan kode penyiapan apa pun yang diperlukan untuk status yang dibuat.

Contoh berikut menunjukkan cara mengintegrasikan composable Text dalam aktivitas minimal:

class ExampleActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent { // In here, we can call composables!
            MaterialTheme {
                Greeting(name = "compose")
            }
        }
    }
}

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}
InteroperabilityAPIsSnippets.kt

Aktivitas Anda tidak tetap dalam status Created. Setelah metode onCreate selesai dieksekusi, aktivitas akan memasuki status Started dan sistem akan memanggil metode onStart dan onResume secara berurutan.

onStart

Saat aktivitas memasuki status Started, sistem akan memanggil onStart. Panggilan ini membuat aktivitas terlihat oleh pengguna saat aplikasi bersiap agar aktivitas memasuki latar depan dan menjadi interaktif. Misalnya, metode ini adalah tempat kode yang mengelola UI diinisialisasi.

Saat aktivitas berpindah ke status Started, komponen berbasis siklus proses yang terkait dengan siklus proses aktivitas akan menerima peristiwa ON_START.

Metode onStart selesai dengan cepat dan, seperti status Created, aktivitas tidak tetap dalam status Started. Setelah callback ini selesai, aktivitas akan memasuki status Resumed dan sistem akan memanggil metode onResume.

onResume

Saat aktivitas memasuki status Dilanjutkan, aktivitas akan muncul di latar depan, dan sistem akan memanggil callback onResume. Ini adalah status saat aplikasi berinteraksi dengan pengguna. Aplikasi tetap dalam status ini hingga terjadi sesuatu yang mengalihkan fokus dari aplikasi, seperti perangkat menerima panggilan telepon, pengguna membuka aktivitas lain, atau layar perangkat nonaktif.

Saat aktivitas berpindah ke status Dilanjutkan, komponen berbasis siklus proses yang terkait dengan siklus proses aktivitas akan menerima peristiwa ON_RESUME. Di sinilah komponen siklus proses dapat mengaktifkan fungsi apa pun yang perlu dijalankan saat komponen terlihat dan berada di latar depan, seperti memulai pratinjau kamera.

Saat terjadi peristiwa yang mengganggu, aktivitas akan memasuki status Paused dan sistem akan memanggil callback onPause.

Jika aktivitas kembali ke status Dilanjutkan dari status Dijeda, sistem akan memanggil metode onResume sekali lagi. Oleh karena itu, terapkan onResume untuk melakukan inisialisasi komponen yang Anda rilis selama onPause dan untuk melakukan inisialisasi lain yang harus terjadi setiap kali aktivitas memasuki status Dilanjutkan.

Berikut adalah contoh komponen berbasis siklus proses yang mengakses kamera saat komponen menerima peristiwa ON_RESUME:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun initializeCamera() {
        if (camera == null) {
            getCamera()
        }
    }
    ...
}

Kode sebelumnya menginisialisasi kamera setelah LifecycleObserver menerima peristiwa ON_RESUME. Namun, dalam mode multi-aplikasi, aktivitas Anda mungkin terlihat sepenuhnya meskipun dalam status Dijeda. Misalnya, saat aplikasi berada dalam mode multi-aplikasi dan pengguna mengetuk jendela yang tidak berisi aktivitas Anda, aktivitas Anda akan berpindah ke status Dijeda.

Jika Anda ingin kamera aktif hanya saat aplikasi Dilanjutkan (terlihat dan aktif di latar depan), lakukan inisialisasi kamera setelah peristiwa ON_RESUME yang ditunjukkan sebelumnya. Jika Anda ingin kamera tetap aktif saat aktivitas Dijeda, tetapi terlihat, seperti dalam mode multi-aplikasi, lakukan inisialisasi kamera setelah peristiwa ON_START.

Namun, mengaktifkan kamera saat aktivitas Anda Dijeda dapat menolak akses ke kamera untuk aplikasi lain yang Dilanjutkan dalam mode multi-aplikasi. Terkadang, Anda perlu menjaga kamera tetap aktif saat aktivitas Dijeda, tetapi hal ini mungkin akan menurunkan pengalaman pengguna secara keseluruhan jika Anda melakukannya.

Oleh karena itu, pikirkan baik-baik di mana dalam siklus proses yang paling tepat untuk mengontrol resource sistem bersama dalam konteks mode multi-aplikasi. Untuk mempelajari lebih lanjut cara mendukung mode multi-aplikasi, lihat Mendukung mode multi-aplikasi.

Terlepas dari peristiwa build-up yang Anda pilih untuk melakukan operasi inisialisasi, pastikan untuk menggunakan peristiwa siklus proses yang sesuai untuk merilis resource. Jika Anda melakukan inisialisasi sesuatu setelah peristiwa ON_START, rilis atau hentikan setelah peristiwa ON_STOP. Jika Anda melakukan inisialisasi setelah peristiwa ON_RESUME, lepaskan setelah peristiwa ON_PAUSE.

Cuplikan kode sebelumnya menempatkan kode inisialisasi kamera dalam komponen berbasis siklus proses. Sebagai gantinya, Anda dapat menempatkan kode ini langsung ke dalam callback siklus proses aktivitas, seperti onStart dan onStop, tetapi kami tidak merekomendasikannya. Menambahkan logika ini ke komponen independen yang berbasis siklus proses memungkinkan Anda menggunakan kembali komponen di beberapa aktivitas tanpa harus menduplikasi kode. Untuk mempelajari cara membuat komponen berbasis siklus proses, lihat Siklus proses di Jetpack Compose.

onPause

Sistem memanggil metode ini sebagai indikasi pertama bahwa pengguna keluar dari aktivitas Anda, meskipun tidak selalu berarti aktivitas tersebut dihancurkan. Hal ini menunjukkan bahwa aktivitas tidak lagi berada di latar depan, tetapi masih terlihat jika pengguna berada dalam mode multi-aplikasi. Ada beberapa alasan mengapa aktivitas dapat memasuki status ini:

• Peristiwa yang mengganggu eksekusi aplikasi, seperti yang dijelaskan di bagian tentang callback onResume, akan menjeda aktivitas saat ini. Ini adalah kasus yang paling umum.
• Dalam mode multi-aplikasi, hanya satu aplikasi yang memiliki fokus pada satu waktu, dan sistem menjeda semua aplikasi lainnya.
• Pembukaan aktivitas baru yang semi-transparan, seperti dialog, akan menjeda aktivitas yang dicakupnya. Selama aktivitas terlihat sebagian, tetapi tidak dalam fokus, aktivitas akan tetap dijeda.

Saat aktivitas berpindah ke status Dijeda, komponen berbasis siklus proses yang terkait dengan siklus proses aktivitas akan menerima peristiwa ON_PAUSE. Di sinilah komponen siklus proses dapat menghentikan fungsi apa pun yang tidak perlu dijalankan saat komponen tidak berada di latar depan, seperti menghentikan pratinjau kamera.

Gunakan metode onPause untuk menjeda atau menyesuaikan operasi yang tidak dapat dilanjutkan, atau mungkin dilanjutkan dalam jumlah sedang, saat Activity dalam status Dijeda, dan yang Anda harapkan akan segera dilanjutkan.

Anda juga dapat menggunakan metode onPause untuk merilis resource sistem, handle ke sensor (seperti GPS), atau resource apa pun yang memengaruhi masa pakai baterai saat aktivitas Anda Dijeda dan pengguna tidak membutuhkannya.

Namun, seperti yang disebutkan di bagian tentang onResume, aktivitas Dijeda mungkin masih terlihat sepenuhnya jika aplikasi berada dalam mode multi-aplikasi. Sebaiknya gunakan onStop, bukan onPause, untuk sepenuhnya merilis atau menyesuaikan resource dan operasi terkait UI agar lebih mendukung mode multi-aplikasi.

Contoh LifecycleObserver berikut yang bereaksi terhadap peristiwa ON_PAUSE adalah pasangan dari contoh peristiwa ON_RESUME sebelumnya, yang merilis kamera yang melakukan inisialisasi setelah peristiwa ON_RESUME diterima:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun releaseCamera() {
        camera?.release()
        camera = null
    }
    ...
}

Contoh ini menempatkan kode rilis kamera setelah peristiwa ON_PAUSE diterima oleh LifecycleObserver.

Eksekusi onPause sangat singkat dan tidak selalu memberikan cukup waktu untuk melakukan operasi penyimpanan. Oleh karena itu, jangan gunakan onPause untuk menyimpan data aplikasi atau pengguna, melakukan panggilan jaringan, atau menjalankan transaksi database. Pekerjaan tersebut mungkin tidak selesai sebelum metode selesai.

Sebagai gantinya, lakukan operasi penonaktifan beban berat selama onStop. Untuk mengetahui informasi selengkapnya tentang operasi yang sesuai untuk dilakukan selama onStop, lihat bagian berikutnya. Untuk mengetahui informasi selengkapnya tentang cara menyimpan data, lihat bagian tentang menyimpan dan memulihkan status.

Penyelesaian metode onPause tidak berarti bahwa aktivitas keluar dari status Dijeda. Sebaliknya, aktivitas tetap dalam status ini hingga aktivitas dilanjutkan atau menjadi sepenuhnya tidak terlihat oleh pengguna. Jika aktivitas dilanjutkan, sistem akan memanggil callback onResume sekali lagi.

Jika aktivitas kembali dari status Dijeda ke status Dilanjutkan, sistem akan mempertahankan instance Activity di memori, dan memanggil kembali instance tersebut saat sistem memanggil onResume. Dalam skenario ini, Anda tidak perlu melakukan inisialisasi ulang komponen yang dibuat selama metode callback apa pun yang mengarah ke status Dilanjutkan. Jika aktivitas menjadi tidak terlihat sepenuhnya, sistem akan memanggil onStop.

onStop

Jika aktivitas Anda tidak lagi terlihat oleh pengguna, aktivitas tersebut akan memasuki status Dihentikan, dan sistem akan memanggil callback onStop. Hal ini dapat terjadi saat aktivitas yang baru diluncurkan menutupi seluruh layar. Sistem juga memanggil onStop saat aktivitas selesai berjalan dan akan dihentikan.

Saat aktivitas berpindah ke status Dihentikan, komponen berbasis siklus proses yang terkait dengan siklus proses aktivitas akan menerima peristiwa ON_STOP. Di sinilah komponen siklus proses dapat menghentikan fungsi apa pun yang tidak perlu dijalankan saat komponen tidak terlihat di layar.

Dalam metode onStop, rilis atau sesuaikan resource yang tidak diperlukan saat aplikasi tidak terlihat oleh pengguna. Misalnya, aplikasi Anda mungkin menjeda animasi atau beralih dari pembaruan lokasi akurat ke pembaruan lokasi umum. Menggunakan onStop, bukan onPause, berarti pekerjaan terkait UI akan terus berlanjut, bahkan saat pengguna melihat aktivitas Anda dalam mode multi-aplikasi.

Selain itu, gunakan onStop untuk melakukan operasi penonaktifan yang relatif intensif CPU. Misalnya, jika Anda tidak dapat menemukan waktu yang lebih baik untuk menyimpan informasi ke database, Anda dapat melakukannya selama onStop. Contoh berikut menunjukkan implementasi onStop yang menyimpan konten draf catatan ke penyimpanan persisten:

override fun onStop() {
    super.onStop()

    // Delegate the save operation to the ViewModel, which handles the
    // background thread operations (e.g., using Kotlin Coroutines and Room).
    noteViewModel.saveDraft()
}

Saat aktivitas Anda memasuki status Dihentikan, objek Activity akan tetap berada di memori: objek ini mempertahankan semua informasi status dan anggota, tetapi tidak terpasang ke pengelola jendela. Saat aktivitas dilanjutkan, aktivitas akan mengingat informasi ini.

Dari status Berhenti, aktivitas akan kembali untuk berinteraksi dengan pengguna, atau aktivitas akan selesai berjalan dan hilang. Jika aktivitas kembali, sistem akan memanggil onRestart. Jika Activity selesai berjalan, sistem akan memanggil onDestroy.

onDestroy

onDestroy dipanggil sebelum aktivitas dihancurkan. Sistem memanggil callback ini karena salah satu dari dua alasan:

1. Aktivitas sedang diselesaikan, karena pengguna menutup aktivitas sepenuhnya atau karena finish dipanggil pada aktivitas.
2. Sistem akan menghancurkan aktivitas untuk sementara karena perubahan konfigurasi, seperti rotasi perangkat atau memasuki mode multi-aplikasi.

Saat aktivitas berpindah ke status dihancurkan, komponen berbasis siklus proses yang terkait dengan siklus proses aktivitas akan menerima peristiwa ON_DESTROY. Di sinilah komponen siklus proses dapat membersihkan apa pun yang diperlukan sebelum Activity dihancurkan.

Daripada menempatkan logika di Activity untuk menentukan alasan penghancurannya, gunakan objek ViewModel untuk memuat data tampilan yang relevan untuk Activity. Jika Activity dibuat ulang karena perubahan konfigurasi, ViewModel tidak perlu melakukan apa pun, karena dipertahankan dan diberikan ke instance Activity berikutnya.

Jika Activity tidak dibuat ulang, ViewModel akan memanggil metode onCleared, yang dapat membersihkan data yang diperlukan sebelum dihancurkan. Anda dapat membedakan kedua skenario ini dengan metode isFinishing.

Jika aktivitas selesai, onDestroy adalah callback siklus proses terakhir yang diterima aktivitas. Jika onDestroy dipanggil sebagai hasil dari perubahan konfigurasi, sistem akan segera membuat instance aktivitas baru, lalu memanggil onCreate pada instance baru tersebut dalam konfigurasi baru.

Callback onDestroy merilis semua resource yang tidak dirilis oleh callback sebelumnya, seperti onStop.

Status aktivitas dan pengeluaran dari memori

Sistem akan menghentikan proses saat perlu mengosongkan RAM. Kemungkinan sistem menghentikan proses tertentu bergantung pada status proses pada saat itu. Status proses, pada gilirannya, bergantung pada status aktivitas yang berjalan dalam proses. Tabel 1 menunjukkan korelasi antara status proses, status aktivitas, dan kemungkinan sistem menghentikan proses. Tabel ini hanya berlaku jika proses tidak menjalankan jenis komponen aplikasi lainnya.

Tabel 1. Hubungan antara siklus proses proses dan status aktivitas.

Sistem tidak pernah menutup aktivitas secara langsung untuk membebaskan memori. Sebagai gantinya, sistem akan menghentikan proses tempat aktivitas berjalan, sehingga tidak hanya menghancurkan aktivitas, tetapi juga semua hal lain yang berjalan dalam proses tersebut. Untuk mempelajari cara mempertahankan dan memulihkan status UI aktivitas Anda saat terjadi penghentian proses yang dimulai oleh sistem, lihat bagian tentang menyimpan dan memulihkan status.

Pengguna juga dapat menghentikan proses dengan menggunakan Pengelola Aplikasi, di bagian Setelan, untuk menghentikan aplikasi yang sesuai.

Untuk mengetahui informasi selengkapnya tentang proses, lihat Ringkasan proses dan thread.

Menyimpan dan memulihkan status UI sementara

Pengguna berharap status UI aktivitas tetap sama selama perubahan konfigurasi, seperti rotasi atau beralih ke mode multi-aplikasi. Namun, sistem menutup aktivitas secara default ketika perubahan konfigurasi tersebut terjadi, sehingga menghapus semua status UI yang disimpan dalam instance aktivitas.

Demikian pula, pengguna berharap status UI tetap sama jika pengguna untuk sementara beralih dari aplikasi Anda ke aplikasi lain, lalu kembali ke aplikasi Anda nanti. Namun, sistem dapat menghancurkan proses aplikasi Anda saat pengguna tidak aktif dan aktivitas Anda dihentikan.

Saat batasan sistem menghancurkan aktivitas, pertahankan status UI sementara pengguna menggunakan kombinasi ViewModel (untuk logika bisnis dan status layar yang kompleks), API rememberSaveable Jetpack Compose (untuk status UI ringan), dan/atau penyimpanan lokal. Untuk mempelajari lebih lanjut ekspektasi pengguna dibandingkan dengan perilaku sistem dan cara terbaik untuk mempertahankan data status UI yang kompleks di seluruh aktivitas yang dimulai sistem dan penghentian proses, lihat Menyimpan status UI.

rememberSaveable otomatis bertahan dari perubahan konfigurasi dan penghentian proses yang dimulai sistem dengan menggabungkan status di balik layar, sehingga memberikan pengalaman yang lancar tanpa memerlukan boilerplate tingkat aktivitas.

Status instance

Ada beberapa skenario yang menyebabkan aktivitas Anda dihancurkan karena perilaku aplikasi yang normal, seperti saat pengguna menekan tombol Kembali atau aktivitas Anda memberi sinyal penghancurannya sendiri dengan memanggil metode finish.

Saat aktivitas Anda dihancurkan karena pengguna menekan Kembali atau aktivitas selesai dengan sendirinya, konsep sistem dan pengguna tentang instance Activity tersebut akan hilang selamanya. Dalam skenario ini, ekspektasi pengguna sesuai dengan perilaku sistem, dan Anda tidak perlu melakukan pekerjaan tambahan.

Namun, jika sistem menghancurkan aktivitas karena batasan sistem (seperti perubahan konfigurasi atau tekanan memori), meskipun instance Activity yang sebenarnya hilang, sistem akan mengingat bahwa instance tersebut pernah ada. Jika pengguna mencoba menavigasi kembali ke aktivitas, sistem akan membuat instance baru aktivitas tersebut menggunakan kumpulan data tersimpan yang menjelaskan status aktivitas saat dihancurkan.

Data tersimpan yang digunakan sistem untuk memulihkan status sebelumnya disebut status instance. Di balik layar, ini adalah kumpulan key-value pair. Secara default, sistem menggunakan status instance untuk menyimpan informasi dasar tentang tata letak UI Anda, seperti input teks pengguna atau posisi scroll.

Anda dapat memanfaatkan perilaku sistem ini menggunakan rememberSaveable. Jika instance aktivitas Anda dihancurkan dan dibuat ulang, status UI apa pun yang digabungkan dalam rememberSaveable akan otomatis dipulihkan, tanpa memerlukan kode tingkat aktivitas tambahan dari Anda.

Namun, aktivitas Anda kemungkinan akan memiliki informasi status yang lebih kompleks yang ingin Anda pulihkan, seperti data pengguna, respons jaringan, atau variabel anggota yang melacak progres pengguna. Mekanisme status instance (dan, lebih jauh lagi, rememberSaveable) tidak sesuai untuk mempertahankan data dalam jumlah yang lebih dari sekadar sepele, karena memerlukan serialisasi pada thread utama dan menggunakan memori proses sistem.

Untuk mempertahankan lebih dari sedikit data, gunakan pendekatan gabungan menggunakan penyimpanan lokal persisten, class ViewModel, dan pengangkatan status Compose, seperti yang diuraikan dalam Menyimpan status UI.

Menyimpan status UI yang sederhana dan ringan menggunakan rememberSaveable

Saat aktivitas Anda mulai berhenti, sistem akan bersiap untuk menyimpan informasi status ke paket status instance. Untuk mengaitkan ke perilaku sistem ini, Anda menggunakan rememberSaveable langsung dalam fungsi composable. rememberSaveable otomatis menyimpan dan memulihkan status UI sementara, seperti input teks pengguna atau posisi scroll, di seluruh pembuatan ulang aktivitas.

Untuk menyimpan informasi status kustom yang ringan (seperti progres pengguna dalam game), deklarasikan status Anda menggunakan rememberSaveable. Framework Compose menangani serialisasi ke paket status instance di balik layar:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}
StateOverviewSnippets.kt

Untuk menyimpan data persisten, seperti preferensi pengguna atau data untuk database, ambil peluang yang sesuai saat aktivitas Anda berada di latar depan. Jika tidak ada peluang seperti itu, simpan data persisten selama metode onStop.

Memulihkan status UI aktivitas menggunakan status instance tersimpan

Saat aktivitas Anda dibuat ulang setelah sebelumnya dihancurkan, pemulihan status akan otomatis dilakukan. Saat menggunakan rememberSaveable, Anda tidak perlu menulis logika pemulihan eksplisit, memeriksa paket null, atau mengganti callback aktivitas. Kode yang melakukan inisialisasi dan menyimpan status Anda juga memulihkannya dengan lancar saat aktivitas kembali:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}
StateOverviewSnippets.kt

Aktivitas dan navigasi

Aplikasi kemungkinan akan bertransisi antar-layar berkali-kali selama masa aktifnya, seperti saat pengguna mengetuk tombol Kembali perangkat atau memilih tujuan baru. Aplikasi Android modern biasanya menggunakan arsitektur aktivitas tunggal. Alih-alih memulai Activity baru untuk setiap layar, aplikasi Anda menghosting satu Activity dan menggunakan komponen Navigation untuk menukar layar composable dalam aktivitas tersebut.

Untuk mempelajari cara menerapkan navigasi modern yang mengutamakan Compose, lihat panduan untuk library Navigation 3 Jetpack Compose.

Memulai satu aktivitas dari aktivitas lain

Suatu aktivitas mungkin perlu memulai aktivitas lain pada suatu waktu. Kebutuhan ini muncul, misalnya, saat aplikasi perlu berpindah dari layar saat ini ke layar baru.

Bergantung pada apakah aktivitas Anda menginginkan hasil kembali dari aktivitas baru yang akan dimulai, Anda memulai aktivitas baru menggunakan metode startActivity atau metode startActivityForResult. Dalam kedua kasus tersebut, Anda meneruskan objek Intent.

Objek Intent menentukan aktivitas persis yang ingin Anda mulai atau menjelaskan jenis tindakan yang ingin Anda lakukan. Sistem akan memilih aktivitas yang sesuai untuk Anda, yang bahkan dapat berasal dari aplikasi lain. Objek Intent juga dapat membawa sejumlah kecil data untuk digunakan oleh aktivitas yang dimulai. Untuk informasi selengkapnya tentang class Intent, lihat Intent dan Filter Intent.

startActivity

Jika aktivitas yang baru dimulai tidak perlu menampilkan hasil, aktivitas saat ini dapat memulainya dengan memanggil metode startActivity.

Saat bekerja dalam aplikasi Anda sendiri, Anda sering kali hanya perlu meluncurkan aktivitas yang diketahui. Misalnya, cuplikan kode berikut menunjukkan cara meluncurkan aktivitas yang disebut SignInActivity.

val context = LocalContext.current

Button(onClick = {
    val intent = Intent(context, SignInActivity::class.java)
    context.startActivity(intent)
}) {
    Text("Sign In")
}

Memulai aktivitas eksternal

Meskipun navigasi aplikasi internal ditangani oleh Navigation, Activity Anda terkadang perlu memulai aktivitas lain. Hal ini biasanya terjadi saat Anda ingin memanfaatkan aplikasi eksternal untuk melakukan tindakan tertentu, seperti membuka browser web, mengirim email, atau mengambil foto.

Untuk melakukannya, Anda menggunakan objek Intent untuk mendeskripsikan jenis tindakan yang ingin Anda lakukan, dan sistem akan meluncurkan aktivitas yang sesuai dari aplikasi lain.

Misalnya, jika ingin mengizinkan pengguna mengirim pesan email, Anda dapat membuat intent berikut:

val intent = Intent(Intent.ACTION_SEND).apply {
    putExtra(Intent.EXTRA_EMAIL, recipientArray)
}
startActivity(intent)

Jika Anda perlu meluncurkan aktivitas eksternal dan mendapatkan hasilnya kembali (seperti meminta aplikasi kamera untuk mengambil foto dan menampilkan gambar), gunakan API hasil Activity modern, bukan callback startActivityForResult yang tidak digunakan lagi.

Mengoordinasikan aktivitas

Bila suatu aktivitas memulai aktivitas lain, keduanya akan mengalami transisi siklus proses. Aktivitas pertama berhenti beroperasi dan memasuki status Dijeda atau Dihentikan, sementara aktivitas lainnya dibuat. Jika aktivitas ini berbagi data yang disimpan ke disk atau di tempat lain, penting untuk dipahami bahwa aktivitas pertama tidak sepenuhnya dihentikan sebelum aktivitas kedua dibuat. Sebaliknya, proses memulai yang kedua tumpang-tindih dengan proses menghentikan yang pertama.

Urutan callback siklus proses ditentukan dengan baik, terutama saat kedua aktivitas berada dalam proses yang sama—dengan kata lain, aplikasi yang sama—dan salah satunya memulai aktivitas yang lain. Berikut adalah urutan operasi yang terjadi saat Aktivitas A memulai Aktivitas B:

1. Metode onPause Aktivitas A dijalankan.
2. Metode onCreate, onStart, dan onResume Aktivitas B dijalankan secara berurutan. Aktivitas B kini mendapatkan fokus pengguna.
3. Jika Aktivitas A tidak lagi terlihat di layar, metode onStop-nya akan dijalankan.

Urutan callback siklus proses ini memungkinkan Anda mengelola transisi informasi dari satu aktivitas ke aktivitas lainnya.

Referensi lainnya

Untuk mempelajari siklus proses aktivitas lebih lanjut, lihat referensi tambahan berikut:

Konten penayangan

• Siklus proses aktivitas (View)