Bergabunglah bersama kami di ⁠#Android11: The Beta Launch Show pada tanggal 3 Juni!

Menggunakan Android vitals untuk menyempurnakan performa, stabilitas, dan ukuran aplikasi

  • Uji
  • Mengembangkan aplikasi
  • Analisis

Performa dan stabilitas berkaitan langsung dengan rating yang positif di Google Play. Dengan mengatasi masalah dan mencegah perilaku buruk pada aplikasi, Anda dapat meningkatkan pengalaman pengguna, mendapatkan rating yang lebih tinggi, dan menaikkan jumlah installer yang belum meng-uninstal. Selain itu, mengurangi ukuran aplikasi juga dapat menaikkan tingkat penginstalan dan mengurangi tingkat uninstal.

Mengapa cara ini berhasil

Android vitals menampilkan metrik performa aplikasi terkait stabilitas, daya, jank, waktu mulai, dan penolakan izin. Dengan memantau metrik ini, Anda dapat mengidentifikasi dan memperbaiki perilaku buruk aplikasi yang berpengaruh langsung pada pengalaman pengguna. Anda juga akan mengetahui jika ada perubahan mendadak pada data vital inti yang menunjukkan anomali yang harus diselidiki, serta tolok ukur untuk membantu membandingkan performa aplikasi dengan aplikasi yang serupa atau aplikasi pilihan Anda. Aplikasi dengan metrik yang lebih tinggi memiliki kemungkinan promosi yang lebih baik, yang akan menaikkan peringkatnya pada penelusuran Google Play Store. Aplikasi tersebut kemungkinan juga akan lebih memenuhi syarat untuk ditambahkan ke koleksi Baru & Diperbarui dan Pilihan Editor di Google Play, serta dinominasikan dalam Google Play Awards.

Metrik utama

  • Stabilitas | Rasio ANR: Persentase pengguna yang mengalami setidaknya satu peristiwa aplikasi tidak merespons (ANR) dalam satu sesi harian. ANR biasanya disebabkan oleh deadlock atau kelambatan dalam UI thread dan proses latar belakang (penerima siaran).
  • Stabilitas | Rasio error: Persentase pengguna yang mengalami setidaknya satu peristiwa error dalam satu sesi harian. Error sering kali disebabkan oleh pengecualian yang tidak tertangani, kehabisan resource, pernyataan yang gagal, atau keadaan tidak terduga lainnya.
  • Waktu render | 16 md (60 fps): Persentase sesi harian ketika pengguna mengalami lebih dari 50% frame yang waktu rendernya melebihi 16 md. Interaksi pengguna dengan aplikasi Anda harus berjalan pada 60 frame per detik tanpa ada frame yang menurun atau tertunda.
  • Waktu render | 700 milidetik: Persentase pengguna yang dalam satu harinya mengalami lebih dari 1 dalam 1000 frame yang waktu rendernya melebihi 700 milidetik. Seperti yang disebutkan di atas, waktu render yang lama menurunkan pengalaman pengguna karena menyebabkan aplikasi terasa kurang lancar. Frame yang memerlukan waktu render 700 md atau lebih kemungkinan akan menyebabkan aplikasi tampak berhenti merespons kepada pengguna.
  • Baterai | Penguncian layar saat aktif parsial: Persentase pengguna yang dalam satu harinya mengalami setidaknya satu penguncian layar saat aktif selama lebih dari satu jam. Jika penguncian layar saat aktif parsial berhenti berfungsi, perangkat yang sedang tidak ada aktivitas menjadi tidak dapat beralih ke mode tidur dan menghemat baterai.
  • Baterai | Bangun: Persentase pengguna yang mengalami lebih dari 60 peristiwa bangun per jam sejak perangkat terisi penuh. Peristiwa bangun yang sering terjadi akibat alarm yang melakukan operasi berbasis waktu di luar masa aktif aplikasi menghalangi perangkat yang sedang tidak ada aktivitas untuk beralih ke mode tidur.
  • Waktu mulai: Persentase sesi yang pada saat itu pengguna mengalami waktu mulai cold, warm, atau hot yang lambat. Proses mulai yang lambat dapat disebabkan oleh berbagai masalah, tetapi biasanya menunjukkan eksekusi beban kerja yang berat atau logika yang kompleks saat menginisialisasi aplikasi.
  • Penolakan izin: Persentase sesi izin harian yang pada saat itu pengguna menolak izin atau memilih Jangan tanya lagi. Penolakan izin dapat menunjukkan bahwa pengguna tidak mengetahui alasan izin diminta atau menganggap permintaan tersebut tidak perlu atau tidak masuk akal.
  • Ukuran Aplikasi: Lacak download dan ukuran aplikasi di perangkat lalu bandingkan metrik ini dengan aplikasi yang sejenis. Selain itu, lihat metrik pengguna aktif dan metrik uninstal untuk perangkat yang memiliki penyimpanan rendah. Dapatkan saran pengoptimalan terkait cara mengurangi ukuran aplikasi berdasarkan analisis rilis Anda.

Praktik terbaik

  • Pikirkan dan singkirkan perilaku buruk aplikasi: Selama proses pengembangan, pikirkan bagaimana aplikasi Anda akan berperilaku di berbagai lingkungan. Misalnya, jika Anda menguji aplikasi di perangkat canggih yang memiliki fitur lengkap, pikirkan bagaimana aplikasi akan berjalan di perangkat kelas rendah dengan keterbatasan daya, memori, bandwidth, dan kemampuan CPU/GPU. Gunakan laporan pra-peluncuran untuk menguji aplikasi Anda di perangkat yang lebih beragam sebelum setiap rilis.
  • Periksa Android vitals setelah merilis versi aplikasi baru: Setelah Anda memublikasikan aplikasi, Android vitals akan menyediakan metrik tentang performa aplikasi Anda di perangkat produksi aktual. Hal ini memungkinkan Anda mengidentifikasi masalah dan perilaku buruk yang memengaruhi pengguna di perangkat dan versi Android tertentu.
  • Identifikasi perangkat yang bermasalah: Aplikasi Anda mungkin hanya menunjukkan perilaku buruk pada perangkat atau kumpulan perangkat tertentu. Bergantung pada keparahan dampaknya terhadap pengalaman pengguna serta jumlah perangkat dan pengguna yang terpengaruh, Anda dapat memilih untuk memperbarui Penargetan Perangkat aplikasi agar mengecualikan perangkat tersebut hingga perbaikan tersedia.
  • Identifikasi versi Android yang bermasalah: Aplikasi Anda mungkin hanya menunjukkan perilaku buruk pada versi Android tertentu. Untuk versi lama Android yang merepresentasikan sejumlah kecil pengguna, update aplikasi untuk menghilangkan perilaku buruk, atau update atribut android:minSdkVersion dari elemen <uses-sdk> dalam Manifes aplikasi ke API level yang kompatibel sehingga aplikasi tidak menunjukkan perilaku buruk. Untuk versi Android yang lebih baru, selalu update aplikasi Anda untuk memperbaiki perilaku buruk yang ada, bukan menetapkan atribut android:maxSdkVersion dari elemen <uses-sdk> untuk mengecualikannya.
  • Gunakan alat pelaporan error untuk mengidentifikasi serta melacak error dan ANR: Gunakan alat pelaporan error, seperti Firebase Crash Reporting atau Crashlytics, serta proses debug Android Studio untuk mengidentifikasi dan melacak sebanyak mungkin skenario yang mengarah pada error dan ANR.
  • Gunakan API JobScheduling untuk menghindari peristiwa bangun dan penguncian layar saat aktif: Gunakan API JobScheduling seperti JobScheduler untuk menjadwalkan proses dan tugas latar belakang secara efektif. Dengan demikian, platform dapat mengelola status tidak ada aktivitasnya dengan lebih baik untuk menghemat masa pakai baterai.
  • Gunakan API FrameMetrics untuk mengidentifikasi waktu render yang lambat: Gunakan FrameMetrics untuk mengukur waktu render frame per interaksi secara mendetail bagi perangkat produksi. Hal ini memungkinkan Anda mengidentifikasi interaksi atau peristiwa spesifik yang menyebabkan jank pada perangkat produksi, bukan pada perangkat pengujian yang terhubung melalui USB.
  • Ikuti praktik terbaik untuk permintaan izin: Beri tahu pengguna sebelum meminta izin dan pastikan mereka akan langsung mendapatkan manfaat dari izin tersebut. Bantu pengguna membatalkan penolakan izin, serta pastikan mereka telah mengaktifkan setelan yang tepat agar aplikasi Anda dapat berfungsi.
  • Gunakan laporan pra-peluncuran untuk menguji aplikasi Anda di perangkat aktual, lalu identifikasi dan perbaiki masalah sebelum Anda memublikasikan update.
  • Mulai gunakan Android App Bundle guna memanfaatkan cara yang lebih efisien untuk mem-build dan merilis aplikasi, yang menawarkan pengurangan ukuran aplikasi tanpa pemfaktoran ulang kode.

Contoh