Mengelola dan mendiagnosis memori WebView

WebView menjalankan kode native di beberapa proses untuk merender konten web di aplikasi Android Anda. Jika instance WebView tidak dikelola, hal ini dapat menyebabkan kebocoran memori, error kehabisan memori (OOM), dan performa aplikasi yang menurun.

Dokumen ini menjelaskan model memori multi-proses WebView, menjelaskan cara mengelola siklus prosesnya dengan benar untuk mencegah kebocoran, dan memberikan alur kerja praktis untuk mendiagnosis masalah memori.

Memahami arsitektur memori WebView

Untuk mengelola memori WebView secara efektif, pahami cara Android mengalokasikan resource untuk konten web:

  • Eksekusi multi-proses: Di Android 8.0 (API level 26) dan yang lebih tinggi, WebView memisahkan konten web dari fungsi inti aplikasi Anda di beberapa proses (di perangkat dengan RAM rendah, aplikasi mungkin kembali ke satu proses):

    • Proses Host (Browser): Proses aplikasi utama tempat kode Activity dan Java atau Kotlin Anda berjalan.
    • Proses Renderer Terisolasi: Proses sandbox terpisah (SandboxedProcessService) yang mengurai HTML dan CSS, menjalankan JavaScript, dan merender halaman web.

  • Jejak memori native: Sebagian besar memori WebView, termasuk grafis yang dirender, pohon DOM, dan memori runtime JavaScript, dialokasikan dalam memori native, bukan di heap Java. Java heap dump (.hprof) hanya menampilkan objek wrapper Java ringan dan tidak menangkap memori sebenarnya yang digunakan oleh konten web.

  • Dampak sistem dari memori native: Tidak seperti alokasi heap Java, yang dibatasi oleh batas maxHeap aplikasi dan gagal dengan cepat dengan OutOfMemoryError, memori native dapat bertambah secara diam-diam hingga gigabyte. Saat memori native yang tidak dirilis mengisi RAM fisik dan ruang swap (zRAM), Low Memory Killer (LMK) Android mulai menghentikan proses latar belakang untuk mengklaim kembali memori. Hal ini menurunkan multitasking perangkat secara keseluruhan sebelum akhirnya menghentikan aplikasi latar depan.

Mengelola siklus proses WebView

Pengelolaan siklus proses yang tepat sangat penting untuk mencegah kebocoran memori. Kesalahan umum adalah menganggap bahwa menghapus WebView dari tata letak atau membiarkan Activity selesai secara otomatis akan mengosongkan memorinya.

Untuk memastikan pembersihan lengkap referensi konteks Java dan resource render native, Anda harus mengatur urutan penghancuran secara eksplisit dalam siklus proses komponen host (seperti onDestroy()), menghentikan eksekusi halaman aktif, melepaskan tampilan dari penampungnya, dan merilis binding native.

Membersihkan instance WebView

Untuk memastikan penonaktifan yang bersih dan merilis resource saat Activity atau Fragment Anda dihancurkan, lakukan hal berikut:

  1. Hapus WebView dari penampung induknya (ViewGroup).
  2. Hentikan pemuatan aktif dan hapus histori navigasi.
  3. Panggil destroy().
  4. Hapus referensi ke null.

Contoh berikut menunjukkan cara membersihkan WebView dengan benar:

Kotlin

override fun onDestroy() {
    myWebView?.let {
        // Remove the WebView from its parent ViewGroup.
        (it.parent as? ViewGroup)?.removeView(it)
        // Stop active loading and clear history.
        it.stopLoading()
        it.clearHistory()
        // Destroy the instance.
        it.destroy()
    }
    myWebView = null
    super.onDestroy()
}

Java

@Override
protected void onDestroy() {
    if (myWebView != null) {
        // Remove the WebView from its parent ViewGroup.
        if (myWebView.getParent() instanceof ViewGroup) {
            ((ViewGroup) myWebView.getParent()).removeView(myWebView);
        }
        // Stop active loading and clear history.
        myWebView.stopLoading();
        myWebView.clearHistory();
        // Destroy the instance.
        myWebView.destroy();
    }
    myWebView = null;
    super.onDestroy();
}

Memahami memori pasca-penghancuran

Saat Anda memanggil destroy(), sistem akan merilis konteks Activity, membersihkan hierarki tampilan, dan menghentikan pekerjaan latar belakang web. Namun, Anda mungkin mengamati bahwa memori fisik proses (Resident Set Size) tidak langsung turun ke baseline pra-WebView.

Hal ini normal terjadi. Cache runtime native, library bersama, dan halaman memori yang dialokasikan tetap berada dalam proses hingga sistem operasi mengklaimnya kembali atau proses dihentikan. Tujuan utama destroy() adalah mencegah kebocoran memori Activity kumulatif saat pengguna membuka dan menutup layar yang didukung web.

Metrik utama untuk proses debug

Saat menganalisis konsumsi memori WebView, fokuslah pada metrik berikut:

  • Resident Set Size (RSS): Total RAM fisik yang dipetakan ke dalam proses, termasuk kode dan library bersama (berlabel Total di Android Studio Profiler).

  • Anonymous RSS (RssAnon): Memori yang dialokasikan langsung oleh proses yang tidak didukung oleh file di disk (seperti heap native dan alokasi runtime JavaScript). Hal ini menunjukkan biaya memori utama konten web Anda (berlabel Dialokasikan di Android Studio Profiler).

  • Private Memory Footprint (PMF): Jumlah RSS Anonim dan swap (zRAM). PMF mencerminkan beban memori yang sebenarnya tidak dapat di-evict yang diterapkan aplikasi Anda pada sistem.

  • PMF Browser versus PMF Renderer: Memori yang digunakan oleh proses utama aplikasi Anda versus memori yang digunakan oleh proses renderer terisolasi. Konten web yang berat menyebabkan lonjakan terutama dalam proses renderer.

  • Jumlah Objek Live (WebViews, Activities, Views): Jumlah UI aktif, Konteks, dan instance WebView yang disimpan dalam memori. Melacak hal ini akan mengidentifikasi apakah pertumbuhan memori disebabkan oleh referensi Java yang dipertahankan atau alokasi khusus native.

  • Heap Native dan Private Other: Di dumpsys meminfo, alokasi C/C++ native dan pemetaan memori kustom (seperti Chromium PartitionAlloc atau heap runtime JavaScript yang disematkan) muncul di bagian Native Heap dan Private Other, bukan Java Heap.

Untuk mengetahui informasi selengkapnya tentang penghitung memori proses dan kategorinya, lihat Glosarium memori proses.

Alur kerja diagnostik praktis

Karena WebView beroperasi di beberapa proses dan mengalokasikan memori native, gunakan alat dan teknik berikut untuk memeriksa jejaknya:

Alat pembuatan profil dan diagnostik

Untuk memeriksa alokasi memori dan mendiagnosis kebocoran, gunakan alat berikut:

  • Android Studio Memory Profiler: Gunakan Memory Profiler untuk memvisualisasikan alokasi native, melacak kategori memori dari waktu ke waktu, dan mendeteksi Activity kebocoran di seluruh transisi layar.

  • Pelacakan memori dengan Perfetto: Gunakan Perfetto untuk merekam penghitung memori tingkat sistem (seperti RSS dan RSS Anonim) guna mengamati pertumbuhan memori secara keseluruhan. Perhatikan bahwa alokasi mesin native WebView tidak menghasilkan callstack di alat pembuatan profil heap Perfetto. Gunakan Chrome DevTools untuk memeriksa snapshot heap JavaScript dan alokasi DOM di dalam konten web.

Memeriksa jumlah objek live

Untuk menentukan apakah pertumbuhan memori disebabkan oleh objek framework Java yang dipertahankan (seperti komponen UI) atau alokasi native, periksa bagian Objects dari dumpsys meminfo:

adb shell dumpsys meminfo -a <var>PACKAGE_NAME</var> | grep -A 10 "Objects"

Output menampilkan jumlah objek live:

 Objects
               Views:     142         ViewRootImpl:        1
         AppContexts:       3           Activities:        1
              Assets:      12        AssetManagers:        0
       Local Binders:      32        Proxy Binders:       45
       Parcel memory:      15         Parcel count:       30
    Death Recipients:       2             WebViews:        1

Bagian ini menampilkan jumlah objek framework aktif, handle IPC, dan alokasi Parcel. Untuk WebView diagnostik, fokuslah terutama pada Activities dan WebViews.

Lakukan interaksi pengguna target (seperti membuka dan menutup layar web) berulang kali dan bandingkan jumlahnya:

  • Kebocoran instance: Jika WebViews atau Activities bertambah pada setiap navigasi dan tidak kembali ke baseline, aplikasi Anda mengalami kebocoran instance WebView Java atau Activity host (misalnya, karena ViewGroup.removeView() tidak ada atau referensi pemroses dipertahankan). Karena Activity yang bocor menyematkan seluruh pohon tampilan dan resource gambar yang didekodekan dalam memori, kunjungan berulang akan dengan cepat menghabiskan heap Java dan menyebabkan error OutOfMemoryError.

  • Kebocoran Native atau DOM: Jika WebViews dan Activities tetap konstan sementara RSS proses total dan Private Other terus meningkat, kebocoran berasal dari resource native yang tidak dirilis, elemen DOM, atau binding mesin JavaScript. Karena alokasi ini berada dalam memori native dan melewati pengumpul sampah ART, alokasi ini tetap tidak terlihat oleh alat deteksi kebocoran Java standar dan terus bertambah hingga sistem operasi menghentikan aplikasi.

Membuat profil proses renderer terisolasi menggunakan CLI

Menjalankan dumpsys meminfo dengan nama paket aplikasi Anda hanya akan menampilkan memori untuk proses host utama. Untuk memeriksa proses renderer terisolasi tempat halaman web dirender:

  1. Temukan ID proses (PID) layanan renderer terisolasi:

    adb shell dumpsys activity processes <var>PACKAGE_NAME</var> | grep "Isolated.*SandboxedProcessService"

    Output menampilkan catatan proses terisolasi dan PID-nya RENDERER_PID (misalnya, 22155):

    Isolated #5: ProcessRecord{... 22155:com.google.android.webview.debug:sandboxed_process0:...}

  2. Periksa perincian memori proses renderer menggunakan PID-nya:

    adb shell dumpsys meminfo <var>RENDERER_PID</var>

  3. Periksa proses aplikasi host untuk mengevaluasi jejak sisi browser:

    adb shell dumpsys meminfo <var>PACKAGE_NAME</var>

Memeriksa peta dan alokasi memori

Untuk melihat subsistem atau alokator native mana yang menempati memori anonim, periksa peta memori proses:

adb shell "cat /proc/$(pidof <var>PACKAGE_NAME</var>)/maps" | grep "anon:"

Tabel berikut mencantumkan tag memori anonim umum dan relevansinya dengan pertumbuhan memori:

Tag Memori Subsistem Relevansi dengan konten aplikasi dan web Penyebab umum peningkatan memori?
[anon:partition_alloc] Chromium PartitionAlloc Alokasi untuk pohon DOM, buffer rendering, heap JavaScript V8, dan eksekusi WebAssembly di WebView. Ya (Tinggi): Memuat halaman web yang berat, DOM kaya media, atau gagal memanggil destroy() pada instance WebView yang dibuang akan langsung meningkatkan tag ini.
[anon:scudo...] atau [anon:libc_malloc] Alokator heap native Android (Scudo / jemalloc) Alokasi native C/C++ umum yang digunakan oleh library NDK, bridge JNI, dan pipeline grafis native. Ya (Sedang hingga Tinggi): Pertumbuhan terjadi saat wrapper JNI native atau dependensi C++ pihak ketiga mempertahankan alokasi yang tidak dirilis di seluruh navigasi.
[anon:...] (misalnya, [anon:quickjs_heap...]) Runtime native atau pembuatan skrip kustom Mesin JavaScript yang disematkan, runtime WebAssembly kustom, atau kumpulan buffer native kustom. Ya (Bergantung pada konteks): Umum dalam aplikasi hybrid yang menjalankan mesin pembuatan skrip bersama tampilan native dan gagal membersihkan binding runtime.

Batasan API memori dalam aplikasi

API memori dalam aplikasi (seperti Debug.getMemoryInfo atau ActivityManager.getProcessMemoryInfo) hanya mengukur proses panggilan. Dalam mode multi-proses, API ini tidak dapat menangkap memori yang digunakan oleh proses renderer terisolasi. Untuk penilaian total memori yang akurat, gunakan alat sistem seperti dumpsys meminfo, Perfetto, atau Android Studio Profiler.

Menentukan prioritas memori tinggi dalam aplikasi hybrid

Saat mendiagnosis pertumbuhan memori yang tidak dapat dijelaskan selama interaksi WebView berulang (seperti membuka link web atau menavigasi feed yang didukung web), gunakan alur kerja penentuan prioritas berikut untuk mengisolasi apakah kebocoran berasal dari lapisan Java atau mesin native:

  1. Mengisolasi jenis kebocoran (Java versus native): Jalankan dumpsys meminfo -a <var>PACKAGE_NAME</var> | grep -A 10 "Objects" sebelum dan setelah transisi pengguna berulang (seperti membuka dan menutup artikel web atau menggeser feed).

    • Pengamatan: Jika Activities dan WebViews jumlah tetap stabil (misalnya, 1–2 instance aktif), aplikasi tidak mengalami kebocoran Activitykonteks atau instance WebView Java.

  2. Mengukur delta memori di seluruh interaksi (Pelacakan deret waktu): Ambil snapshot dumpsys meminfo di beberapa interaksi pengguna untuk menghitung rasio alokasi per transisi:

    • Pengamatan: Heap Java tetap dibatasi dan sehat (melonjak selama penggunaan dan menurun setelah pengumpulan sampah), tetapi Private Other dan Native Heap terus meningkat beberapa megabyte per transisi. Hal ini membuktikan bahwa kebocoran sepenuhnya berada dalam memori native di luar runtime ART. Java heap dump standar (.hprof) tidak akan menampilkan masalah apa pun.

  3. Memeriksa Peta Memori Anonim: Periksa peta memori proses menggunakan ADB (lihat Memeriksa peta dan alokasi memori):

    adb shell "cat /proc/$(pidof <var>PACKAGE_NAME</var>)/maps" | grep "anon:"
    • Pengamatan: Pertumbuhan memori terkonsentrasi di [anon:partition_alloc] atau heap mesin pembuatan skrip yang disematkan, disertai dengan peningkatan referensi global JNI yang lambat. Hal ini menunjukkan bahwa meskipun tampilan Java diganti, objek halaman native yang mendasarinya atau binding JavaScript tidak dirilis.

  4. Perbaikan:

    • Pastikan setiap WebView yang didaur ulang atau dibuang secara eksplisit menghentikan skrip aktif (stopLoading()), menghapus histori, dan memanggil destroy().
    • Hancurkan callback bridge JavaScript kustom atau referensi global JNI yang terkait dengan tampilan yang ditutup.
    • Konfirmasi bahwa Private Other dan RSS proses stabil setelah transisi navigasi.

Referensi lainnya

Untuk mempelajari lebih lanjut cara men-debug dan membuat profil memori serta performa WebView, lihat referensi berikut: