Merekam heap dump

Rekam heap dump untuk melihat objek mana dalam aplikasi Anda yang menggunakan banyak memori pada saat perekaman dan identifikasi kebocoran memori, atau perilaku alokasi memori yang menyebabkan aplikasi tersendat, berhenti merespons, dan bahkan tidak berfungsi. Heap dump sangat berguna untuk diambil setelah sesi pengguna yang cukup lama, karena dapat menunjukkan objek yang masih ada dalam memori yang seharusnya sudah tidak ada lagi di sana.

Halaman ini menjelaskan alat yang disediakan Android Studio untuk mengumpulkan dan menganalisis dump heap. Atau, Anda dapat memeriksa memori aplikasi dari command line dengan dumpsys dan juga melihat peristiwa pengumpulan sampah (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 melepas kembali memori yang tidak terpakai ke heap. Cara Android melakukan pencarian memori yang tidak terpakai akan terus ditingkatkan, tetapi pada beberapa titik dalam semua versi Android, sistem harus menjeda kode Anda sesaat. Biasanya, penjedaan ini tidak akan terasa. Namun, jika aplikasi mengalokasikan memori lebih cepat dari waktu sistem mengumpulkannya, aplikasi mungkin akan tertunda saat pembersih membebaskan memori dalam jumlah yang cukup untuk memenuhi alokasi Anda. Penundaan ini dapat menyebabkan aplikasi melewati frame dan menyebabkan kelambatan yang cukup 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 Anda.

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 merekam heap dump, Anda akan melihat hal berikut:

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 tipe 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.

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

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

Gunakan menu tumpukan untuk memfilter tumpukan tertentu:

  • Heap aplikasi (default): Heap utama tempat aplikasi Anda mengalokasikan memori.
  • Image heap: Image boot sistem, berisi class yang dipramuat selama waktu boot. Alokasi di sini tidak pernah berpindah atau hilang.
  • Zygote heap: Heap salin-saat-menulis, yang menjadi tempat pemisahan proses aplikasi di sistem Android.

Gunakan drop-down pengaturan untuk memilih cara mengatur alokasi:

  • Arrange by 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.
  • Tampilkan kebocoran aktivitas/fragmen: Menampilkan class yang menyebabkan kebocoran memori.
  • Tampilkan class project: 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 instance ini (berdasarkan hierarki dominator).

Klik instance untuk menampilkan Detail Instance, termasuk Kolom dan Referensi-nya. 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.
  • Referensi: Menampilkan setiap referensi ke objek yang ditandai di tab Instance.
Tampilan Instance, Kolom, dan Referensi di jendela alat Heap Dump.

Menemukan kebocoran memori

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

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 bertahan lama ke Activity atau Context yang dapat membocorkan grafik komposisi Compose yang dihosting (seperti ComposeView dan sub-komposisinya).
  • Objek Status Jetpack Compose yang bocor (MutableState), holder status, atau lambda yang mengambil Context.
  • Lupa membersihkan pemroses atau pengamat di blok onDispose dari DisposableEffect.
  • Class internal 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 Kolom dan Referensi di Detail Instance untuk membuka instance atau baris kode sumber yang diinginkan.

Memicu kebocoran memori untuk pengujian

Untuk menganalisis penggunaan memori, Anda harus memberikan tekanan pada kode aplikasi Anda dan mencoba memaksa kebocoran memori. Salah satu cara untuk menyebabkan kebocoran memori dalam aplikasi adalah dengan membiarkannya berjalan beberapa saat sebelum memeriksa heap. Kebocoran mungkin sampai ke bagian atas alokasi dalam heap tersebut. Namun, semakin kecil kebocorannya, semakin lama Anda perlu menjalankan aplikasi untuk melihatnya.

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

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

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.

Sebagai alternatif, untuk menggunakan penganalisis file .hprof lainnya seperti jhat, Anda perlu mengonversi file .hprof dari format Android menjadi 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 telah dikonversi, termasuk nama file .hprof baru. Contoh:

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

Referensi lainnya