Penggunaan memori (RSS anonim + swap)

Penggunaan memori (RSS anonim + swap) adalah metrik di Android vitals yang mencerminkan penggunaan memori aplikasi Anda.

Memori anonim adalah memori yang tidak didukung oleh file di penyimpanan, seperti alokasi heap dan memori yang dialokasikan mmap. Hal ini mencakup alokasi memori dinamis aplikasi Anda, termasuk heap Java atau Kotlin, alokasi heap native yang tidak dikelola (tempat data piksel Bitmap berada di Android 8.0 (level API 26) dan yang lebih tinggi), serta stack eksekusi thread. Meskipun OS dapat melepaskan memori yang didukung file saat tertekan, OS tidak dapat melepaskan memori anonim.

Resident Set Size (RSS) adalah jumlah total halaman memori (bersama dan bukan-bersama) yang digunakan oleh proses yang disimpan dalam RAM fisik. Halaman dianggap "dibagikan" jika diakses oleh lebih dari satu proses (seperti aplikasi yang mengakses library yang sama).

Untuk memori anonim, sistem dapat menulis halaman ke ruang swap (atau zRAM di Android) saat memori tertekan. Sistem dapat membaca kembali halaman ini dari swap jika diperlukan.

Secara keseluruhan, penggunaan memori (RSS anonim + swap) adalah ukuran jumlah total halaman memori aplikasi Anda yang tidak didukung oleh file di penyimpanan, termasuk memori yang juga dipertahankan oleh sistem dalam swap. Pelacakan RSS + swap anonim memastikan Anda melihat jejak memori aplikasi yang sebenarnya dan tidak dapat dikeluarkan.

Jika penggunaan memori aplikasi Anda tinggi, selidiki lebih lanjut dan perbaiki masalahnya menggunakan panduan di halaman ini.

Mengidentifikasi penggunaan memori yang tinggi

Android vitals

Android vitals membagikan penggunaan memori aplikasi Anda yang dikelompokkan berdasarkan status proses berikut:

  • Latar depan: Proses aplikasi terlihat. P99 yang tinggi di sini sering kali memengaruhi performa yang dirasakan pengguna (jank atau error OOM) dan sangat dipengaruhi oleh komponen atau aktivitas UI yang tidak dikeluarkan.
  • Layanan Latar Depan: Aplikasi menjalankan layanan latar depan. Karena layanan ini dirancang untuk tugas yang berjalan lama, layanan ini merupakan kandidat utama untuk kebocoran siklus proses kumulatif yang secara agresif meningkatkan ekor P99 dari waktu ke waktu.
  • Latar belakang: Aplikasi menjalankan layanan latar belakang, atau baru-baru ini berada di latar belakang, tetapi belum di-cache. Di sinilah kebocoran pemrosesan latar belakang terjadi.
  • Di-cache: Aplikasi berada dalam status di-cache. Status ini sangat sensitif terhadap tekanan memori sistem seperti LMK. Karena OS dapat mengeluarkan status proses ini kapan saja, status ini hanya disediakan untuk tujuan debug.

Untuk memahami bagaimana status proses ini berkorelasi dengan callback onTrimMemory, lihat panduan tentang melepaskan memori sebagai respons terhadap peristiwa.

Android vitals juga mengelompokkan penggunaan memori aplikasi Anda berdasarkan bucket RAM. Metrik penggunaan memori ditampilkan sebagai linimasa nilai persentil harian, bersama dengan nilai harian terbaru untuk persentil ke-50 dan ke-90.

Setelah Anda mengidentifikasi dasar pengukuran memori, ikuti panduan untuk mendiagnosis dan meningkatkan penggunaan memori yang berlebihan.

Mengidentifikasi kebocoran memori menggunakan kemiringan ekor

Untuk membantu mengidentifikasi kebocoran memori, cari perbedaan antara pengguna umum (P50) dan pengguna akhir (P90) di Android vitals. Meskipun pembengkakan aset umum meningkatkan memori secara seragam di semua persentil, kebocoran memori akan bertambah seiring waktu, sehingga sangat memiringkan data ujung belakang.

Anda harus membandingkan metrik P90 dan P99 dengan dasar P50 menurut nama proses. Jika rasio P90 terhadap P50 Anda melebihi 3,5x, hal ini menunjukkan kemungkinan kebocoran memori selama sesi yang diperpanjang. Untuk kasus penggunaan tertentu, rasio yang tinggi tidak selalu menunjukkan kebocoran, tetapi Anda harus mengevaluasi alur kerja tertentu untuk menentukan apakah penggunaan memori yang tinggi adalah perilaku yang diharapkan.

Resource

Mendiagnosis penggunaan memori yang berlebihan secara lokal

Untuk mulai mendiagnosis sumber penggunaan memori yang berlebihan, Anda dapat merekam heap dump dengan Rekam heap dump di setelan developer, Android Studio, atau Perfetto. Sebaiknya mulai dengan merekam dump heap secara lokal setelah menguji perjalanan pengguna inti aplikasi Anda.

Sebaiknya uji perjalanan pengguna berikut:

  • WebView dan Sesi Browser Dalam Aplikasi
  • Scrolling tanpa batas dengan banyak media
  • Alur pembuatan dan pengeditan aset

Untuk menyelidiki potensi kebocoran memori, pertama-tama identifikasi proses yang paling banyak menggunakan memori menggunakan tabel Nama proses di dasbor penggunaan memori Android vitals. Selanjutnya, jalankan perjalanan pengguna yang sesuai secara lokal dan kumpulkan dump heap di berbagai status proses (terlihat, layanan latar depan, dan di-cache) untuk memverifikasi apakah aplikasi melepaskan memori setelah dipindahkan ke latar belakang.

Jika Anda men-debug masalah memori menggunakan Android Studio Profiler, Anda juga dapat menggunakan integrasi LeakCanary untuk menyederhanakan deteksi kebocoran dan deteksi bitmap duplikat guna mengoptimalkan penggunaan gambar Anda.

Setelah mengumpulkan heap dump, sebaiknya gunakan Keterampilan AI Perfetto untuk menganalisis heap dump dan mengidentifikasi potensi sumber penggunaan memori yang tinggi.

Berikut contoh respons yang dapat diberikan oleh keterampilan AI:

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

Referensi tambahan untuk menafsirkan dump heap

Referensi berikut memberikan informasi lebih lanjut tentang cara menafsirkan heap dump dan men-debug penggunaan memori:

Meningkatkan penggunaan memori

Lihat bagian ini untuk mempelajari lebih lanjut cara meningkatkan penggunaan memori aplikasi Anda:

Untuk panduan mendetail tentang cara memperbaiki masalah memori, lihat panduan Mengelola memori aplikasi Anda.

Sebelumnya
Low memory killer (LMK)
Berikutnya
Penguncian Layar Saat Aktif Sebagian Bermasalah