Merekam heap dump

Ambil heap dump untuk melihat objek mana dalam aplikasi Anda yang menggunakan memori pada saat pengambilan dan mengidentifikasi kebocoran memori, atau perilaku alokasi memori yang menyebabkan aplikasi tersendat, berhenti merespons, dan bahkan tidak bekerja. Sangat membantu untuk mengambil heap dump setelah sesi pengguna yang diperpanjang, saat heap dump dapat menampilkan objek yang masih ada dalam memori yang seharusnya tidak ada lagi di sana.

Halaman ini menjelaskan alat yang disediakan Android Studio untuk mengumpulkan dan menganalisis heap dump. Atau, Anda dapat memeriksa memori aplikasi dari command line dengan dumpsys dan juga melihat peristiwa pembersihan sampah memori (GC) di Logcat.

Alasan Anda harus membuat profil memori aplikasi

Android menyediakan lingkungan memori terkelola—saat Android menentukan bahwa aplikasi Anda tidak lagi menggunakan beberapa objek, pembersih sampah memori akan merilis memori yang tidak digunakan kembali ke heap. Cara Android menemukan memori yang tidak digunakan terus ditingkatkan, tetapi pada titik tertentu di semua versi Android, sistem harus menjeda kode Anda sebentar. Sering kali, jeda ini tidak terlihat. Namun, jika aplikasi Anda mengalokasikan memori lebih cepat daripada yang dapat dikumpulkan sistem, aplikasi Anda mungkin akan tertunda saat pembersih membebaskan cukup memori untuk memenuhi alokasi Anda. Penundaan ini dapat menyebabkan aplikasi Anda melewatkan frame dan menyebabkan kelambatan yang terlihat.

Meskipun tidak menunjukkan kelambatan, jika membocorkan memori, aplikasi dapat menahan memori tersebut bahkan saat berada di latar belakang. Perilaku ini dapat memperlambat performa memori sistem yang tersisa dengan memaksakan peristiwa pembersihan sampah memori yang tidak perlu. Pada akhirnya, sistem akan dipaksa untuk mematikan proses aplikasi Anda guna mengambil kembali memori tersebut. Kemudian, saat pengguna kembali ke aplikasi Anda, proses aplikasi harus dimulai ulang sepenuhnya.

Untuk mengetahui informasi tentang praktik pemrograman yang dapat mengurangi penggunaan memori aplikasi, baca [Mengelola memori aplikasi]memori.

Ringkasan heap dump

Untuk merekam heap dump, pilih tugas Analyze Memory Usage (Heap Dump) (gunakan Profiler: run 'app' as debuggable (complete data)) untuk merekam heap dump. Saat membuang heap, jumlah memori Java mungkin bertambah untuk sementara. Hal ini normal karena heap dump terjadi dalam proses yang sama dengan aplikasi Anda dan memerlukan beberapa memori untuk mengumpulkan data. Setelah mengambil heap dump, Anda akan melihat hal berikut:

Catatan: Jika perlu lebih akurat tentang kapan heap dump dibuat, Anda dapat membuat heap dump pada titik penting dalam kode aplikasi dengan memanggil dumpHprofData().

Tampilan Heap Dump di Android Studio Profiler.

Daftar kelas menampilkan info berikut:

• Allocations: Jumlah alokasi dalam heap.

• Native Size: Jumlah total memori native yang digunakan oleh jenis objek ini (dalam byte). Anda akan melihat memori di sini untuk beberapa objek yang dialokasikan di Java karena Android menggunakan memori native untuk beberapa class framework, seperti Bitmap.

  Catatan: Kolom Ukuran Native tidak tersedia untuk perangkat yang menjalankan versi OS yang lebih rendah dari Android 7.0.

• Shallow Size: Jumlah total memori Java yang digunakan oleh jenis objek ini (dalam byte).

• Retained Size: Ukuran total memori yang dipertahankan karena semua instance class ini (dalam byte).

Gunakan menu heap untuk memfilter ke heap tertentu:

• Heap aplikasi (default): Heap utama tempat aplikasi Anda mengalokasikan memori.
• Heap image: Image booting sistem, yang berisi class yang dimuat sebelumnya selama waktu booting. Alokasi di sini tidak pernah berpindah atau hilang.
• Heap zygote: Heap copy-on-write tempat proses aplikasi diambil dalam sistem Android.

Gunakan drop-down pengaturan untuk memilih cara mengatur alokasi:

• Atur berdasarkan class (default): Mengelompokkan semua alokasi berdasarkan nama class.
• Arrange by package: Mengelompokkan semua alokasi berdasarkan nama paket.

Gunakan drop-down kelas untuk memfilter ke grup kelas:

• Semua class (default): Menampilkan semua class, termasuk class dari library dan dependensi.
• Show activity/fragment leaks: Menampilkan class yang menyebabkan kebocoran memori.
• Show project classes: hanya menampilkan class yang ditentukan oleh project Anda.

Klik nama class untuk membuka panel Instance. Setiap instance yang tercantum mencakup hal berikut:

• Depth: Jumlah lompatan tersingkat dari GC root ke instance yang dipilih.
• Native Size: Ukuran instance ini dalam memori native. Kolom ini hanya terlihat untuk Android 7.0 dan yang lebih tinggi.
• Shallow Size: Ukuran instance ini dalam memori Java.
• Retained Size: Ukuran memori yang didominasi oleh instance ini (sesuai dengan pohon dominator).

Klik instance untuk menampilkan Instance Details, termasuk Fields dan References. Jenis kolom dan referensi umum adalah jenis terstruktur , array , dan jenis data primitif di Java. Klik kanan pada kolom atau referensi untuk membuka instance atau baris terkait dalam kode sumber.

• Kolom: Menampilkan semua kolom dalam instance ini.
• References: Menampilkan setiap referensi ke objek yang ditandai di tab Instance.

Tampilan Instances, Fields, dan References di jendela alat Heap Dump.

Mendeteksi bitmap duplikat

Anda juga dapat mendeteksi bitmap redundan dalam tampilan Heap Dump mulai dari Android Studio Narwhal 4.

Berikut cara memburunya:

1. Membuka tab Profiler di Android Studio
2. Klik Heap Dump (atau Analyze Memory Usage) dan klik rekam untuk mengambil snapshot status memori aplikasi Anda saat ini.
3. Pindai hasil analisis untuk menemukan segitiga peringatan berwarna kuning ⚠️, yang digunakan Android Studio untuk menandai bitmap duplikat yang disimpan beberapa kali.
   • Atau, buka header profiler, pilih Filter by:, lalu pilih setelan Duplicate Bitmaps.
4. Klik entri yang ditandai untuk membuka panel Bitmap Preview, sehingga Anda dapat melihat dengan tepat gambar mana yang merupakan pelanggar berulang.
5. Gunakan konfirmasi visual tersebut untuk melacak logika pemuatan yang redundan dalam kode Anda dan menerapkan strategi caching yang lebih baik.

Cari bitmap duplikat menggunakan segitiga peringatan kuning ⚠️.

Menemukan kebocoran memori

Untuk memfilter dengan cepat ke class yang mungkin terkait dengan kebocoran memori, buka drop-down class dan pilih Show activity/fragment leaks. Android Studio menampilkan class yang dianggapnya menunjukkan kebocoran memori untuk instance Activity dan Fragment di aplikasi Anda.

Catatan: Di aplikasi Compose yang menggunakan arsitektur satu aktivitas, Anda mungkin tidak memiliki kebocoran Fragment untuk difilter. Namun, mendeteksi kebocoran Activity sangat penting, karena kebocoran Activity host akan mempertahankan seluruh hierarki Compose dan semua hierarki status aktif dalam memori.

Untuk mencari kebocoran memori secara lebih manual, jelajahi daftar class dan instance untuk menemukan objek dengan Retained Size yang besar. Cari kebocoran memori yang disebabkan oleh salah satu hal berikut:

• Referensi yang berumur panjang ke Activity atau Context yang dapat membocorkan grafik komposisi Compose yang dihosting (seperti ComposeView dan sub-composable-nya).
• Membocorkan objek Status Jetpack Compose (MutableState), holder status, atau lambda yang menangkap Context.
• Lupa membersihkan pemroses atau observer di blok onDispose DisposableEffect.
• Class dalam non-statis, seperti Runnable, yang dapat menyimpan instance Activity.
• Cache yang menyimpan objek lebih lama dari yang diperlukan.

Saat Anda menemukan potensi kebocoran memori, gunakan tab Fields dan References di Instance Details untuk beralih ke instance atau baris kode sumber yang diinginkan.

Tips: Mulai Android Studio Quail 2, Android Studio Profiler menawarkan integrasi dengan LeakCanary sebagai tugas khusus. Dengan menggunakan LeakCanary, Anda dapat memindahkan analisis kebocoran memori dari perangkat pengujian ke mesin pengembangan, sehingga menghasilkan peningkatan performa yang signifikan. Untuk informasi selengkapnya, lihat LeakCanary di Profiler Android Studio.

Memicu kebocoran memori untuk pengujian

Untuk menganalisis penggunaan memori, Anda harus menguji kode aplikasi dan mencoba memaksa kebocoran memori. Salah satu cara untuk memicu kebocoran memori di aplikasi Anda adalah dengan membiarkannya berjalan beberapa saat sebelum memeriksa heap. Kebocoran mungkin merembes ke bagian atas alokasi dalam heap. Namun, makin kecil kebocoran, makin lama Anda perlu menjalankan aplikasi untuk melihatnya.

Anda juga dapat memicu kebocoran memori dengan salah satu cara berikut:

• Putar perangkat dari potret ke lanskap dan kembali lagi beberapa kali saat berada dalam status aktivitas yang berbeda. Memutar perangkat sering kali dapat menyebabkan aplikasi membocorkan Activity (dan akibatnya, hierarki UI Compose yang dihosting dan hierarki status terkait) jika aplikasi Anda menyimpan referensi ke Activity atau Context di dalam operasi asinkron atau holder status.
• Beralih antara aplikasi Anda dan aplikasi lain saat berada dalam status aktivitas yang berbeda. Misalnya, buka layar utama, lalu kembali ke aplikasi Anda.

Tips: Anda juga dapat melakukan pengujian UI menggunakan App Crawler atau UI Automator.

Mengekspor dan mengimpor rekaman heap dump

Anda dapat mengekspor dan mengimpor file heap dump dari tab Past Recordings di profiler. Android Studio menyimpan rekaman sebagai file .hprof.

Atau, untuk menggunakan penganalisis file .hprof yang berbeda seperti jhat, Anda perlu mengonversi file .hprof dari format Android ke format file .hprof Java SE. Untuk mengonversi format file, gunakan alat hprof-conv yang disediakan di direktori {android_sdk}/platform-tools/. Jalankan perintah hprof-conv dengan dua argumen: nama file .hprof asli dan lokasi untuk menulis file .hprof yang dikonversi, termasuk nama file .hprof baru. Contoh:

hprof-conv heap-original.hprof heap-converted.hprof

Referensi lainnya

• Merekam heap dump (Tampilan)