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 (API level 26) dan yang lebih tinggi), serta stack eksekusi thread. Meskipun OS dapat menghapus memori yang didukung file saat tertekan, OS tidak dapat menghapus 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 "bersama" 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 apa pun yang juga dipertahankan oleh sistem dalam swap. Melacak RSS anonim + swap memastikan Anda melihat jejak memori aplikasi yang sebenarnya dan tidak dapat dihapus.
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 dipecah 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 didorong oleh mempertahankan komponen atau aktivitas UI yang tidak lagi diperlukan.
- Layanan yang dirasakan pengguna: Proses aplikasi berjalan dalam status yang dapat dirasakan. Hal ini mencakup layanan latar depan, tugas yang dipercepat, dan tugas transfer data yang dimulai pengguna. Hal ini juga dapat diperluas ke layanan yang terikat sistem atau layanan yang terikat oleh aplikasi lain. Karena layanan ini dirancang untuk tugas yang berjalan lama, mempertahankan memori karena kebocoran atau gagal merilis resource dapat 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 dan resource yang tidak dirilis dapat bertambah. Karena status proses ini kurang penting daripada proses latar depan atau yang dapat dirasakan, coba hindari mempertahankan memori dalam jumlah besar dalam status ini.
- Di-cache: Aplikasi berada dalam status di-cache. Status ini sangat sensitif terhadap tekanan memori sistem seperti LMK. Karena OS dapat menghapus status proses ini kapan saja, status ini hanya disediakan untuk tujuan debug.
Untuk memahami bagaimana status proses ini berkorelasi dengan onTrimMemory callback,
lihat panduan tentang merilis memori sebagai respons terhadap peristiwa.
Android vitals juga memecah 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 mengidentifikasi baseline 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 bloat aset umum meningkatkan memori secara seragam di semua persentil, kebocoran memori bertambah dari waktu ke waktu, sehingga sangat memiringkan data akhir.
Anda harus membandingkan metrik P90 dan P99 dengan baseline P50 berdasarkan nama proses. Jika rasio P90 ke P50 Anda melebihi 3,5x, hal ini menunjukkan kemungkinan kebocoran memori selama sesi yang diperpanjang. Untuk kasus penggunaan tertentu, rasio yang ditingkatkan tidak selalu menunjukkan kebocoran, tetapi Anda harus mengevaluasi alur kerja tertentu untuk menentukan apakah penggunaan memori yang ditingkatkan 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 heap dump secara lokal setelah menguji perjalanan pengguna inti aplikasi Anda.
Sebaiknya uji perjalanan pengguna berikut:
- Sesi Browser Dalam Aplikasi dan WebView
- Scrolling tanpa batas yang menggunakan 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 heap dump di berbagai status proses (terlihat, layanan latar depan, dan di-cache) untuk memverifikasi apakah aplikasi merilis memori setelah berada di latar belakang.
Jika Anda melakukan debug masalah memori menggunakan Android Studio Profiler, Anda juga dapat menggunakan integrasi LeakCanary untuk menyederhanakan deteksi kebocoran dan bitmap duplikat guna mengoptimalkan penggunaan gambar.
Setelah mengumpulkan heap dump, sebaiknya gunakan Perfetto AI Skills untuk menganalisis heap dump dan mengidentifikasi potensi sumber penggunaan memori yang tinggi.
Berikut contoh respons yang dapat diberikan oleh AI skills:
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 heap dump
Referensi berikut memberikan informasi selengkapnya tentang menafsirkan heap dump dan melakukan debug penggunaan memori:
- Analisis manual: Gunakan panduan Perfetto Heap Dump Explorer untuk mempelajari cara menavigasi dan menafsirkan visualisasi heap dump di UI Perfetto.
- Alokasi Java/Kotlin: Baca Memvisualisasikan heap dump ART pertama Anda untuk mengetahui panduan langkah demi langkah dalam menganalisis heap dump Android Runtime (ART).
- Alokasi native: Lihat dokumentasi Perfetto Native Profiling untuk mempelajari cara mengumpulkan dan menganalisis profil memori native (C/C++).
- Pemeriksaan CLI: Gunakan adb dumpsys meminfo untuk mendapatkan perincian cepat penggunaan memori aplikasi Anda di perangkat.
- Analisis yang dibantu AI: Manfaatkan Perfetto AI Skills untuk menjalankan analisis yang didukung LLM guna membantu mendeteksi kebocoran memori dan alokasi yang berlebihan dalam rekaman aktivitas Anda.
- Analisis berbasis SQL: Gunakan Perfetto SQL dan Trace Analysis Skills untuk menjalankan kueri terstruktur dan skrip khusus guna menganalisis data rekaman aktivitas yang kompleks.
Meningkatkan penggunaan memori
Lihat bagian ini untuk mempelajari lebih lanjut cara meningkatkan penggunaan memori aplikasi Anda:
- Mengurangi jejak kode dan resource aplikasi
- Memantau memori yang tersedia dan penggunaan memori
- Menggunakan konstruksi kode yang lebih hemat memori
Untuk panduan mendetail tentang cara memperbaiki masalah memori, lihat panduan Mengelola memori aplikasi.