The Android Developer Challenge is back! Submit your idea before December 2.

Menampilkan alokasi memori dan heap Java 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 oleh aplikasi Anda, 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 menghubungkan perangkat melalui USB tetapi tidak melihatnya tercantum, pastikan Anda sudah 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.

Mengapa Anda harus membuat profil memori aplikasi

Android menyediakan lingkungan memori terkelola; ketika 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, silakan 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 fitur 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 lebih rendah, 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 tinggi, 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 penghitungan 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 grafik lainnya, walaupun kode yang ditulis menggunakan bahasa Java atau Kotlin.

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

  • Stack: Memori yang digunakan oleh tumpukan Java maupun native dalam aplikasi Anda. Kategori ini biasanya berkaitan dengan banyaknya thread yang dijalankan oleh aplikasi.

  • Code: Memori yang digunakan aplikasi untuk kode dan resource, misalnya bytecode dex, kode dex yang dihimpun 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 rendah, 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 tinggi.

Ketika dibandingkan dengan penghitungan memori dari fitur Android Monitor versi sebelumnya, Memory Profiler yang baru akan merekam memori dalam 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 fitur 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 oleh aplikasi Anda.

Menampilkan alokasi memori

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

  • Tipe objek yang telah dialokasikan dan banyaknya ruang yang digunakannya.
  • Pelacakan tumpukan dari setiap alokasi, serta dalam thread yang mana.
  • Kapan objek dibebaskan alokasinya (hanya saat menggunakan perangkat dengan Android 8.0 atau yang lebih tinggi).

Jika perangkat menjalankan Android 8.0 atau yang lebih tinggi, Anda dapat menampilkan alokasi objek kapan saja dengan cara berikut: Tarik dalam linimasa untuk memilih region yang ingin dilihat alokasinya (seperti dalam video 1). Tidak perlu memulai sesi perekaman karena Android 8.0 dan yang lebih tinggi menyertakan alat pembuatan profil bawaan yang terus-menerus melacak alokasi aplikasi.

Video 1. Dengan Android 8.0 dan yang lebih tinggi, pilih area linimasa yang sudah ada untuk menampilkan alokasi objek

Jika perangkat menjalankan Android 7.1 atau yang lebih rendah, klik Record memory allocations di toolbar Memory Profiler. Selagi merekam, Memory Profiler akan melacak semua alokasi yang terjadi dalam aplikasi Anda. Setelah selesai, klik Stop recording (tombol yang sama; lihat video 2) untuk melihat alokasi.

Video 2. Dengan Android 7.1 dan yang lebih rendah, Anda harus merekam alokasi memori secara eksplisit

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

Untuk memeriksa rekaman alokasi, 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, 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 terhadap huruf besar kecil.
  2. Di panel Instance View, klik salah satu instance. Tab Call Stack akan muncul di bawahnya, menampilkan tempat instance dialokasikan dan dalam thread yang 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 setelan default.
  • 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.

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 menerapkan aplikasi ke perangkat yang menjalankan Android 8.0 atau lebih tinggi.

Untuk mengetahui informasi selengkapnya tentang JNI, lihat tips JNI.

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 rendah saat Anda merekam heap dump selagi merekam alokasi.)

Untuk merekam heap dump, klik Dump Java heap di toolbar Memory Profiler. 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.

Heap dump akan muncul di bawah linimasa memori, menampilkan semua tipe class dalam heap, seperti pada gambar 5.

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 tipe 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 setelan default.
  • 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 utama 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 pohon dominator).

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, 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 terhadap huruf besar kecil.
  2. Di panel Instance View, klik salah satu instance. Tab References akan muncul di bawahnya, 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 yang terkait dari heap dump, menunjukkan data instance miliknya sendiri kepada Anda.

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

  • Referensi berumur panjang untuk Activity, Context, View, Drawable, dan objek lain yang mungkin menyimpan referensi ke penampung Activity atau Context.
  • Kelas 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 rendah, tombol Export capture to file berada di sebelah kiri toolbar di bawah linimasa; di Android Studio 3.2 dan yang lebih tinggi, ada tombol Export Heap Dump di sebelah kanan setiap entri Heap Dump di panel Sessions. Dalam 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 fitur hprof-conv yang disediakan dalam direktori android_sdk/platform-tools/. Jalankan perintah hprof-conv dengan dua argumen: file HPROF yang 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 Session, pilih Load from file, lalu pilih file dari browser file.

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

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 beberapa kali dalam berbagai status aktivitas. Memutar perangkat sering kali dapat menyebabkan aplikasi membocorkan objek Activity, Context, atau View karena sistem akan membuat ulang Activity; dan jika aplikasi Anda menyimpan referensi ke salah satu objek tersebut di tempat lain, sistem tidak dapat 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.