Memeriksa penggunaan memori aplikasi dengan Memory Profiler

Memory Profiler adalah komponen dalam Android Profiler yang membantu Anda mengidentifikasi kebocoran memori dan churn memori yang dapat menyebabkan aplikasi tersendat, berhenti merespons, dan bahkan tidak bekerja. Komponen ini menampilkan grafik yang realtime atas penggunaan memori aplikasi Anda, yang memungkinkan Anda merekam heap dump, memaksa pembersihan sampah memori, dan melacak alokasi memori.

Untuk membuka Memory Profiler, ikuti langkah-langkah berikut:

1. Klik View > Tool Windows > Profiler (Anda juga dapat mengklik Profile di toolbar).
2. Pilih perangkat dan proses aplikasi yang ingin dibuat profilnya dari toolbar Android Profiler. Jika Anda telah menyambungkan perangkat melalui USB, tetapi tidak melihatnya tercantum, pastikan Anda telah mengaktifkan proses debug USB.
3. Klik di mana saja dalam linimasa MEMORY untuk membuka Memory Profiler.

Atau, Anda dapat memeriksa memori aplikasi dari command line dengan dumpsys, dan juga melihat peristiwa 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 beberapa 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, mulai ulang penuh akan diperlukan.

Untuk membantu mencegah masalah ini, Anda harus menggunakan Memory Profiler untuk melakukan hal berikut:

• Mencari pola alokasi memori yang tidak diinginkan dalam linimasa yang mungkin menyebabkan masalah performa.
• Membuang heap Java untuk mengetahui objek mana yang menggunakan banyak memori pada waktu tertentu. Beberapa heap dump dalam jangka waktu yang cukup panjang dapat membantu mengidentifikasi kebocoran memori.
• Merekam alokasi memori selama interaksi pengguna yang normal dan ekstrem untuk mengidentifikasi secara persis ke mana kode Anda mengalokasikan terlalu banyak objek dalam waktu singkat atau mengalokasikan objek yang kemudian bocor.

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

Ringkasan Memory Profiler

Saat membuka Memory Profiler untuk kali pertama, Anda akan melihat linimasa mendetail tentang penggunaan memori aplikasi dan alat akses untuk memaksa pembersihan sampah memori, merekam heap dump, dan merekam alokasi memori.

Gambar 1. Memory Profiler

Sebagaimana ditunjukkan dalam gambar 1, tampilan default Memory Profiler menyertakan hal-hal berikut:

1. Tombol untuk memaksa peristiwa pembersihan sampah memori.

2. Tombol untuk merekam heap dump.

   Catatan: Tombol untuk merekam alokasi memori akan muncul di sebelah kanan tombol heap dump hanya ketika terhubung ke perangkat yang menjalankan Android 7.1 (API level 25) atau yang lebih rendah.

3. Menu drop-down untuk menentukan seberapa sering profiler merekam alokasi memori. Memilih opsi yang sesuai dapat membantu Anda meningkatkan performa aplikasi saat membuat profil.
4. Tombol untuk memperbesar/memperkecil tampilan linimasa.
5. Tombol untuk melompat maju ke data memori langsung.
6. Linimasa peristiwa, yang menampilkan status aktivitas, peristiwa input pengguna, dan peristiwa rotasi layar.
7. Memori menggunakan linimasa, yang mencakup hal-hal berikut:
   • Grafik bertumpuk tentang banyaknya memori yang sedang digunakan oleh setiap kategori memori, sebagaimana ditunjukkan oleh sumbu y di sebelah kiri dan kunci warna di bagian atas.
   • Garis putus-putus yang menunjukkan jumlah objek yang dialokasikan, sebagaimana ditunjukkan oleh sumbu y di sebelah kanan.
   • Ikon untuk setiap peristiwa pembersihan sampah memori.

Namun, jika menggunakan perangkat yang menjalankan Android 7.1 atau yang lebih lama, tidak semua data pembuatan profil akan terlihat secara default. Jika melihat pesan "Advanced profiling is unavailable for the selected process", Anda perlu mengaktifkan pembuatan profil lanjutan untuk melihat hal-hal berikut:

• Linimasa peristiwa
• Jumlah objek yang dialokasikan
• Peristiwa pembersihan sampah memori

Di Android 8.0 dan yang lebih baru, pembuatan profil lanjutan selalu diaktifkan untuk aplikasi yang dapat di-debug.

Cara menghitung memori

Angka yang Anda lihat di bagian atas Memory Profiler (gambar 2) didasarkan pada semua halaman memori pribadi yang telah dilakukan oleh aplikasi Anda menurut sistem Android. Jumlah ini tidak termasuk halaman yang digunakan bersama sistem atau aplikasi lainnya.

Gambar 2. Legenda jumlah memori di bagian atas Memory Profiler

Kategori dalam jumlah memori adalah sebagai berikut:

• Java: Memori dari objek yang dialokasikan dari kode Java atau Kotlin.

• Native: Memori dari objek yang dialokasikan dari kode C atau C++.

  Meskipun tidak menggunakan C++ dalam aplikasi, Anda mungkin melihat ada beberapa memori native yang digunakan di sini karena framework Android menggunakannya untuk menangani beragam tugas atas nama Anda, misalnya saat menangani aset gambar dan grafis lainnya, walaupun kode yang ditulis menggunakan bahasa Java atau Kotlin.

• Graphics: Memori yang digunakan untuk antrean buffer grafis agar dapat menampilkan piksel ke layar, termasuk permukaan GL, tekstur GL, dan seterusnya. (Perlu diketahui bahwa ini adalah memori yang digunakan bersama CPU, bukan memori GPU khusus.)

• Stack: Memori yang digunakan oleh stack Java dan native dalam aplikasi Anda. Biasanya memori ini berkaitan dengan jumlah thread yang dijalankan oleh aplikasi Anda.

• Code: Memori yang digunakan oleh aplikasi untuk kode dan resource, misalnya bytecode dex, kode dex yang telah dikompilasi atau dioptimalkan, library .so, dan font.

• Others: Memori yang digunakan oleh aplikasi, tetapi sistem tidak yakin bagaimana cara mengategorikannya.

• Allocated: Jumlah objek Java/Kotlin yang dialokasikan oleh aplikasi Anda. Jumlah ini tidak termasuk objek yang dialokasikan di C atau C++.

  Saat terhubung ke perangkat yang menjalankan Android 7.1 dan yang lebih lama, penghitungan alokasi ini hanya akan dimulai saat Memory Profiler terhubung ke aplikasi yang sedang berjalan. Oleh karena itu, objek yang dialokasikan sebelum Anda memulai pembuatan profil tidak akan diperhitungkan. Namun, Android 8.0 dan yang lebih tinggi menyertakan fitur pembuatan profil bawaan yang melacak semua alokasi sehingga angka ini selalu menunjukkan jumlah total objek Java yang masih harus diselesaikan dalam aplikasi di Android 8.0 dan yang lebih baru.

Jika dibandingkan dengan jumlah memori dari alat Android Monitor versi sebelumnya, Memory Profiler yang baru merekam memori dengan cara yang berbeda sehingga penggunaan memori Anda sekarang mungkin terlihat lebih tinggi. Memory Profiler memantau beberapa kategori tambahan yang menambah total tersebut, tetapi jika Anda hanya memedulikan memori heap Java, angka "Java" akan mendekati nilai dari alat sebelumnya. Walaupun angka Java tersebut mungkin tidak sama persis dengan yang terlihat di Android Monitor, angka yang baru ini memperhitungkan semua halaman memori fisik yang telah dialokasikan ke heap Java aplikasi Anda sejak tahap pertama pengembangannya. Jadi, angka ini memberikan representasi yang akurat tentang berapa banyak memori fisik yang sebenarnya digunakan aplikasi Anda.

Catatan: Saat menggunakan perangkat yang menjalankan Android 8.0 (API level 26) dan yang lebih tinggi, Memory Profiler juga akan menunjukkan beberapa penggunaan memori native positif palsu (PP) dalam aplikasi Anda yang sebenarnya dimiliki oleh alat pembuatan profil. Hingga 10 MB memori ditambahkan untuk setidaknya 100.000 objek Java. Dalam versi IDE mendatang, angka ini akan difilter dari data Anda.

Menampilkan alokasi memori

Alokasi memori menunjukkan kepada Anda cara setiap objek Java dan referensi JNI dalam memori dialokasikan. Secara spesifik, Memory Profiler dapat menunjukkan hal-hal berikut tentang alokasi objek:

• Jenis objek yang telah dialokasikan dan banyaknya ruang yang digunakannya.
• Stack trace dari setiap alokasi, termasuk di thread mana.
• Kapan objek didealokasi (hanya saat menggunakan perangkat dengan Android 8.0 atau yang lebih baru).

Untuk merekam alokasi Java dan Kotlin, pilih Record Java / Kotlin allocations, lalu pilih Record. Jika perangkat menjalankan Android 8 atau yang lebih tinggi, UI Memory Profiler akan bertransisi ke layar terpisah yang menampilkan rekaman yang sedang berlangsung. Anda dapat berinteraksi dengan linimasa mini di atas rekaman (misalnya, untuk mengubah rentang pemilihan). Untuk menyelesaikan perekaman, pilih Stop .

Pada Android 7.1 dan versi yang lebih lama, memory profiler menggunakan rekaman alokasi lama, yang menampilkan rekaman di linimasa sampai Anda mengklik Stop.

Setelah memilih region linimasa (atau setelah menyelesaikan sesi perekaman dengan perangkat yang menjalankan Android 7.1 atau yang lebih lama), daftar objek yang dialokasikan akan muncul, dikelompokkan berdasarkan nama class, dan diurutkan berdasarkan jumlah heap-nya.

Catatan: Di Android 7.1 dan yang lebih lama, Anda dapat merekam maksimum 65535 alokasi. Jika sesi perekaman melebihi batas ini, hanya 65535 alokasi terbaru yang akan disimpan dalam rekaman. (Tidak ada batas praktis pada Android 8.0 dan yang lebih baru.)

Untuk memeriksa rekaman alokasi, ikuti langkah-langkah berikut:

1. Jelajahi daftar untuk menemukan objek yang memiliki jumlah heap tidak wajar dan yang kemungkinan sudah bocor. Untuk membantu menemukan class yang dikenal, klik header kolom Class Name untuk mengurutkan menurut abjad. Kemudian, klik nama class. Panel Instance View akan muncul di sebelah kanan, yang menampilkan setiap instance class tersebut, seperti dalam gambar 3.
   • Atau, Anda dapat segera menemukan objek dengan mengklik Filter , atau dengan menekan Control+F (Command+F di Mac) dan memasukkan nama class atau paket di kolom penelusuran. Anda juga dapat menelusuri menurut nama metode jika memilih Arrange by callstack dari menu drop-down. Jika ingin menggunakan ekspresi reguler, centang kotak di samping Regex. Centang kotak di samping Match case jika kueri penelusuran peka huruf besar/kecil.
2. Di panel Instance View, klik salah satu instance. Tab Call Stack akan muncul di bawahnya, yang menampilkan tempat instance dialokasikan dan di thread mana.
3. Di tab Call Stack, klik kanan baris mana pun dan pilih Jump to Source untuk membuka kode tersebut dalam editor.

Gambar 3. Detail tentang setiap objek yang dialokasikan muncul dalam Instance View di sebelah kanan.

Anda dapat menggunakan dua menu di atas daftar objek yang dialokasikan untuk memilih heap yang akan diperiksa dan cara menata data yang ada.

Dari menu di sebelah kiri, pilih heap yang akan diperiksa:

• default heap: Ketika tidak ada heap yang ditentukan oleh sistem.
• image heap: Image boot sistem, berisi class yang dipramuat pada waktu boot. Alokasi di sini dijamin tidak akan pernah berpindah atau hilang.
• zygote heap: Heap salin-saat-menulis, yang menjadi tempat pemisahan proses aplikasi di sistem Android.
• app heap: Heap utama tempat aplikasi Anda mengalokasikan memori.
• JNI heap: Heap yang menunjukkan tempat referensi Java Native Interface (JNI) dialokasikan dan dilepaskan.

Dari menu di sebelah kanan, pilih cara untuk mengatur alokasi:

• Arrange by class: Mengelompokkan semua alokasi berdasarkan nama class. Ini adalah defaultnya.
• Arrange by package: Mengelompokkan semua alokasi berdasarkan nama paket.
• Arrange by callstack: Mengelompokkan semua alokasi ke dalam stack panggilan yang sesuai.

Meningkatkan performa aplikasi saat membuat profil

Untuk meningkatkan performa aplikasi saat membuat profil, profiler memori akan secara berkala mengambil sampel alokasi memori secara default. Saat melakukan pengujian di perangkat yang menjalankan API level 26 atau yang lebih tinggi, Anda dapat mengubah perilaku ini menggunakan drop-down Allocation Tracking . Opsi yang tersedia adalah sebagai berikut:

• Full: Merekam semua alokasi objek dalam memori. Ini adalah perilaku default di Android Studio 3.2 dan yang lebih lama. Jika memiliki aplikasi yang mengalokasikan banyak objek, Anda mungkin melihat pelambatan yang cukup jelas dengan aplikasi saat membuat profil.
• Sampled: Mengambil sampel alokasi objek dalam memori pada interval rutin. Opsi ini merupakan default dan tidak berdampak terlalu besar pada performa aplikasi saat membuat profil. Aplikasi yang mengalokasikan banyak objek dalam rentang waktu singkat mungkin masih menunjukkan pelambatan yang jelas.
• Off: Menghentikan pelacakan alokasi memori aplikasi Anda.

Catatan: Secara default, Android Studio akan berhenti melacak alokasi langsung saat melakukan perekaman CPU dan mengaktifkannya kembali setelah perekaman CPU selesai. Anda dapat mengubah perilaku ini di dialog konfigurasi perekaman aktivitas CPU.

Menampilkan referensi JNI global

Java Native Interface (JNI) adalah framework yang memungkinkan kode Java dan kode native memanggil satu sama lain.

Referensi JNI dikelola secara manual oleh kode native sehingga objek Java mungkin saja digunakan oleh kode native agar tetap hidup untuk waktu yang terlalu lama. Beberapa objek pada heap Java mungkin menjadi tidak terjangkau jika referensi JNI dibuang tanpa dihapus secara eksplisit terlebih dahulu. Selain itu, Anda juga dapat menggunakan batas referensi JNI global.

Untuk memecahkan masalah tersebut, gunakan tampilan JNI Heap di Memory Profiler untuk menjelajahi semua referensi JNI global dan memfilternya menurut tipe Java dan stack panggilan asli. Dengan informasi ini, Anda dapat menemukan kapan dan di mana referensi JNI global dibuat dan dihapus.

Saat aplikasi sedang berjalan, pilih bagian linimasa yang ingin diperiksa dan pilih JNI heap dari menu drop-down di atas daftar class. Selanjutnya, Anda dapat memeriksa objek dalam heap seperti biasanya dan mengklik dua kali objek di tab Allocation Call Stack untuk melihat tempat referensi JNI dialokasikan dan dirilis dalam kode, seperti dalam gambar 4.

Gambar 4. Menampilkan referensi JNI global

Untuk memeriksa alokasi memori bagi kode JNI aplikasi, Anda harus men-deploy aplikasi ke perangkat yang menjalankan Android 8.0 atau lebih baru.

Untuk mengetahui informasi selengkapnya tentang JNI, lihat tips JNI.

Native Memory Profiler

Memory Profiler Android Studio menyertakan Native Memory Profiler untuk aplikasi di-deploy ke perangkat fisik dan virtual yang menjalankan Android 10 dan yang lebih tinggi.

Native Memory Profiler melacak alokasi/dealokasi objek dalam kode native selama jangka waktu tertentu dan memberikan informasi berikut:

• Alokasi: Jumlah objek yang dialokasikan melalui operator malloc() atau new selama jangka waktu yang dipilih.
• Dealokasi: Jumlah objek yang dibatalkan alokasinya melalui operator free() atau delete selama jangka waktu yang dipilih.
• Ukuran Alokasi: Ukuran gabungan dalam byte dari semua alokasi selama jangka waktu yang dipilih.
• Ukuran Dealokasi: Ukuran gabungan dalam byte dari semua memori yang dibebaskan selama jangka waktu yang dipilih.
• Jumlah Total: Nilai di kolom Alokasi dikurangi nilai di kolom Dealokasi.
• Ukuran Tersisa: Nilai di kolom Ukuran Alokasi dikurangi nilai di kolom Ukuran Dealokasi.

Untuk merekam alokasi native pada perangkat yang menjalankan Android 10 dan versi yang lebih baru, pilih Record native allocations, lalu pilih Record. Rekaman akan berlanjut sampai Anda mengklik Stop , setelah itu UI Memory Profiler akan bertransisi ke layar terpisah yang menampilkan rekaman native.

Pada Android 9 dan versi yang lebih lama, opsi Record native allocations tidak tersedia.

Secara default, Native Memory Profiler menggunakan ukuran sampel 32 byte: Setiap kali 32 byte memori dialokasikan, snapshot memori diambil. Ukuran sampel yang lebih kecil menghasilkan snapshot yang lebih sering, sehingga menghasilkan data penggunaan memori yang lebih akurat. Ukuran sampel yang lebih besar menghasilkan data yang kurang akurat, tetapi akan mengurangi resource yang digunakan pada sistem Anda dan meningkatkan performa saat merekam.

Untuk mengubah ukuran sampel Native Memory Profiler:

1. Pilih Run > Edit Configurations.
2. Pilih modul aplikasi dalam panel kiri.
3. Klik tab Profiling, dan masukkan ukuran sampel di kolom berlabel Native memory sampling interval (bytes).
4. Build dan jalankan aplikasi kembali.

Catatan: Data memori yang diberikan oleh Native Memory Profiler berbeda dengan data yang diberikan oleh memory profiler untuk heap Java. Daripada membuat profil objek pada heap Java, Native Memory Profiler hanya melacak alokasi yang dibuat melalui alokator C/C++, termasuk objek JNI native.

Native Memory Profiler di-build di heapprofd dalam stack alat analisis performa Perfetto. Untuk informasi lebih lanjut tentang internal Native Memory Profiler, lihat dokumentasi heapprofd.

Catatan: Mulai rilis Android Studio versi 4.1, Native Memory Profiler dinonaktifkan selama startup aplikasi. Opsi ini akan diaktifkan dalam rilis mendatang.

Sebagai solusinya, Anda dapat menggunakan profiler command line mandiri Perfetto untuk mengambil profil startup.

Merekam heap dump

Heap dump menunjukkan objek mana dalam aplikasi Anda yang menggunakan memori pada saat Anda merekam heap dump. Khususnya, setelah sesi pengguna yang cukup lama, heap dump dapat membantu mengidentifikasi kebocoran memori dengan menampilkan objek yang masih dalam memori yang menurut Anda seharusnya sudah tidak ada lagi di sana.

Setelah merekam heap dump, Anda dapat menampilkan hal-hal berikut:

• Tipe objek yang telah dialokasikan aplikasi, dan jumlahnya masing-masing.
• Banyaknya memori yang digunakan setiap objek.
• Tempat referensi ke setiap objek disimpan dalam kode Anda.
• Stack panggilan untuk tempat objek dialokasikan. (Stack panggilan saat ini tersedia dengan heap dump hanya di Android 7.1 dan yang lebih lama saat Anda merekam heap dump sambil merekam alokasi.)

Untuk merekam heap dump, klik Capture heap dump, lalu pilih Record. 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 profiler selesai merekam heap dump, UI Memory Profiler akan bertransisi ke layar terpisah yang menampilkan heap dump.

Gambar 5. Menampilkan heap dump.

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

Dalam daftar class, Anda dapat melihat informasi berikut:

• Allocations: Jumlah alokasi dalam heap.

• Native Size: Jumlah total memori native yang digunakan oleh tipe objek ini (dalam byte). Kolom ini hanya terlihat untuk Android 7.0 dan yang lebih tinggi.

  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 jenis objek ini (dalam byte).

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

Anda dapat menggunakan dua menu di atas daftar objek yang dialokasikan untuk memilih heap dump mana yang akan diperiksa dan cara mengatur data yang ada.

Dari menu di sebelah kiri, pilih heap yang akan diperiksa:

• default heap: Ketika tidak ada heap yang ditentukan oleh sistem.
• app heap: Heap utama tempat aplikasi Anda mengalokasikan memori.
• image heap: Image boot sistem, berisi class yang dipramuat pada waktu boot. Alokasi di sini dijamin tidak akan pernah berpindah atau hilang.
• zygote heap: Heap salin-saat-menulis, yang menjadi tempat pemisahan proses aplikasi di sistem Android.

Dari menu di sebelah kanan, pilih cara untuk mengatur alokasi:

• Arrange by class: Mengelompokkan semua alokasi berdasarkan nama class. Ini adalah defaultnya.
• Arrange by package: Mengelompokkan semua alokasi berdasarkan nama paket.
• Arrange by callstack: Mengelompokkan semua alokasi ke dalam stack panggilan yang sesuai. Opsi ini hanya berfungsi jika Anda merekam heap dump selagi merekam alokasi. Meskipun demikian, mungkin ada objek dalam heap yang dialokasikan sebelum Anda memulai perekaman sehingga alokasi tersebut muncul terlebih dahulu, yang hanya dicantumkan menurut nama class.

Daftar ini diurutkan menurut kolom Retained Size secara default. Untuk mengurutkan menurut nilai dalam kolom lain, klik judul kolom.

Klik nama class untuk membuka jendela Instance View di sebelah kanan (seperti dalam gambar 6). Setiap instance yang tercantum menyertakan 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).

Catatan: Secara default, heap dump tidak menampilkan pelacakan tumpukan untuk setiap objek yang dialokasikan. Untuk mendapatkan pelacakan tumpukan, Anda harus mulai merekam alokasi memori sebelum mengklik Capture heap dump. Kemudian, Anda dapat memilih instance dalam Instance View dan melihat tab Call Stack di samping tab References, seperti dalam gambar 6. Namun, beberapa objek kemungkinan telah dialokasikan sebelum Anda mulai merekam alokasi sehingga stack panggilan tidak tersedia untuk objek tersebut. Instance yang menyertakan stack panggilan ditunjukkan dengan badge "stack" pada ikonnya . (Sayangnya, karena pelacakan tumpukan mengharuskan Anda melakukan perekaman alokasi, Anda saat ini tidak dapat melihat pelacakan tumpukan untuk heap dump di Android 8.0.)

Gambar 6. Durasi yang diperlukan untuk merekam heap dump ditunjukkan dalam linimasa.

Untuk memeriksa heap, ikuti langkah-langkah ini:

1. Jelajahi daftar untuk menemukan objek yang memiliki jumlah heap tidak wajar dan yang kemungkinan sudah bocor. Untuk membantu menemukan class yang dikenal, klik header kolom Class Name untuk mengurutkan menurut abjad. Kemudian, klik nama class. Panel Instance View akan muncul di sebelah kanan, yang menampilkan setiap instance class tersebut, seperti dalam gambar 6.
   • Atau, Anda dapat segera menemukan objek dengan mengklik Filter , atau dengan menekan Control+F (Command+F di Mac) dan memasukkan nama class atau paket di kolom penelusuran. Anda juga dapat menelusuri menurut nama metode jika memilih Arrange by callstack dari menu drop-down. Jika ingin menggunakan ekspresi reguler, centang kotak di samping Regex. Centang kotak di samping Match case jika kueri penelusuran peka huruf besar/kecil.
2. Di panel Instance View, klik salah satu instance. Tab References akan muncul di bawahnya, yang menampilkan setiap referensi ke objek tersebut.

   Atau, klik panah di samping nama instance untuk menampilkan semua kolomnya, kemudian klik nama kolom untuk menampilkan semua referensinya. Jika ingin melihat detail instance untuk kolom, klik kanan kolom dan pilih Go to Instance.

3. Di tab References, jika Anda mengidentifikasi referensi yang mungkin membocorkan memori, klik kanan referensi dan pilih Go to Instance. Tindakan ini akan memilih instance terkait dari heap dump, yang menunjukkan data instance miliknya sendiri kepada Anda.

Dalam heap dump, cari kebocoran memori yang disebabkan oleh salah satu hal berikut:

• Referensi berumur panjang ke Activity, Context, View, Drawable, dan objek lainnya yang mungkin menyimpan referensi ke container Activity atau Context.
• Class internal non-statis, seperti Runnable, yang dapat menyimpan instance Activity.
• Cache yang menyimpan objek lebih lama dari yang diperlukan.

Menyimpan heap dump sebagai file HPROF

Setelah Anda merekam heap dump, data hanya dapat dilihat di Memory Profiler ketika profiler dijalankan. Ketika keluar dari sesi pembuatan profil, Anda akan kehilangan heap dump tersebut. Jadi, jika ingin menyimpannya untuk ditinjau nanti, ekspor heap dump ke file HPROF. Di Android Studio 3.1 dan yang lebih lama, tombol Export capture to file berada di sebelah kiri toolbar di bawah linimasa; di Android Studio 3.2 dan yang lebih baru, ada tombol Export Heap Dump di sebelah kanan setiap entri Heap Dump di panel Sessions. Pada dialog Export As yang muncul, simpan file dengan ekstensi nama file .hprof.

Untuk menggunakan penganalisis HPROF lainnya, seperti jhat, Anda perlu mengonversi file HPROF dari format Android menjadi format HPROF Java SE. Anda dapat melakukannya dengan alat hprof-conv yang disediakan dalam direktori android_sdk/platform-tools/. Jalankan perintah hprof-conv dengan dua argumen: file HPROF asli dan lokasi untuk menulis file HPROF yang telah dikonversi. Contoh:

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

Mengimpor file heap dump

Untuk mengimpor file HPROF (.hprof), klik Start a new profiling session di panel Sessions, pilih Load from file, lalu pilih file dari file browser.

Anda juga dapat mengimpor file HPROF dengan menariknya dari browser file ke jendela editor.

Deteksi kebocoran di Memory Profiler

Saat menganalisis heap dump di Memory Profiler, Anda dapat memfilter data pembuatan profil yang dianggap Android Studio dapat menunjukkan kebocoran memori untuk instance Activity dan Fragment di aplikasi Anda.

Jenis data yang ditampilkan filter mencakup yang berikut:

• Instance Activity yang telah dihapus tetapi masih direferensikan.
• Instance Fragment yang tidak memiliki FragmentManager valid tetapi masih direferensikan.

Dalam situasi tertentu, seperti berikut ini, filter mungkin menghasilkan positif palsu:

• Fragment dibuat tetapi belum digunakan.
• Fragment di-cache tetapi bukan sebagai bagian dari FragmentTransaction.

Untuk menggunakan fitur ini, pertama ambil heap dump atau impor file heap dump ke Android Studio. Untuk menampilkan fragmen dan aktivitas yang mungkin membocorkan memori, centang kotak Activity/Fragment Leaks pada panel heap dump Memory Profiler, seperti yang ditunjukkan pada gambar 7.

Gambar 7. Memfilter heap dump untuk kebocoran memori.

Teknik untuk membuat profil memori

Saat menggunakan Memory Profiler, 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 lama sebelum memeriksa heap. Kebocoran mungkin sampai ke bagian atas alokasi dalam heap tersebut. Namun, semakin kecil kebocorannya, semakin lama Anda perlu menjalankan aplikasi tersebut 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, Context, atau objek View karena sistem membuat ulang Activity dan jika aplikasi menyimpan referensi ke salah satu objek itu di tempat lain, sistem tidak bisa membersihkan sampah memorinya.
• Beralihlah antara aplikasi Anda dan aplikasi lain dalam berbagai status aktivitas (buka Layar utama, kemudian kembali ke aplikasi Anda).

Tips: Anda juga dapat melakukan langkah-langkah di atas menggunakan framework pengujian monkeyrunner.