Dapatkah komponen Arch navigasi membuat kebocoran memori positif palsu?


14

Saya memiliki pengetahuan dasar tentang kebocoran memori dan apa yang dapat menyebabkannya. Itu sebabnya saya tidak mengerti jika saya memiliki masalah dalam kode saya atau itu positif palsu. Saya tidak tahu bagian mana dari kode yang harus saya bagikan karena proyeknya tidak kecil. Tapi beri tahu saya di komentar dan saya akan menambahkan kode yang diperlukan.

Saya menggunakan komponen lengkung navigasi dan mengikuti pola MVVM. Saya menambahkan perpustakaan LeakCanary kemudian dalam pengembangan proyek dan segera mulai memberi saya peringatan tentang contoh yang disimpan ketika saya menavigasi antara layar.

Masalahnya terjadi ketika saya menambahkan fragmen ke tumpukan belakang. Dengan setiap fragmen yang ditambahkan ke tumpukan belakang penghitung contoh dipertahankan meningkat. Ketika mencapai nilai ambang 5 LeakCanary, dump heap dan memberikan laporan.

Tetapi jika saya mengklik tombol kembali dan kembali ke layar sebelumnya maka counter dari contoh yang disimpan menurun dan akhirnya, ketika kembali ke layar 1 semua contoh yang disimpan menghilang.

Jika saya melihat laporan analisis tumpukan itu mengatakan bahwa variabel coordinatorLayout yang merupakan referensi ke CoordinatorLayoutdalam xml telah bocor. Jika saya menghapus variabel dan semua penggunaannya dan menjalankan aplikasi lagi saya melihat masalah yang sama, tetapi sekarang dengan variabel lain yang merupakan referensi ke tampilan lain di xml. Saya mencoba untuk menghapus semua tampilan dan penggunaannya yang dilaporkan LeakCanary bocor. Ketika dikatakan bahwa TextView, yang hanya digunakan untuk mengatur teks onViewCreateddan tidak digunakan di tempat lain, bocor saya mulai ragu bahwa ada masalah dalam kode saya.

Saya menganalisis panggilan metode siklus hidup dalam fragmen dan memperhatikan bahwa ketika saya menavigasi ke layar baru untuk fragmen sebelumnya semua metode sampai dan termasuk onDestroyViewdipanggil tetapi tidak onDestroy. Ketika saya mengklik kembali onDestroydipanggil untuk fragmen yang berada di atas tumpukan kembali dan disimpan contoh penghitung menurun.

Saya menduga bahwa komponen Navigasi menyimpan instance dari fragmen ketika berada di tumpukan belakang dan LeakCanary melihatnya sebagai kebocoran.

Jawaban:


24

Begitulah cara kerja Fragmen di tumpukan belakang (dan Navigasi hanya menggunakan API Fragmen yang ada): tampilan Fragmen dihancurkan, tetapi Fragmen itu sendiri tidak dihancurkan - mereka disimpan dalam CREATEDkeadaan sampai Anda menekan tombol kembali dan kembali ke Fragmen. (setelah itu onCreateView()akan dipanggil lagi dan Anda akan naik kembali ke RESUMED).

Sesuai dengan Fragmen: Masa Lalu, Sekarang, dan Masa Depan , salah satu perubahan di masa depan yang datang ke Fragmen adalah pilihan untuk menghancurkan Fragmen di tumpukan belakang, daripada memiliki dua siklus hidup yang terpisah. Ini belum tersedia sampai sekarang.

Anda harus membatalkan referensi Anda ke tampilan onDestroyViewkarena itulah tanda bahwa tampilan tidak lagi digunakan oleh sistem Fragmen dan itu bisa dengan aman dikumpulkan oleh sampah jika bukan karena Anda melanjutkan referensi ke Tampilan.


2
Apakah Android View Binding mengatasi masalah ini? Saya tidak dapat menemukan dokumentasi tentang apakah referensi untuk tampilan Binding Lihat (mungkin objek yang mengikat itu sendiri) secara otomatis 'dibatalkan' onDestroyViewdengan View Binding.
Tim Malseed

3
@TimMalseed - Anda harus menghapus sendiri referensi Anda ke objek yang mengikat, tidak ada yang otomatis terjadi.
ianhanniballake

1
@ Emmanuel - Anda perlu menjatuhkan referensi Anda ke objek yang mengikat itu sendiri karena yang memegang referensi sulit untuk Views yang dimilikinya.
ianhanniballake

1
@ Emmanuel - Anda selalu dapat mengajukan permintaan fitur !
ianhanniballake

1
@ Emmanuel - Saya pikir itu pasti akan menjadi perubahan perilaku (yang mungkin menyiratkan itu menjadi pilihan terpisah dalam flag), tetapi memiliki LifecycleOwner yang benar akan menjadi informasi yang cukup untuk memperbaikinya untuk menyelesaikan seluruh masalah memori.
ianhanniballake
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.