Waktu memulai aplikasi

Pengguna mengharapkan aplikasi dimuat dengan cepat dan responsif. Aplikasi dengan waktu mulai lambat tidak memenuhi harapan ini dan dapat mengecewakan pengguna. Pengalaman buruk semacam ini dapat menyebabkan pengguna memberikan rating yang buruk ke aplikasi Anda di Play Store, atau bahkan berhenti menggunakan aplikasi Anda.

Halaman ini memberikan informasi untuk membantu mengoptimalkan waktu peluncuran aplikasi Anda, termasuk ringkasan internal proses peluncuran, cara membuat profil performa startup, dan beberapa masalah umum waktu mulai yang disertai tips tentang cara mengatasinya.

Memahami berbagai status startup aplikasi

Peluncuran aplikasi dapat dilakukan dalam salah satu dari tiga status berikut: cold start, warm start, atau hot start. Setiap status memengaruhi waktu yang diperlukan aplikasi untuk terlihat oleh pengguna. Dalam cold start, aplikasi akan dimulai dari awal. Dalam status yang lain, sistem harus memindah aplikasi yang berjalan dari latar belakang ke latar depan.

Sebaiknya selalu lakukan pengoptimalan berdasarkan asumsi cold start. Tindakan tersebut juga dapat meningkatkan performa warm start dan hot start.

Untuk mengoptimalkan aplikasi Anda agar startup-nya cepat, memahami apa yang terjadi pada tingkat sistem dan aplikasi, serta bagaimana interaksinya dalam setiap status sangatlah berguna.

Dua metrik penting untuk menentukan startup aplikasi adalah waktu hingga tampilan awal (TTID) dan waktu hingga tampilan penuh (TTFD). TTID adalah waktu yang diperlukan untuk menampilkan frame pertama, dan TTFD adalah waktu yang diperlukan aplikasi untuk menjadi interaktif sepenuhnya. Keduanya sama pentingnya, karena TTID memberi tahu pengguna bahwa aplikasi sedang dimuat, dan TTFD adalah saat aplikasi benar-benar dapat digunakan. Jika salah satu proses ini berlangsung terlalu lama, pengguna mungkin akan keluar dari aplikasi Anda bahkan sebelum aplikasi dimuat sepenuhnya.

Cold start

Cold start mengacu pada aplikasi yang dimulai dari awal. Artinya, hingga aplikasi dimulai, proses sistem akan membuat proses aplikasi. Cold start terjadi dalam beberapa kasus seperti peluncuran aplikasi pertama kalinya sejak perangkat di-booting atau sejak sistem menghentikan aplikasi.

Jenis start ini menghadirkan tantangan terbesar untuk meminimalkan waktu startup, karena sistem dan aplikasi memiliki tugas yang lebih banyak daripada status peluncuran lainnya.

Di awal cold start, sistem memiliki tiga tugas berikut:

1. Memuat dan meluncurkan aplikasi.
2. Menampilkan jendela awal kosong untuk aplikasi, segera setelah peluncuran.
3. Membuat proses aplikasi.

Segera setelah sistem membuat proses aplikasi, proses aplikasi bertanggung jawab untuk tahap selanjutnya:

1. Membuat objek aplikasi.
2. Meluncurkan thread utama.
3. Membuat aktivitas utama.
4. Lakukan inisialisasi UI.
5. Gambar UI di layar.

Saat proses aplikasi menyelesaikan penggambaran pertama, proses sistem menukar jendela latar belakang yang ditampilkan, menggantinya dengan aktivitas utama. Pada tahap ini, pengguna dapat mulai menggunakan aplikasi.

Untuk mengetahui informasi selengkapnya tentang fase tata letak di Compose, lihat Fase Jetpack Compose.

Masalah performa dapat muncul selama pembuatan aplikasi dan pembuatan aktivitas host.

Pembuatan aplikasi

Saat aplikasi diluncurkan, jendela awal kosong tetap muncul di layar sampai sistem selesai menggambar aplikasi untuk pertama kalinya. Pada tahap ini, proses sistem menukar jendela awal aplikasi Anda, memungkinkan pengguna berinteraksi dengan aplikasi.

Jika Anda mengganti Application.onCreate di aplikasi Anda sendiri, sistem akan memanggil metode onCreate pada objek aplikasi Anda. Setelah itu, aplikasi akan memunculkan thread utama, yang juga dikenal sebagai UI thread, dan menugaskannya untuk membuat aktivitas host aplikasi Anda.

Pada tahap ini, proses tingkat aplikasi dan sistem akan dilanjutkan sesuai dengan tahap siklus proses aplikasi.

Pembuatan aktivitas

Setelah proses aplikasi membuat aktivitas Anda, aktivitas ini akan menjalankan operasi berikut:

1. Melakukan inisialisasi nilai.
2. Memanggil konstruktor.
3. Memanggil metode callback, seperti Activity.onCreate, sesuai dengan status siklus proses aktivitas saat ini.

Biasanya, metode onCreate memiliki dampak terbesar pada waktu pemuatan. Di aplikasi Jetpack Compose, overhead metode onCreate sering kali berasal dari komposisi awal. Hal ini terjadi saat aplikasi Anda memanggil setContent dan memanggil composable tingkat atas Anda. Hierarki UI yang dalam atau kompleks, atau composable yang melakukan penghitungan berat di thread utama, dapat meningkatkan waktu komposisi ini.

Warm start

Warm start mencakup subset operasi yang berlangsung selama cold start. Pada saat yang sama, warm start menunjukkan lebih banyak overhead dibandingkan hot start. Ada banyak potensi status yang dapat dianggap sebagai warm start, seperti berikut:

• Pengguna keluar dari aplikasi Anda, tetapi kemudian meluncurkannya kembali. Proses mungkin akan terus berjalan, tetapi aplikasi harus membuat ulang aktivitas dari awal menggunakan panggilan ke onCreate.

• Sistem mengeluarkan aplikasi Anda dari memori, lalu pengguna meluncurkannya kembali. Proses dan aktivitas perlu dimulai ulang, tetapi tugas dapat memanfaatkan paket status instance tersimpan yang diteruskan ke onCreate.

Hot start

Hot start pada aplikasi memiliki overhead yang lebih rendah daripada cold start. Pada hot start, sistem membawa aktivitas host aplikasi Anda ke latar depan. Jika semua UI aplikasi Anda masih tersimpan di memori, aplikasi tersebut dapat menghindari pengulangan inisialisasi objek, inisialisasi UI, dan rendering.

Namun, jika beberapa memori dihapus permanen sebagai respons terhadap peristiwa pemangkasan memori, seperti onTrimMemory, objek ini perlu dibuat ulang sebagai respons terhadap peristiwa hot start.

Hot start menampilkan perilaku on-screen yang sama dengan skenario cold start. Proses sistem menampilkan layar kosong hingga aplikasi selesai merender aktivitas.

Cara mengidentifikasi startup aplikasi di Perfetto

Untuk men-debug masalah startup aplikasi, sebaiknya tentukan apa yang sebenarnya disertakan dalam fase startup aplikasi. Untuk mengidentifikasi seluruh fase startup aplikasi di Perfetto, ikuti langkah-langkah berikut:

1. Di Perfetto, temukan baris dengan metrik turunan Android App Startups. Jika Anda tidak melihatnya, coba ambil rekaman aktivitas menggunakan aplikasi pelacakan sistem di perangkat.

   

2. Klik slice yang terkait, lalu tekan m untuk memilih slice tersebut. Tanda kurung muncul mengapit slice dan menunjukkan berapa lama waktu yang dibutuhkan. Durasi juga ditampilkan di tab Current selection.

3. Sematkan baris Android App Startups dengan mengklik ikon pin, yang akan terlihat saat Anda mengarahkan kursor ke baris.

4. Scroll ke baris yang berisi aplikasi yang dimaksud, lalu klik sel pertama untuk meluaskan baris.

5. Perbesar tampilan thread utama, biasanya di bagian atas, dengan menekan w (tekan s, a, d untuk memperkecil tampilan, bergerak ke kiri, dan bergerak ke kanan, secara berurutan).

   

6. Slice metrik turunan memudahkan Anda melihat apa yang sebenarnya disertakan dalam startup aplikasi, sehingga Anda dapat melanjutkan proses debug dengan lebih mendetail.

Saat menganalisis aplikasi Jetpack Compose, Anda dapat menggunakan Pelacakan komposisi untuk melihat detail terperinci tentang performa UI Anda. Perhatikan secara khusus bagian rekaman aktivitas dalam thread utama yang dimulai dengan Choreographer#doFrame. Cari irisan seperti Compose:recompose, Compose:layout, dan Compose:draw. Bagian ini menunjukkan berapa banyak waktu yang dihabiskan aplikasi Anda untuk menyusun, mengukur dan menempatkan, serta menggambar komponen tertentu.

Menggunakan metrik untuk memeriksa dan meningkatkan kualitas startup

Untuk mendiagnosis performa waktu startup dengan benar, Anda dapat melacak metrik yang menampilkan berapa lama aplikasi Anda dimulai. Android menyediakan beberapa cara untuk menunjukkan bahwa aplikasi Anda bermasalah dan membantu Anda mendiagnosisnya. Android vitals dapat memberi tahu Anda bahwa masalah terjadi, dan alat diagnostik dapat membantu Anda mendiagnosis masalah tersebut.

Manfaat menggunakan metrik startup

Android menggunakan metrik waktu hingga tampilan awal (TTID) dan waktu hingga tampilan penuh (TTFD) untuk mengoptimalkan startup aplikasi cold dan warm. Android Runtime (ART) menggunakan data dari metrik ini untuk mengompilasi kode secara efisien guna mengoptimalkan startup mendatang.

Startup yang lebih cepat menghasilkan interaksi pengguna yang lebih berkelanjutan dengan aplikasi Anda, yang mengurangi instance keluar awal, memulai ulang instance, atau berpindah ke aplikasi lain.

Android vitals

Android vitals dapat membantu meningkatkan performa aplikasi dengan memberi tahu Anda di Konsol Play, jika waktu startup aplikasi Anda berlebihan.

Android vitals menganggap waktu startup berikut terlalu berlebihan untuk aplikasi Anda:

• Cold startup membutuhkan waktu 5 detik atau lebih lama.
• Warm startup membutuhkan waktu 2 detik atau lebih lama.
• Hot startup membutuhkan waktu 1,5 detik atau lebih lama.

Android vitals menggunakan metrik waktu hingga tampilan awal (TTID). Untuk mengetahui informasi tentang cara Google Play mengumpulkan data Android vitals, lihat dokumentasi Konsol Play.

Waktu hingga tampilan awal

Waktu hingga tampilan awal (TTID) adalah waktu yang diperlukan untuk menampilkan frame pertama UI aplikasi. Metrik ini mengukur waktu yang diperlukan aplikasi untuk menghasilkan frame pertamanya, termasuk inisialisasi proses selama cold start, pembuatan aktivitas selama cold start atau warm start, dan menampilkan frame pertama. Mempertahankan TTID aplikasi Anda tetap rendah akan membantu meningkatkan pengalaman pengguna dengan memungkinkan pengguna melihat peluncuran aplikasi Anda dengan cepat. TTID dilaporkan secara otomatis untuk setiap aplikasi oleh Android Framework. Saat mengoptimalkan startup aplikasi, sebaiknya terapkan reportFullyDrawn untuk mendapatkan informasi hingga TTFD.

TTID diukur sebagai nilai waktu yang mewakili total waktu yang berlalu yang mencakup urutan peristiwa berikut:

• Meluncurkan proses.
• Menginisialisasi objek.
• Membuat dan menginisialisasi aktivitas host.
• Menginisialisasi UI.
• Menggambar aplikasi untuk pertama kalinya.

Mengambil TTID

Untuk menemukan TTID, telusuri di alat command line Logcat untuk menemukan baris output yang berisi nilai bernama Displayed. Nilai ini adalah TTID dan terlihat mirip dengan contoh berikut, yang TTID-nya adalah 3s534ms:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

Untuk menemukan TTID di Android Studio, nonaktifkan filter dalam tampilan Logcat Anda dari menu filter drop-down, lalu temukan waktu Displayed, seperti yang ditunjukkan pada gambar 4. Filter perlu dinonaktifkan karena server sistem, bukan aplikasi itu sendiri, yang menyalurkan log ini.

Metrik Displayed dalam output Logcat tidak selalu merekam jumlah waktu sampai semua resource dimuat dan ditampilkan. Metrik ini tidak menyertakan resource yang tidak direferensikan dalam komposisi awal (seperti data atau gambar yang dimuat secara asinkron) atau resource yang dibuat aplikasi sebagai bagian dari inisialisasi objek. Metrik tersebut tidak menyertakan resource ini karena memuatnya merupakan suatu proses inline dan tidak memblokir tampilan awal aplikasi. Untuk mengetahui informasi selengkapnya tentang resource, lihat Resource dalam Compose.

Terkadang baris Displayed dalam output Logcat berisi kolom tambahan untuk waktu total, seperti dalam contoh berikut:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)

Dalam hal ini, pengukuran pertama kali hanya dilakukan untuk aktivitas yang pertama kali digambar, biasanya aktivitas host. Pengukuran waktu total dimulai saat proses aplikasi dijalankan dan dapat menyertakan aktivitas lain yang dimulai terlebih dahulu, tetapi tidak menampilkan apa pun di layar. Pengukuran waktu total ditampilkan hanya jika ada perbedaan antara aktivitas tunggal dan waktu startup total.

Sebaiknya gunakan Logcat di Android Studio, tetapi jika Anda tidak menggunakan Android Studio, Anda juga dapat mengukur TTID dengan menjalankan aplikasi menggunakan perintah pengelola aktivitas shell adb. Berikut contohnya:

adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN

Metrik Displayed muncul dalam output Logcat seperti sebelumnya. Jendela terminal Anda akan menampilkan:

Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete

Argumen -c dan -a bersifat opsional dan memungkinkan Anda menentukan <category> dan <action>.

Waktu hingga tampilan penuh

Waktu hingga tampilan penuh (TTFD) adalah waktu yang dibutuhkan aplikasi untuk menjadi interaktif bagi pengguna. TTFD dilaporkan sebagai waktu yang diperlukan untuk menampilkan frame pertama UI aplikasi, serta konten yang dimuat secara asinkron setelah frame awal ditampilkan. Umumnya, ini adalah konten utama yang dimuat dari jaringan atau disk, seperti yang dilaporkan oleh aplikasi. Dengan kata lain, TTFD mencakup TTID serta waktu yang diperlukan agar aplikasi dapat digunakan. Mempertahankan TTFD aplikasi Anda tetap rendah akan membantu meningkatkan pengalaman pengguna dengan memungkinkan pengguna berinteraksi dengan aplikasi Anda secara cepat.

Meskipun sistem dapat menentukan TTID saat jendela host merender frame awalnya, sistem tidak dapat menentukan TTFD secara otomatis. Karena aplikasi sering memuat konten utamanya secara asinkron, sistem tidak tahu kapan aplikasi benar-benar dapat digunakan sepenuhnya oleh pengguna. Untuk menentukan TTFD, aplikasi perlu memberi sinyal ke sistem saat mencapai status digambar sepenuhnya.

Mengambil TTFD

Untuk menemukan TTFD, beri sinyal status digambar sepenuhnya dengan memanggil metode reportFullyDrawn dari ComponentActivity. Metode reportFullyDrawn melaporkan saat aplikasi sepenuhnya digambar dan dalam keadaan dapat digunakan. TTFD adalah waktu yang berlalu dari saat sistem menerima intent peluncuran aplikasi hingga saat reportFullyDrawn dipanggil. Jika Anda tidak memanggil reportFullyDrawn, tidak ada nilai TTFD yang dilaporkan.

Untuk mengukur TTFD, panggil reportFullyDrawn setelah Anda sepenuhnya menggambar UI dan semua data. Jangan panggil reportFullyDrawn sebelum jendela aktivitas pertama digambar dan ditampilkan untuk pertama kalinya sebagaimana diukur oleh sistem, karena sistem akan melaporkan waktu yang diukur oleh sistem. Dengan kata lain, jika Anda memanggil reportFullyDrawn sebelum sistem mendeteksi TTID, sistem akan melaporkan TTID dan TTFD sebagai nilai yang sama, dan nilai ini adalah nilai TTID.

Saat Anda menggunakan reportFullyDrawn, Logcat akan menampilkan output seperti contoh berikut, dengan TTFD 1 dtk 54 md:

system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms

Output Logcat terkadang menyertakan waktu total, seperti yang dibahas dalam Waktu hingga tampilan awal.

Jika waktu tampilan lebih lambat dari yang diinginkan, Anda dapat mencoba mengidentifikasi bottleneck dalam proses startup.

Anda dapat menggunakan reportFullyDrawn untuk menandakan status gambar yang sepenuhnya digambar dalam kasus dasar saat Anda mengetahui bahwa status gambar yang sepenuhnya digambar telah tercapai. Namun, dalam kasus ketika thread latar belakang harus menyelesaikan pekerjaan latar belakang sebelum status digambar sepenuhnya tercapai, Anda perlu menunda reportFullyDrawn untuk pengukuran TTFD yang lebih akurat. Untuk mempelajari cara menunda reportFullyDrawn, lihat bagian berikut.

Meningkatkan akurasi pengaturan waktu startup

Jika aplikasi Anda melakukan pemuatan lambat dan tampilan awal tidak menyertakan semua resource, seperti saat aplikasi Anda mengambil gambar dari jaringan, Anda mungkin ingin menunda panggilan reportFullyDrawn hingga setelah aplikasi Anda dapat digunakan sehingga Anda dapat menyertakan pengisian daftar sebagai bagian dari waktu tolok ukur.

Misalnya, jika UI berisi daftar dinamis, seperti LazyColumn atau LazyRow, UI ini mungkin diisi oleh tugas latar belakang yang selesai setelah daftar pertama kali digambar dan, karenanya, setelah UI ditandai sebagai digambar sepenuhnya. Dalam kasus tersebut, pengisian daftar tidak disertakan dalam tolok ukur.

Untuk menyertakan pengisian daftar sebagai bagian dari waktu benchmark, dapatkan FullyDrawnReporter dengan menggunakan fullyDrawnReporter, dan tambahkan pelapor ke dalamnya pada kode aplikasi Anda. Rilis reporter setelah tugas latar belakang selesai mengisi daftar.

FullyDrawnReporter tidak memanggil metode reportFullyDrawn hingga semua pelapor tambahan dilepaskan. Dengan menambahkan pelapor, tetapi tidak melepaskannya hingga proses latar belakang selesai, Anda memastikan data waktu startup mencakup waktu pengisian daftar, tanpa mengubah perilaku aplikasi untuk pengguna. reportFullyDrawn tidak dipanggil sampai semua tugas selesai, terlepas dari urutannya.

Jika aplikasi Anda menggunakan Jetpack Compose, Anda dapat menggunakan API berikut untuk menunjukkan status yang sepenuhnya digambar:

• ReportDrawn: menunjukkan bahwa composable Anda langsung siap untuk berinteraksi.
• ReportDrawnWhen: mengambil predikat, seperti list.count > 0, untuk menunjukkan kapan composable Anda siap berinteraksi.
• ReportDrawnAfter: mengambil metode penangguhan yang, setelah selesai, menunjukkan bahwa composable Anda siap untuk berinteraksi.

Contoh berikut menunjukkan cara menjalankan beberapa tugas latar belakang secara serentak, dengan mendaftarkan pelapor masing-masing:

class MainActivity : ComponentActivity() {

    sealed interface ActivityState {
        data object LOADING : ActivityState
        data object LOADED : ActivityState
    }

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

        setContent {
            var activityState by remember {
                mutableStateOf(ActivityState.LOADING as ActivityState)
            }
            fullyDrawnReporter.addOnReportDrawnListener {
                activityState = ActivityState.LOADED
            }
            ReportFullyDrawnTheme {
                when(activityState) {
                    is ActivityState.LOADING -> {
                        // Display the loading UI.
                    }
                    is ActivityState.LOADED -> {
                        // Display the full UI.
                    }
                }
            }
            SideEffect {
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

Mengidentifikasi bottleneck

Untuk mencari bottleneck, Anda dapat menggunakan CPU Profiler Android Studio. Untuk mengetahui informasi selengkapnya, lihat Memeriksa aktivitas CPU dengan CPU Profiler.

Anda juga dapat memperoleh insight tentang potensi bottleneck melalui pelacakan inline di dalam metode onCreate aplikasi dan aktivitas Anda. Untuk mempelajari pelacakan inline, lihat dokumentasi untuk fungsi Trace dan ringkasan pelacakan sistem.

Menyelesaikan masalah umum

Bagian ini membahas beberapa masalah yang kerap memengaruhi performa startup aplikasi. Masalah ini terutama menyangkut inisialisasi objek aplikasi dan aktivitas, serta pemuatan layar.

Melakukan inisialisasi aplikasi berat

Performa peluncuran dapat terpengaruh jika kode Anda mengganti objek Application dan mengeksekusi tugas berat atau logika yang kompleks saat melakukan inisialisasi objek tersebut. Aplikasi Anda dapat membuang waktu selama startup jika subclass Application Anda melakukan inisialisasi yang masih belum perlu dilakukan.

Beberapa inisialisasi mungkin sama sekali tidak diperlukan, seperti saat melakukan inisialisasi informasi status untuk aktivitas utama ketika aplikasi benar-benar dimulai sebagai respons terhadap intent. Dengan intent, aplikasi hanya menggunakan subset data status yang telah diinisialisasi sebelumnya.

Kesulitan lainnya selama inisialisasi aplikasi mencakup peristiwa pembersihan sampah memori yang paling berdampak atau sangat banyak, atau I/O disk terjadi bersamaan dengan inisialisasi, yang kemudian memblokir proses inisialisasi. Pembersihan sampah memori terutama menjadi pertimbangan dengan runtime Dalvik. Android Runtime (ART) menjalankan pembersihan sampah memori secara serentak, meminimalkan dampak operasi tersebut.

Mendiagnosis masalah

Anda dapat menggunakan metode pelacakan atau pelacakan inline untuk mendiagnosis masalahnya.

Pelacakan metode

Menjalankan CPU Profiler mengungkapkan bahwa metode callApplicationOnCreate akhirnya memanggil metode com.example.customApplication.onCreate Anda. Jika alat ini menunjukkan bahwa metode ini membutuhkan waktu lama dalam menyelesaikan eksekusi, sebaiknya pelajari lebih lanjut untuk melihat tugas apa yang terjadi di sana.

Pelacakan inline

Gunakan pelacakan inline untuk menyelidiki kemungkinan masalah, termasuk hal berikut:

• Fungsi onCreate awal aplikasi Anda.
• Semua objek singleton global yang diinisialisasi aplikasi.
• Semua I/O disk, deserialisasi, atau loop ketat yang mungkin terjadi selama bottleneck.

Solusi untuk masalah tersebut

Apa pun masalahnya, baik terletak pada inisialisasi yang tidak perlu maupun pada I/O disk, solusinya adalah inisialisasi lambat. Dengan kata lain, hanya inisialisasi objek yang segera diperlukan. Daripada membuat objek statis global, sebaiknya pindahkan ke pola singleton tempat aplikasi melakukan inisialisasi objek, hanya saat pertama kali diperlukan.

Pertimbangkan juga untuk menggunakan framework injeksi dependensi seperti Hilt yang membuat objek dan dependensi saat melakukan injeksi untuk pertama kalinya.

Jika aplikasi menggunakan penyedia konten untuk melakukan inisialisasi komponen aplikasi saat startup, sebaiknya gunakan library App Startup.

Menginisialisasi aktivitas berat

Pembuatan aktivitas kerap memerlukan banyak tugas overhead yang tinggi. Sering kali ada peluang untuk mengoptimalkan pekerjaan ini untuk mencapai peningkatan performa. Masalah umum tersebut meliputi:

• Menginisialisasi UI yang besar atau kompleks.
• Inisialisasi berat dalam composable.
• Memblokir menggambar layar pada disk, atau I/O jaringan.
• Memuat dan mendekode bitmap.
• Meraster objek VectorDrawable.
• Inisialisasi subsistem lain dari aktivitas host aplikasi.

Mendiagnosis masalah

Untuk hal ini pun, pelacakan metode dan pelacakan inline bisa bermanfaat.

Pelacakan metode

Saat menggunakan CPU Profiler, perhatikan konstruktor subclass Application dan metode com.example.customApplication.onCreate dari aplikasi Anda.

Jika alat tersebut menunjukkan bahwa metode ini membutuhkan waktu lama dalam menyelesaikan eksekusi, sebaiknya pelajari lebih lanjut untuk melihat tugas apa yang terjadi di sana.

Pelacakan inline

Gunakan pelacakan inline untuk menyelidiki kemungkinan masalah, termasuk hal berikut:

• Fungsi onCreate awal aplikasi Anda.
• Semua objek singleton global yang diinisialisasi olehnya.
• Semua I/O disk, deserialisasi, atau loop ketat yang mungkin terjadi selama bottleneck.

Solusi untuk masalah tersebut

Terdapat banyak kemungkinan bottleneck, tetapi dua masalah umum dan solusinya adalah sebagai berikut:

• Makin besar hierarki UI Anda, makin banyak waktu yang dibutuhkan aplikasi untuk menginisialisasinya. Pertimbangkan langkah-langkah berikut saat mengatasi masalah ini:
  • Meratakan hierarki UI dengan mengurangi composable yang berlebihan atau bertingkat.
  • Hindari komposisi dan rekomposisi yang tidak perlu selama peluncuran.
  • Menunda komposisi UI yang tidak penting.
• Melakukan semua inisialisasi resource di thread utama juga dapat memperlambat startup. Anda dapat mengatasi masalah ini seperti berikut:
  • Memindahkan semua inisialisasi resource sehingga aplikasi tersebut dapat menjalankannya dengan lambat di thread yang berbeda.
  • Muat dan tampilkan UI Anda dengan data placeholder terlebih dahulu, lalu perbarui properti visual yang bergantung pada bitmap dan resource lainnya.

Untuk mengetahui informasi selengkapnya tentang rekomposisi, lihat Rekomposisi dan Mendapatkan jumlah rekomposisi.

Layar pembuka kustom

Anda mungkin melihat waktu ekstra yang ditambahkan selama startup jika sebelumnya telah menggunakan salah satu metode berikut untuk menerapkan layar pembuka kustom di Android 11 (level API 30) atau yang lebih rendah:

• Menggunakan atribut tema windowDisablePreview untuk menonaktifkan layar kosong awal yang digambar oleh sistem selama peluncuran.
• Menggunakan Activity khusus.

Mulai Android 12, Anda harus bermigrasi ke API SplashScreen. Dengan API ini, waktu startup dapat menjadi lebih cepat, dan Anda dapat menyesuaikan layar pembuka dengan cara berikut:

• Mengatur tema untuk mengubah tampilan layar pembuka.
• Mengontrol durasi layar pembuka akan ditampilkan dengan windowSplashScreenAnimationDuration.
• Menyesuaikan animasi layar pembuka, dan menangani animasi dengan baik untuk menutup layar pembuka.

Selain itu, library compat dapat mem-backport SplashScreen API untuk mengaktifkan kompatibilitas mundur dan membuat tampilan serta nuansa yang konsisten untuk tampilan layar pembuka di semua versi Android.

Lihat Panduan migrasi layar pembuka untuk mengetahui detailnya.