Pengguna berharap 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 sepenuhnya digambar (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:
- Memuat dan meluncurkan aplikasi.
- Menampilkan jendela awal kosong untuk aplikasi, segera setelah peluncuran.
- Membuat proses aplikasi.
Segera setelah sistem membuat proses aplikasi, proses aplikasi bertanggung jawab untuk tahap selanjutnya:
- Membuat objek aplikasi.
- Meluncurkan thread utama.
- Membuat aktivitas utama.
- Meng-inflate tampilan.
- Mengatur tata letak layar.
- 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.
![](https://developer.android.google.cn/static/topic/performance/images/cold-launch.png?authuser=19&hl=id)
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:
- Melakukan inisialisasi nilai.
- Memanggil konstruktor.
- 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 di layar yang sama dengan skenario cold start. Proses sistem menampilkan layar kosong hingga aplikasi selesai merender aktivitas.
![](https://developer.android.google.cn/static/topic/performance/vitals/images/startup-modes-r1.png?authuser=19&hl=id)
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:
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. 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.
Sematkan baris Android App Startups dengan mengklik ikon pin, yang akan terlihat saat Anda mengarahkan kursor ke baris.
Scroll ke baris yang berisi aplikasi yang dimaksud, lalu klik sel pertama untuk meluaskan baris.
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, masing-masing).
Gambar 4.Slice metrik turunan Android App Startups di samping thread utama aplikasi. 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 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
TID aplikasi yang rendah akan membantu meningkatkan pengalaman pengguna dengan memungkinkan pengguna melihat
aplikasi Anda diluncurkan dengan cepat. TTID dilaporkan secara otomatis untuk setiap aplikasi oleh Framework
Android. Saat mengoptimalkan startup aplikasi, sebaiknya implementasikan
reportFullyDrawn
untuk mendapatkan informasi hingga TTFD.
TTID diukur sebagai nilai waktu yang mewakili total waktu berlalu yang mencakup urutan peristiwa berikut:
- Meluncurkan proses.
- Melakukan inisialisasi objek.
- Membuat dan menginisialisasi aktivitas.
- Meng-inflate tata letak.
- Menggambar aplikasi untuk pertama kalinya.
Ambil TTID
Untuk menemukan TTID, telusuri baris output
yang berisi nilai bernama Displayed
di Alat command line Logcat. Nilai ini adalah TTID dan terlihat mirip
dengan contoh berikut, dengan TTID adalah 3s534 md:
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms
Untuk menemukan TTID di Android Studio, nonaktifkan filter di tampilan Logcat dari
menu drop-down filter, lalu cari waktu Displayed
, seperti ditunjukkan dalam gambar 5.
Filter perlu dinonaktifkan karena server sistem, bukan aplikasi itu sendiri, yang menyalurkan log ini.
![](https://developer.android.google.cn/static/topic/performance/images/displayed-logcat.png?authuser=19&hl=id)
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.
Sebaiknya gunakan Logcat di Android Studio, tetapi Jika 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 diperlukan aplikasi untuk menjadi interaktif bagi pengguna. Ini 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 menyertakan TTID serta waktu yang diperlukan agar aplikasi dapat digunakan. Mempertahankan TTFD aplikasi tetap rendah akan membantu meningkatkan pengalaman pengguna karena memungkinkan pengguna berinteraksi dengan aplikasi secara cepat.
Sistem menentukan TTID saat Choreographer
memanggil metode onDraw()
aktivitas, dan saat sistem mengetahuinya, sistem akan memanggilnya untuk pertama kalinya.
Namun, sistem tidak tahu kapan harus menentukan TTFD karena setiap aplikasi
berperilaku berbeda. Untuk menentukan TTFD, aplikasi harus memberikan sinyal ke sistem
saat mencapai status digambar sepenuhnya.
Ambil TTFD
Untuk menemukan TTFD, beri sinyal status yang digambar sepenuhnya dengan memanggil
metode reportFullyDrawn()
dari ComponentActivity
. Metode
reportFullyDrawn
melaporkan saat aplikasi telah digambar sepenuhnya dan dalam status
dapat digunakan. TTFD adalah waktu yang berlalu sejak 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 pertama kali digambar dan ditampilkan sebagaimana diukur oleh sistem, karena nantinya
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 adalah 1s54 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 Anda lebih lambat dari yang diinginkan, Anda dapat mencoba mengidentifikasi bottleneck dalam proses startup.
Anda dapat menggunakan reportFullyDrawn()
untuk menandakan status yang digambar sepenuhnya dalam kasus dasar
saat Anda mengetahui bahwa status yang digambar sepenuhnya telah tercapai. Namun, jika
thread latar belakang harus menyelesaikan pekerjaan latar belakang sebelum status yang digambar sepenuhnya
dicapai, Anda harus menunda reportFullyDrawn()
untuk pengukuran TTFD
yang lebih akurat. Untuk mempelajari cara menunda reportFullyDrawn()
, lihat bagian
berikut.
Meningkatkan akurasi pengaturan waktu startup
Jika aplikasi melakukan pemuatan lambat dan tampilan awal tidak menyertakan
semua resource, seperti saat aplikasi mengambil gambar dari jaringan, Anda
mungkin perlu menunda pemanggilan reportFullyDrawn
hingga aplikasi dapat
digunakan sehingga Anda dapat menyertakan populasi daftar sebagai bagian dari waktu
benchmark.
Misalnya, jika UI berisi daftar dinamis, seperti RecyclerView
atau daftar lambat, UI ini mungkin diisi oleh tugas latar belakang yang selesai setelah
daftar pertama kali digambar, sehingga setelah UI ditandai sebagai digambar sepenuhnya.
Dalam kasus tersebut, populasi daftar tidak disertakan dalam tolok ukur.
Untuk menyertakan pengisian daftar sebagai bagian dari waktu benchmark, dapatkan
FullyDrawnReporter
dengan menggunakan getFullyDrawnReporter()
, dan tambahkan
reporter ke dalamnya pada kode aplikasi Anda. Rilis reporter setelah tugas latar belakang
selesai mengisi daftar.
FullyDrawnReporter
tidak memanggil metode reportFullyDrawn()
hingga semua
reporter yang ditambahkan dirilis. Dengan menambahkan pelapor hingga proses latar belakang
selesai, pengaturan waktu juga menyertakan jumlah waktu yang diperlukan untuk mengisi
daftar dalam data waktu startup. Hal ini tidak mengubah perilaku aplikasi bagi
pengguna, tetapi memungkinkan data startup pengaturan waktu menyertakan waktu yang diperlukan untuk mengisi
daftar. reportFullyDrawn()
tidak dipanggil sampai semua tugas
selesai, terlepas dari urutannya.
Contoh berikut menunjukkan cara menjalankan beberapa tugas latar belakang secara serentak, dengan mendaftarkan pelapor masing-masing:
Kotlin
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 { lifecycleScope.launch(Dispatchers.IO) { fullyDrawnReporter.addReporter() // Perform the background operation. fullyDrawnReporter.removeReporter() } lifecycleScope.launch(Dispatchers.IO) { fullyDrawnReporter.addReporter() // Perform the background operation. fullyDrawnReporter.removeReporter() } } } } }
Java
public class MainActivity extends ComponentActivity { private FullyDrawnReporter fullyDrawnReporter; @Override protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); fullyDrawnReporter = getFullyDrawnReporter(); fullyDrawnReporter.addOnReportDrawnListener(() -> { // Trigger the UI update. return Unit.INSTANCE; }); new Thread(new Runnable() { @Override public void run() { fullyDrawnReporter.addReporter(); // Do the background work. fullyDrawnReporter.removeReporter(); } }).start(); new Thread(new Runnable() { @Override public void run() { fullyDrawnReporter.addReporter(); // Do the background work. fullyDrawnReporter.removeReporter(); } }).start(); } }
Jika aplikasi menggunakan Jetpack Compose, Anda dapat menggunakan API berikut untuk menunjukkan status sepenuhnya digambar:
ReportDrawn
: menunjukkan bahwa composable Anda langsung siap untuk interaksi.ReportDrawnWhen
: menggunakan predikat, sepertilist.count > 0
, untuk menunjukkan kapan composable Anda siap untuk berinteraksi.ReportDrawnAfter
: menggunakan metode penangguhan yang, setelah selesai, menunjukkan bahwa composable Anda siap untuk berinteraksi.
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.
- Meraster 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, dan kemudian 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.
Direkomendasikan untuk Anda
- Catatan: teks link ditampilkan saat JavaScript nonaktif
- Rendering lambat
- Mengambil metrik Macrobenchmark
- Membuat Profil Dasar Pengukuran{:#creating-profile-rules}