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

  • Pengujian
  • Pengembangan
  • 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, rating, dan jumlah penginstal persisten. 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 terhadap aplikasi serupa atau aplikasi pilihan Anda. Aplikasi dengan metrik yang lebih tinggi memiliki kemungkinan promosi yang lebih baik, sehingga menaikkan peringkatnya pada penelusuran Google Play Store. Aplikasi tersebut kemungkinan juga akan lebih memenuhi syarat untuk ditambahkan ke koleksi Baru & Di-update dan Pilihan Editor di Google Play, serta dinominasikan dalam Google Play Award.

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 disebabkan oleh pengecualian yang tidak tertangani, kehabisan resource, pernyataan yang gagal, atau keadaan tak 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 md: Persentase pengguna yang dalam satu harinya mengalami lebih dari 1 dalam 1000 frame yang waktu rendernya melebihi 700 md. Seperti 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 di mata 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 tidak dapat menghemat baterai.
  • Baterai | Bangun: Persentase pengguna yang mengalami lebih dari 60 peristiwa bangun per jam sejak daya perangkat terisi penuh. Peristiwa bangun yang sering terjadi akibat alarm yang melakukan operasi berbasis waktu di luar masa aktif aplikasi akan menghalangi perangkat yang sedang tidak ada aktivitas untuk beralih ke mode tidur.
  • Waktu mulai: Persentase sesi manakala 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 manakala 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 kelas atas yang memiliki fitur lengkap, pikirkan bagaimana aplikasi akan berjalan di perangkat kelas bawah 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 jenis perangkat tertentu. Bergantung pada seberapa parah 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 menyebabkan 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 rendering lambat: Gunakan FrameMetrics untuk mengukur waktu render frame per interaksi secara mendetail bagi perangkat dalam 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: Jelaskan kepada 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 untuk aplikasi Anda.
  • 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 build dan rilis aplikasi yang lebih efisien, yang menawarkan pengurangan ukuran aplikasi tanpa pemfaktoran ulang kode.

Contoh