Waktu startup aplikasi

Pengguna mengharapkan aplikasi responsif dan cepat untuk dimuat. 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 sepenuhnya digambar (TTFD). TTID adalah waktu yang dibutuhkan untuk menampilkan frame pertama, dan TTFD adalah waktu yang dibutuhkan 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.

Guna mendapatkan nilai yang akurat untuk TTFD, beri sinyal saat aplikasi mencapai status digambar sepenuhnya untuk membantu memastikan pengukuran waktu yang akurat. Untuk mempelajari cara melakukannya, lihat Meningkatkan akurasi pengaturan waktu startup.

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. Meng-inflate tampilan.
5. Mengatur tata letak layar.
6. Melakukan penggambaran awal.

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.

Gambar 1 menunjukkan bagaimana sistem dan proses aplikasi saling berbagi tugas satu sama lain.

Gambar 1. Representasi visual bagian-bagian penting dari peluncuran aplikasi secara cold.

Masalah performa dapat muncul selama pembuatan aplikasi dan pembuatan aktivitas.

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 utama 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 karena metode tersebut menjalankan tugas dengan overhead tertinggi: memuat dan meng-inflate tampilan, serta melakukan inisialisasi objek yang perlu dijalankan oleh aktivitas.

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 Anda ke latar depan. Jika semua aktivitas aplikasi Anda masih tersimpan di memori, aplikasi tersebut dapat menghindari pengulangan inisialisasi objek, inflate tata letak, 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.

Gambar 2. Diagram dengan berbagai status startup dan setiap prosesnya, setiap status dimulai dari frame pertama yang digambar.

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.

   

   Gambar 3.Slice metrik turunan Android App Startups di Perfetto.

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 bawah 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).

   

   Gambar 4.Slice metrik turunan Android App Startups di samping thread utama aplikasi.

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

Menggunakan metrik untuk mendeteksi dan mendiagnosis masalah

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 informasi tentang cara Google Play mengumpulkan data Android vitals, lihat dokumentasi Konsol Play.

Waktu hingga tampilan awal

Metrik waktu hingga tampilan awal (TTID) mengukur waktu yang diperlukan aplikasi untuk membuat frame pertamanya, termasuk inisialisasi proses selama cold start, pembuatan aktivitas selama cold start atau warm start, dan menampilkan frame pertama.

Cara mengambil TTID

Logcat menyertakan baris output yang berisi nilai bernama Displayed. Nilai ini mewakili jumlah waktu yang berlalu antara meluncurkan proses dan menyelesaikan penggambaran aktivitas terkait di layar. Waktu yang berlalu mencakup urutan peristiwa berikut:

• Meluncurkan proses.
• Menginisialisasi objek.
• Membuat dan menginisialisasi aktivitas.
• Meng-inflate tata letak.
• Menggambar aplikasi untuk pertama kalinya.

Baris log yang dilaporkan terlihat mirip dengan contoh berikut:

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

Jika Anda melacak output logcat dari command line atau dalam terminal, Anda dapat menemukan waktu yang berlalu dengan mudah. Untuk menemukan waktu yang berlalu di Android Studio, nonaktifkan filter dalam tampilan logcat Anda. Filter perlu dinonaktifkan karena server sistem, bukan aplikasi itu sendiri, yang menyalurkan log ini.

Setelah selesai membuat setelan yang benar, Anda dapat menelusuri periode yang tepat untuk melihat waktunya. Gambar 3 menunjukkan cara menonaktifkan filter dengan memilih "No filters" dari menu drop-down folier, dan di baris kedua output dari bagian bawah, contoh output logcat dari waktu Displayed.

Gambar 5. Menonaktifkan filter dan menemukan nilai Displayed di logcat.

Metrik Displayed dalam output logcat tidak selalu merekam jumlah waktu sampai semua resource dimuat dan ditampilkan. Metrik ini tidak menyertakan resource yang tidak dirujuk di file tata letak atau file 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.

Terkadang baris Displayed dalam output logcat berisi kolom tambahan untuk waktu total. Contoh:

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

Dalam hal ini, pengukuran pertama kali hanya dilakukan untuk aktivitas yang pertama kali digambar. 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 hanya ditampilkan ketika ada perbedaan antara aktivitas tunggal dan waktu startup total.

Anda juga dapat mengukur TTID dengan menjalankan aplikasi menggunakan perintah ADB Shell Activity Manager. 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

Metrik waktu hingga tampilan penuh (TTFD) mengukur waktu yang dibutuhkan oleh aplikasi untuk menghasilkan frame pertamanya dengan konten lengkap, termasuk konten yang dimuat secara asinkron setelah frame pertama. Umumnya, ini adalah konten daftar utama yang dimuat dari jaringan, seperti yang dilaporkan oleh aplikasi.

Cara mengambil TTFD

Anda dapat menggunakan metode reportFullyDrawn() untuk mengukur waktu yang telah berlalu antara peluncuran aplikasi dan tampilan lengkap semua resource dan hierarki tampilan. Hal ini dapat sangat berguna jika suatu aplikasi menjalankan pemuatan lambat. Dalam pemuatan lambat, aplikasi tidak memblokir penggambaran awal jendela, tetapi memuat resource dan memperbarui hierarki tampilannya secara asinkron.

Karena pemuatan lambat, jika tampilan awal aplikasi tidak menyertakan semua resource, Anda dapat mempertimbangkan pemuatan dan tampilan lengkap semua resource dan tampilan sebagai metrik terpisah. Misalnya, UI Anda mungkin dimuat sepenuhnya dengan beberapa teks yang digambar, tetapi mungkin belum menampilkan gambar yang harus diambil aplikasi dari jaringan.

Meningkatkan akurasi pengaturan waktu startup menjelaskan cara menggunakan FullyDrawnReporter untuk menunda panggilan reportFullyDrawn hingga setelah aplikasi Anda menjadi interaktif bagi pengguna.

Saat Anda menggunakan API ini, nilai yang ditampilkan logcat adalah waktu yang telah berlalu dari pembuatan objek aplikasi sampai saat reportFullyDrawn() dipanggil. Berikut adalah contoh dari output logcat:

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

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

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

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. 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:

• Meng-inflate tata letak yang besar atau kompleks.
• Memblokir menggambar layar pada disk, atau I/O jaringan.
• Memuat dan mendekode bitmap.
• Membuat raster objek VectorDrawable.
• Inisialisasi subsistem lain dari aktivitas.

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 tampilan Anda, makin banyak waktu yang dibutuhkan aplikasi untuk meng-inflate-nya. Dua langkah yang dapat Anda lakukan untuk mengatasi masalah ini adalah sebagai berikut:
  • Meratakan hierarki tampilan dengan mengurangi tata letak yang berlebihan atau bertingkat.
  • Jangan meng-inflate bagian UI yang tidak perlu terlihat selama peluncuran. Sebagai gantinya, gunakan objek ViewStub sebagai placeholder untuk sub-hierarki yang dapat di-inflate aplikasi pada waktu yang lebih tepat.
• 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.
  • Mengizinkan aplikasi memuat dan menampilkan tampilan Anda, lalu mengupdate properti visual yang bergantung pada bitmap dan resource lainnya.

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 SplashScreen API. 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.