Waktu memulai aplikasi

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:

  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 di layar 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 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, masing-masing).

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

Gambar 5. Filter dinonaktifkan dan 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.

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, seperti list.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:

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.