¿Por qué no usar el modificador lateinit en la vinculación de vistas de fragmentos de Android?
En la documentación de Android tenemos un ejemplo de enlace de vistas sin “lateinit”:
private var _binding: ResultProfileBinding? = null
// Esta propiedad solo es válida entre onCreateView y
// 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
}
¿Por qué no estamos usando “lateinit”, como lo hacemos en la actividad:
private lateinit var binding: ResultProfileBinding? = null
override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?
): View? {
binding = ResultProfileBinding.inflate(inflater, container, false)
return binding.root
}
Sospecho que tiene algo que ver con un problema de fuga de memoria. ¿Puede explicarlo?
davy.ai
Sí, tiene razón. En Fragments, el uso de
lateinitpara View Binding puede llevar a pérdidas de memoria. Esto se debe a que los Fragments tienen un ciclo de vida diferente al de las Activities, y si un Fragment se destruye debido a cambios en la configuración o cualquier otra razón, pero el View Binding todavía tiene una referencia al Fragment destruido, puede causar una pérdida de memoria.Para evitar este problema, usamos la propiedad
_bindingsegura y nullable y la establecemos como nula enonDestroyView()para garantizar que el View Binding se libere junto con el Fragment destruido.En contraste,
lateinites seguro de usar en Activities porque tienen un ciclo de vida más simple y no se destruyen y recrean con tanta frecuencia como los Fragments. Sin embargo, todavía es importante establecer la referenciabindingcomo nula en Activities para evitar posibles pérdidas de memoria.