# Fragments, ViewBinding and memory leaks

DevFeed: [Fragments, ViewBinding and memory leaks](<https://devfeed.tech/articles/fragments-viewbinding-and-memory-leaks-25871.md>)

Original publisher: [Read original article](<http://lordraydenmk.github.io//2020/view-binding/>)

Author: Stojan Anastasov

Published: 2020-10-30T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stojan Anastasov's blog](<https://devfeed.tech/sources/stojan-anastasov-s-blog.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Memory Leaks](<https://devfeed.tech/topics/memory-leaks.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-android-extensions](<https://devfeed.tech/tags/kotlin-android-extensions.md>), [memory-leak](<https://devfeed.tech/tags/memory-leak.md>), [memory-leaks](<https://devfeed.tech/tags/memory-leaks.md>), [view-binding](<https://devfeed.tech/tags/view-binding.md>)

## AI overview

This article explains how Android view binding works with Kotlin and Java, focusing on the risk of memory leaks when a Fragment retains a binding after its view is destroyed. It argues that the issue results from placing the binding reference in the Fragment scope and recommends keeping it in a shorter-lived local function scope, particularly when using MVVM.

## Source excerpt

As an Android engineer one of the basic things you need to do is bind the views (written in XML) with Kotlin/Java code. You can do this with the basic primitive -findViewById(), using a library like ButterKnife, using a compiler plugin like Kotlin Android Extensions or starting with Android Studio/AGP 3.6 ViewBinding. There are a few other options out there but in my experience these are the most common. The Kotlin Android Extensions plugin will be deprecated (except the @Parcelize functionality) in favor of ViewBinding soon. I see this as a positive change, but not everyone shares my opinion. One of the common arguments against ViewBinding (according to a comment in the ticket, a discussion on reddit and a friend of mine) is: ViewBinding introduces memory leaks in Fragments. Let's take a look into the usage example from the official docs: private var _binding: ResultProfileBinding? = null // This property is only valid between onCreateView and // onDestroyView. private val binding get() = _binding!! override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View? { _binding = ResultProfileBinding.inflate(inflater, container, false) val view = binding.root return view } override fun onDestroyView() { super.onDestroyView() _binding = null } The fragment outlives the view, which means that if we forget to clear the binding reference in onDestroyView this will cause a memory leak. Now I do agree that this is error prone, you have to remember to clear the binding reference in each fragment you create. However this problem is not inherent to ViewBinding, but to this kind of usage. The problem here is: a component with a larger scope (the fragment) keeps a reference to a component with a smaller scope (the binding). Clearing the reference is a workaround, the proper solution is to move the reference to the correct scope: private val viewModel by viewModels<ProfileViewModel>() override fun onViewCreated(view: View, savedInsta