Menyelidiki Penggunaan RAM Anda

Ketika mengembangkan aplikasi Android, selalu perhatikan berapa banyak random-access memory (RAM) yang digunakan aplikasi Anda. Meskipun waktu proses Dalvik dan ART melakukan pengumpulan sampah (GC) rutin, Anda tetap perlu memahami kapan dan di mana aplikasi Anda mengalokasikan dan membebaskan memori. Untuk memberikan pengalaman pengguna yang stabil ketika sistem operasi Android dengan cepat berganti antar aplikasi, pastikan bahwa aplikasi Anda tidak memakai memori dengan tidak perlu ketika pengguna tidak berinteraksi dengannya.

Bahkan meski Anda mengikuti praktik terbaik untuk Mengelola Memori Aplikasi selama development, Anda mungkin masih membocorkan objek atau memunculkan bug memori yang lain. Satu-satunya cara untuk memastikan aplikasi Anda menggunakan memori sesedikit mungkin adalah dengan menganalisis penggunaan memori aplikasi dengan alat yang dijelaskan di sini.

Mengartikan pesan log

Tempat paling sederhana untuk memulai penyelidikan penggunaan memori aplikasi Anda adalah dalam pesan log waktu proses. Kadang saat terjadi GC, Anda bisa melihat pesan di logcat.

Pesan log Dalvik

Dalam Dalvik (namun bukan ART), setiap GC mencetak informasi berikut ke logcat:

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>

Contoh:

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
Alasan GC
Hal yang memicu GC dan jenis pengumpulannya. Alasan yang mungkin muncul meliputi:
GC_CONCURRENT
GC yang secara bersamaan membebaskan memori ketika heap Anda mulai terisi.
GC_FOR_MALLOC
GC yang disebabkan karena aplikasi Anda mencoba mengalokasikan memori ketika heap telah penuh, sehingga sistem harus menghentikan aplikasi dan mengambil kembali memori.
GC_HPROF_DUMP_HEAP
GC yang terjadi ketika Anda meminta pembuatan file HPROF untuk menganalisis heap Anda.
GC_EXPLICIT
GC eksplisit, misalnya ketika Anda memanggil gc() (yang seharusnya tidak Anda panggil dan memercayai GC untuk berjalan bila diperlukan).
GC_EXTERNAL_ALLOC
Ini hanya terjadi pada API level 10 dan yang lebih rendah (versi yang lebih baru mengalokasikan semuanya di heap Dalvik). GC untuk memori yang dialokasikan secara eksternal (seperti data piksel yang disimpan dalam memori asli atau penyanggaan byte NIO).
Jumlah yang dibebaskan
Jumlah memori yang diperoleh kembali dari GC ini.
Statistik heap
Jumlah persentase heap dan (jumlah objek aktif)/(total ukuran heap).
Statistik memori eksternal
Memori yang dialokasikan secara eksternal pada API level 10 dan lebih rendah (jumlah memori yang dialokasikan) / (batas ketika pengumpulan akan terjadi).
Waktu jeda
Heap yang lebih besar akan memiliki waktu jeda lebih banyak. Waktu jeda bersamaan menunjukkan dua jeda: satu di awal pengumpulan dan lainnya di dekat akhir pengumpulan.

Saat pesan log ini terkumpul, waspadai peningkatan statistik heap (nilai 3571K/9991K dalam contoh di atas). Jika nilainya terus meningkat, Anda mungkin mengalami kebocoran memori.

Pesan log ART

Tidak seperti Dalvik, ART tidak mencatat log pesan untuk GC yang tidak diminta secara eksplisit. GC hanya dicetak ketika mereka dianggap lambat. Lebih tepatnya, jika jeda GC melebihi 5ms atau durasi GC melebihi 100ms. Jika aplikasi tidak dalam status proses yang bisa merasakan jeda, maka tidak satu pun dari GC-nya akan dianggap lambat. GC eksplisit selalu di-log.

ART menyertakan informasi berikut dalam pesan log pengumpulan sampah:

I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>

Contoh:

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms
Alasan GC
Hal yang memicu GC dan jenis pengumpulannya. Alasan yang mungkin muncul meliputi:
Concurrent
GC bersamaan yang tidak menangguhkan thread aplikasi. GC ini berjalan di thread latar belakang dan tidak mencegah alokasi.
Alloc
GC ini dimulai karena aplikasi Anda mencoba mengalokasikan memori saat heap sudah penuh. Dalam kasus ini, pengumpulan sampah terjadi di thread alokasi.
Explicit
Pengumpulan sampah secara eksplisit diminta oleh aplikasi, misalnya, dengan memanggil gc() atau gc(). Seperti halnya Dalvik, praktik terbaik dalam ART adalah dengan memercayai GC dan menghindari permintaan GC eksplisit, bilamana mungkin. GC eksplisit tidak dianjurkan karena memblokir thread alokasi dan menggunakan siklus CPU dengan sia-sia. GC eksplisit juga bisa menyebabkan jank (tersendat, bergetar, atau berhenti di aplikasi) jika mereka menyebabkan thread lain tertunda eksekusinya.
NativeAlloc
Pengumpulan disebabkan oleh tekanan memori native dari alokasi native seperti objek alokasi Bitmap atau RenderScript.
CollectorTransition
Pengumpulan disebabkan oleh transisi heap; ini disebabkan karena mengalihkan GC pada waktu proses. Transisi pengumpul terdiri dari penyalinan semua objek dari ruang yang didukung daftar-bebas ke ruang penunjuk tempelkan (atau sebaliknya). Transisi pengumpul saat ini hanya terjadi ketika sebuah aplikasi mengubah keadaan proses dari keadaan kentara jeda ke keadaan kentara non-jeda (atau sebaliknya) pada perangkat dengan sedikit RAM.
HomogeneousSpaceCompact
Pemadatan ruang homogen adalah pemadatan ruang daftar-bebas ke ruang daftar-bebas yang biasanya terjadi ketika suatu aplikasi dipindahkan ke keadaan proses tak kentara jeda. Alasan utama melakukannya adalah untuk mengurangi penggunaan RAM dan defragmentasi heap.
DisableMovingGc
Ini bukan alasan GC yang sebenarnya, namun harap perhatikan bahwa pengumpulan diblokir karena penggunaan GetPrimitiveArrayCritical. saat pemadatan heap yang bersamaan sedang terjadi. Secara umum, penggunaan GetPrimitiveArrayCritical sangat tidak dianjurkan karena pembatasannya pada memindahkan pengumpul.
HeapTrim
Ini bukan alasan GC, namun harap perhatikan bahwa pengumpulannya diblokir sampai pemotongan heap selesai.
Nama GC
ART memiliki berbagai GC berbeda yang bisa berjalan.
Concurrent mark sweep (CMS)
Pengumpul seluruh heap yang membebaskan pengumpulan semua ruang selain ruang gambar.
Concurrent partial mark sweep
Pengumpul hampir seluruh heap yang mengumpulkan semua ruang selain ruang gambar dan zygote.
Concurrent sticky mark sweep
Pengumpul generasional yang hanya bisa membebaskan objek yang dialokasikan sejak GC terakhir. Pengumpulan sampah ini dijalankan lebih sering dibandingkan mark sweep penuh atau sebagian karena lebih cepat dan memiliki jeda lebih rendah.
Marksweep + semispace
GC penyalin tidak bersamaan yang digunakan untuk transisi heap serta pemadatan ruang homogen (untuk melakukan defragmentasi heap).
Objek yang dibebaskan
Jumlah objek yang diperoleh kembali karena GC ini dari ruang objek tak besar.
Ukuran yang dibebaskan
Jumlah byte yang diperoleh kembali karena GC ini dari ruang objek tak besar.
Objek besar yang dibebaskan
Jumlah objek dalam ruang objek besar yang diperoleh kembali dari pengumpulan sampah ini.
Ukuran objek besar yang dibebaskan
Jumlah byte dalam ruang objek besar yang diperoleh kembali dari pengumpulan sampah ini.
Statistik heap
Persentase yang dibebaskan dan (jumlah objek aktif)/(total ukuran heap).
Waktu jeda
Biasanya waktu jeda berbanding lurus dengan jumlah referensi objek yang diubah saat GC berjalan. Saat ini, ART CMS GC hanya memiliki satu kali jeda, di dekat ujung GC. GC yang bergerak memiliki jeda panjang yang berlangsung selama mayoritas durasi GC.

Jika Anda melihat GC berjumlah besar dalam logcat, waspadai peningkatan dalam statistik heap (nilai 25MB/38MB dalam contoh di atas). Jika nilainya terus meningkat dan tidak mengecil, Anda mungkin mengalami kebocoran memori. Atau, jika Anda melihat GC untuk alasan "Alloc", maka Anda telah beroperasi mendekati kapasitas maksimal heap dan akan mendapat pengecualian OOM dalam waktu dekat.

Mengakses Android Monitor

  1. Jalankan aplikasi Anda pada perangkat atau emulator yang terhubung.
  2. Pilih View > Tool Windows > Android Monitor.
  3. Di sudut kiri atas Android Monitor, pilih tab Monitors.

    Gambar 1. Android Monitor dan tiga monitornya: Memory, CPU, dan GPU. Dalam Android Studio, perbesar panel Android Monitor secara vertikal untuk melihat monitor Network.

Menangkap heap dump

Heap dump adalah cuplikan semua objek di heap aplikasi Anda. Heap dump disimpan dalam format biner bernama HPROF yang bisa Anda unggah ke dalam alat bantu analisis seperti jhat. Heap dump aplikasi berisi informasi tentang keadaan heap aplikasi secara keseluruhan sehingga Anda bisa melacak masalah yang mungkin teridentifikasi saat melihat pembaruan heap.

  1. Di bagian atas monitor Memory, klik Dump Java Heap .

    Android Studio membuat file cuplikan heap dengan nama file application-id_yyyy.mm.dd_hh.mm.hprof, buka file di Android Studio, dan tambahkan file ke daftar Heap Snapshot dalam tab Captures.

  2. Dalam tab Captures, klik-kanan file tersebut dan pilih Export to standard .hprof.

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

Menampilkan pembaruan heap

Gunakan Android Monitor untuk menampilkan pembaruan real-time pada heap aplikasi saat Anda berinteraksi dengan aplikasi. Pembaruan real-time memberikan informasi tentang berapa banyak memori yang dialokasikan untuk operasi aplikasi yang berbeda. Anda bisa menggunakan informasi ini untuk memutuskan apakah suatu operasi menggunakan terlalu banyak memori dan perlu disesuaikan agar penggunaannya lebih sedikit.

  1. Berinteraksilah dengan aplikasi Anda, dan dalam monitor Memory, tampilkan memori Free dan Alloated.
  2. Klik Dump Java Heap .
  3. Di tab Captures, klik-ganda file cuplikan heap untuk membuka penampil HPROF.
  4. Untuk melakukan alokasi heap, berinteraksilah dengan aplikasi Anda dan klik Initiate GC .

Teruslah berinteraksi dengan aplikasi Anda dan mulai GC. Amati pembaruan alokasi heap Anda dengan masing-masing GC. Identifikasi tindakan apa dalam aplikasi yang menyebabkan terlalu banyak alokasi dan di mana Anda bisa mengurangi alokasi dan membebaskan sumber daya.

Menganalisis heap dump

Heap dump disediakan dalam format yang serupa, namun tidak sama, dengan salah satu format dari alat bantu HFPROF Java. Perbedaan utama dalam heap dump Android adalah ada banyak alokasi dalam proses Zygote. Karena alokasi Zygote dibagikan di seluruh proses aplikasi, mereka tidak terlalu berpengaruh pada analisis heap Anda sendiri.

Untuk menganalisis heap dump, Anda bisa menggunakan alat bantu standar seperti jhat. Untuk menggunakan jhat, Anda harus mengonversi file HPROF dari format Android ke format HPROF Java SE. Untuk mengonversi format HPROF Java SE, gunakan alat bantu hprof-conv yang tersedia di direktori ANDROID_SDK/platform-tools/. Jalankan perintah hprof-conv dengan dua argumen: file HPROF asli dan lokasi untuk menuliskan file HPROF yang dikonversi. Misalnya:

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

Anda bisa memuat file yang dikonversi ke dalam alat bantu analisis heap yang memahami format HPROF Java SE. Selama analisis, carilah kebocoran memori yang disebabkan oleh salah satu hal berikut:

  • Referensi berumur-panjang ke Activity, Context, View, Drawable, dan objek lain yang mungkin memiliki referensi ke kontainer Activity atau Context.
  • Kelas dalam non-statis, seperti Runnable, yang bisa menyimpan sebuah instance Activity.
  • Cache yang menyimpan objek lebih lama dari yang diperlukan.

Melacak alokasi memori

Melacak alokasi memori bisa memberikan pemahaman yang lebih baik kepada Anda tentang di mana objek boros-memori dialokasikan. Anda bisa menggunakan Pelacak Alokasi untuk melihat penggunaan memori tertentu dan menganalisis jalur kode krusial dalam aplikasi seperti menggulir.

Misalnya, Anda mungkin menggunakan Pelacak Alokasi untuk melacak alokasi saat Anda melempar sebuah daftar ke dalam aplikasi. Pelacakan memungkinkan Anda melihat semua alokasi memori yang diperlukan untuk melemparkan daftar, thread yang mengalokasikan memori, dan dari mana asal alokasi memori tersebut. Jenis informasi ini bisa membantu Anda menyederhanakan jalur eksekusi untuk mengurangi beban pekerjaan yang dilakukan, yang dapat meningkatkan operasi aplikasi dan antarmuka pengguna secara keseluruhan.

Meskipun tidak diperlukan atau bahkan mustahil untuk membuang semua alokasi memori dari jalur kode krusial-kinerja, Pelacak Alokasi bisa membantu Anda mengidentifikasi masalah penting dalam kode Anda. Misalnya, sebuah aplikasi mungkin membuat objek Paint yang baru setiap kali menggambar. Membuat objek Paint menjadi global adalah penyelesaian sederhana yang membantu meningkatkan kinerja.

  1. Jalankan aplikasi Anda pada perangkat atau emulator yang terhubung.
  2. Dalam Android Studio, pilih View > Tool Windows > Android Monitor.
  3. Di sudut kiri atas Android Monitor, pilih tab Monitors.
  4. Dalam bilah alat Memory Monitor, klik Allocation Tracker untuk memulai alokasi memori.
  5. Gunakan aplikasi.
  6. Klik Allocation Tracker lagi untuk menghentikan pelacakan alokasi.

    Android Studio membuat file alokasi dengan nama file application-id_yyyy.mm.dd_hh.mm.alloc, buka file di Android Studio, dan tambahkan file ke daftar Allocations dalam tab Captures.

  7. Dalam file alokasi, identifikasi tindakan dalam aplikasi yang mungkin menyebabkan alokasi terlalu banyak dan tetapkan area aplikasi yang harus Anda coba kurangi alokasinya dan membebaskan sumber dayanya.

Untuk informasi selengkapnya tentang Pelacak Alokasi, lihat Pelacak Alokasi.

Menampilkan alokasi memori secara keseluruhan

Untuk analisis lebih jauh, Anda mungkin ingin melihat bagaimana memori aplikasi dibagi dalam berbagai jenis alokasi RAM dengan perintah adb berikut:

adb shell dumpsys meminfo <package_name|pid> [-d]

Tanda -d mencetak lebih banyak informasi terkait dengan penggunaan memori Dalvik dan ART.

Keluaran mencantumkan semua alokasi aplikasi Anda saat ini, diukur dalam kilobyte.

Ketika memeriksa informasi ini, Anda harus familier dengan jenis alokasi berikut:

RAM Privat (Bersih dan Kotor)
Ini adalah memori yang sedang digunakan hanya oleh proses Anda. RAM dalam jumlah besar bisa diperoleh kembali di sini oleh sistem ketika proses aplikasi Anda ditutup. Biasanya, bagian terpenting dari RAM ini adalah RAM kotor privat, paling krusial karena digunakan hanya oleh proses Anda dan materinya hanya ada dalam RAM sehingga tidak bisa dikeluarkan ke penyimpanan (karena Android tidak menggunakan swap). Semua alokasi heap native dan Dalvik yang Anda buat akan menjadi RAM kotor privat; alokasi native dan Dalvik yang Anda bagikan dengan proses Zygote akan berbagi RAM kotor.
Proportional Set Size (PSS)
Ini adalah pengukuran penggunaan RAM oleh aplikasi Anda dengan memperhitungkan berbagi laman di seluruh proses. Setiap laman RAM unik untuk proses Anda secara langsung berkontribusi terhadap nilai PSS-nya, sedangkan laman yang dibagikan dengan proses lain hanya berkontribusi terhadap nilai PSS sesuai dengan jumlah yang dibagikan. Misalnya, laman yang dibagikan untuk dua proses akan berkontribusi setengah dari ukurannya terhadap PSS masing-masing proses.

Karakteristik yang baik dari pengukuran PSS adalah bahwa Anda bisa menambahkan PSS ke seluruh proses untuk menentukan memori sebenarnya yang sedang digunakan oleh semua proses. Ini berarti PSS bisa dipakai sebagai pengukuran yang baik untuk beban RAM sebenarnya dari suatu proses dan sebagai perbandingan terhadap penggunaan RAM proses lain serta total RAM yang tersedia.

Misalnya, di bawah ini adalah keluaran untuk proses Maps pada perangkat Nexus 5. Ada banyak informasi di sini, namun poin utama untuk dibahas tercantum di bawah ini.

adb shell dumpsys meminfo com.google.android.apps.maps -d

Catatan: Informasi yang Anda lihat mungkin sedikit berbeda dari apa yang ditampilkan di sini, karena beberapa detail keluaran bisa berbeda pada berbagai versi platform.

** MEMINFO in pid 18227 [com.google.android.apps.maps] **
                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap    10468    10408        0        0    20480    14462     6017
  Dalvik Heap    34340    33816        0        0    62436    53883     8553
 Dalvik Other      972      972        0        0
        Stack     1144     1144        0        0
      Gfx dev    35300    35300        0        0
    Other dev        5        0        4        0
     .so mmap     1943      504      188        0
    .apk mmap      598        0      136        0
    .ttf mmap      134        0       68        0
    .dex mmap     3908        0     3904        0
    .oat mmap     1344        0       56        0
    .art mmap     2037     1784       28        0
   Other mmap       30        4        0        0
   EGL mtrack    73072    73072        0        0
    GL mtrack    51044    51044        0        0
      Unknown      185      184        0        0
        TOTAL   216524   208232     4384        0    82916    68345    14570

 Dalvik Details
        .Heap     6568     6568        0        0
         .LOS    24771    24404        0        0
          .GC      500      500        0        0
    .JITCache      428      428        0        0
      .Zygote     1093      936        0        0
   .NonMoving     1908     1908        0        0
 .IndirectRef       44       44        0        0

 Objects
               Views:       90         ViewRootImpl:        1
         AppContexts:        4           Activities:        1
              Assets:        2        AssetManagers:        2
       Local Binders:       21        Proxy Binders:       28
       Parcel memory:       18         Parcel count:       74
    Death Recipients:        2      OpenSSL Sockets:        2

Berikut adalah dumpsys lama pada Dalvik dari aplikasi gmail:

** MEMINFO in pid 9953 [com.google.android.gm] **
                 Pss     Pss  Shared Private  Shared Private    Heap    Heap    Heap
               Total   Clean   Dirty   Dirty   Clean   Clean    Size   Alloc    Free
              ------  ------  ------  ------  ------  ------  ------  ------  ------
  Native Heap      0       0       0       0       0       0    7800    7637(6)  126
  Dalvik Heap   5110(3)    0    4136    4988(3)    0       0    9168    8958(6)  210
 Dalvik Other   2850       0    2684    2772       0       0
        Stack     36       0       8      36       0       0
       Cursor    136       0       0     136       0       0
       Ashmem     12       0      28       0       0       0
    Other dev    380       0      24     376       0       4
     .so mmap   5443(5) 1996    2584    2664(5) 5788    1996(5)
    .apk mmap    235      32       0       0    1252      32
    .ttf mmap     36      12       0       0      88      12
    .dex mmap   3019(5) 2148       0       0    8936    2148(5)
   Other mmap    107       0       8       8     324      68
      Unknown   6994(4)    0     252    6992(4)    0       0
        TOTAL  24358(1) 4188    9724   17972(2)16388    4260(2)16968   16595     336

 Objects
               Views:    426         ViewRootImpl:        3(8)
         AppContexts:      6(7)        Activities:        2(7)
              Assets:      2        AssetManagers:        2
       Local Binders:     64        Proxy Binders:       34
    Death Recipients:      0
     OpenSSL Sockets:      1

 SQL
         MEMORY_USED:   1739
  PAGECACHE_OVERFLOW:   1164          MALLOC_SIZE:       62

Secara umum, perhatikan hanya kolom Pss Total dan Private Dirty. Dalam beberapa kejadian, kolom Private Clean dan Heap Alloc juga menawarkan data yang menarik. Informasi selengkapnya tentang alokasi memori (baris) berbeda yang harus Anda amati mengikuti:

Dalvik Heap
RAM yang digunakan oleh alokasi Dalvik dalam aplikasi Anda. Pss Total Menyertakan semua alokasi Zygote (yang ditimbang dengan pembagian lintas proses mereka, seperti yang dijelaskan dalam definisi PSS di atas). Angka Private Dirty adalah RAM sebenarnya yang diperuntukkan hanya untuk heap aplikasi, yang terdiri dari alokasi Anda sendiri dan semua laman alokasi Zygote yang telah dimodifikasi sejak membagi proses aplikasi dari Zygote.

Catatan: Pada versi platform lebih baru yang memiliki bagian Dalvik Other, nomor Pss Total dan Private Dirty Dalvik Heap tidak menyertakan overhead Dalvik seperti kompilasi just-in-time (JIT) dan pembukuan GC, sedangkan versi lama menggabungkan semuanya di bawah Dalvik.

Heap Alloc adalah jumlah memori yang selalu dilacak Dalvik dan peng-alokasi heap native dari aplikasi Anda. Nilai ini lebih besar dari Pss Total dan Private Dirty karena proses Anda telah dikeluarkan dari Zygote dan menyertakan alokasi yang dibagikan proses Anda dengan aplikasi lainnya.

.so mmap dan .dex mmap
RAM sedang digunakan oleh .so yang dipetakan (native) dan kode .dex (Dalvik atau ART). Jumlah Pss Total mencakup kode platform yang dibagikan ke seluruh aplikasi; Private Clean adalah kode aplikasi Anda sendiri. Biasanya, ukuran yang dipetakan sebenarnya jauh lebih besar—RAM di sini hanyalah apa yang saat ini diperlukan dalam RAM untuk kode yang telah dieksekusi oleh aplikasi tersebut. Akan tetapi, .so mmap memiliki private dirty yang besar, hal ini karena perbaikan kode asli saat dimuat ke alamat akhirnya.
.oat mmap
Ini adalah jumlah RAM yang digunakan oleh gambar kode berdasarkan kelas pramuat yang biasanya digunakan oleh beberapa aplikasi. Gambar ini dibagikan ke semua aplikasi dan tidak terpengaruh oleh aplikasi tertentu.
.art mmap
Ini adalah jumlah RAM yang digunakan oleh gambar heap berdasarkan kelas pramuat yang biasanya digunakan oleh beberapa aplikasi. Gambar ini dibagikan ke semua aplikasi dan tidak terpengaruh oleh aplikasi tertentu. Meskipun gambar ART mengandung instance Object, ini tidak diperhitungkan terhadap ukuran heap Anda.
.Heap (hanya dengan tanda -d)
Ini adalah jumlah memori heap untuk aplikasi Anda. Ini mengecualikan objek dalam gambar dan ruang objek besar, namun menyertakan ruang zygote dan ruang tak-berpindah.
.LOS (hanya dengan tanda -d)
Ini adalah jumlah RAM yang digunakan oleh ruang objek besar ART. Ini menyertakan objek besar zygote. Objek besar adalah semua alokasi larik primitif yang lebih besar dari 12KB.
.GC (hanya dengan tanda -d)
Ini adalah jumlah GC internal yang memperhitungkan overhead untuk aplikasi Anda. Tidak ada cara untuk mengurangi overhead ini.
.JITCache (hanya dengan tanda -d)
Ini adalah jumlah memori yang digunakan oleh data JIT dan cache kode. Biasanya, bernilai nol karena semua aplikasi akan dikompilasi saat dipasang.
.Zygote (hanya dengan tanda -d)
Ini adalah jumlah memori yang digunakan oleh ruang zygote. Ruang zygote dibuat selama startup perangkat dan belum pernah dialokasikan.
.NonMoving (hanya dengan tanda -d)
Ini adalah jumlah RAM yang digunakan oleh ruang tak-berpindah ART. Ruang tak-berpindah berisi objek tak dapat dipindahkan khusus seperti bidang dan metode. Anda bisa mengurangi bagian ini dengan menggunakan lebih sedikit bidang dan metode dalam aplikasi.
.IndirectRef (hanya dengan tanda -d)
Ini adalah jumlah RAM yang digunakan oleh tabel referensi tak langsung ART. Biasanya berjumlah kecil, namun jika terlalu tinggi, bisa dikurangi dengan mengurangi jumlah referensi JNI lokal dan global yang digunakan.
Unknown
Semua laman RAM yang tidak bisa diklasifikasikan sistem ke dalam salah satu dari item yang lebih spesifik. Sekarang, ini kebanyakan berisi alokasi native, yang tidak bisa diidentifikasi dengan alat bantu saat mengumpulkan data karena Address Space Layout Randomization (ASLR). Seperti halnya heap Dalvik, Pss Total untuk Unknown memperhitungkan pembagian bersama Zygote, dan Private Dirty adalah RAM tak diketahui yang didedikasikan khusus untuk aplikasi Anda.
TOTAL
Total RAM Proportional Set Size (PSS) yang digunakan oleh proses Anda. Ini adalah jumlah semua bidang PSS di atasnya. Ini menunjukkan beban memori dari proses secara keseluruhan, yang bisa dibandingkan secara langsung dengan proses lainnya dan total RAM yang tersedia.

Private Dirty dan Private Clean adalah alokasi total dalam proses Anda, yang tidak dibagikan dengan proses lain. Bersama-sama (khususnya Private Dirty), ini adalah jumlah RAM yang akan dilepaskan kembali ke sistem ketika proses ditutup. RAM kotor adalah laman yang telah diubah sehingga harus selalu menggunakan RAM (karena tidak ada swap); RAM bersih adalah laman yang telah dipetakan dari file tetap (seperti kode yang sedang dijalankan) sehingga bisa dilepaskan jika tidak digunakan untuk sementara waktu.

ViewRootImpl
Jumlah tampilan akar yang aktif dalam proses Anda. Setiap tampilan akar dihubungkan dengan sebuah jendela, sehingga ini bisa membantu Anda mengidentifikasi kebocoran memori yang melibatkan dialog atau jendela lain.
AppContexts dan Activities
Jumlah objek Context dan Activity aplikasi yang saat ini sedang aktif dalam proses Anda. Ini bisa membantu Anda dengan cepat mengidentifikasi objek Activity bocor yang tidak dapat dilakukan pengumpulan sampah karena terdapat referensi statis, yang biasa terjadi. Objek ini sering kali memiliki banyak alokasi lain yang terkait dengannya, yang menjadikan ini sebuah cara yang baik untuk melacak kebocoran memori yang besar.

Catatan: Objek View atau Drawable juga memiliki referensi ke Activity yang menjadi tempat asalnya, jadi memiliki objek View atau Drawable juga bisa menyebabkan aplikasi Anda membocorkan Activity.

Pemicu kebocoran memori

Saat menggunakan alat yang dijelaskan di atas, Anda harus secara agresif menekan kode aplikasi Anda dan mencoba memaksa kebocoran memori. Satu cara untuk menyebabkan kebocoran memori di aplikasi adalah dengan membiarkannya berjalan untuk sementara waktu sebelum memeriksa heap. Kebocoran akan menetes ke bagian atas alokasi dalam heap tersebut. Namun, semakin kecil kebocoran, semakin lama Anda harus menjalankan aplikasi untuk melihatnya.

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

  1. Putar perangkat beberapa kali dari potret ke lanskap dan kembali lagi saat dalam keadaan aktivitas yang berbeda. Memutar perangkat sering kali bisa menyebabkan aplikasi membocorkan objek Activity, Context, atau View karena sistem membuat kembali Activity dan jika aplikasi Anda memiliki referensi ke salah satu objek tersebut di tempat lain, sistem tidak dapat melakukan pengumpulan sampah di situ.
  2. Beralihlah antar aplikasi Anda dan aplikasi lain saat dalam keadaan aktivitas berbeda (arahkan ke layar Utama, lalu kembali ke aplikasi).

Tip: Anda juga bisa melakukan langkah-langkah di atas dengan menggunakan kerangka kerja pengujian monkey. Untuk informasi selengkapnya tentang menjalankan kerangka kerja pengujian monkey, baca dokumentasi monkeyrunner.