LifecycleOwner — qué es, interfaz Jetpack y suscripción a eventos

¿Qué es LifecycleOwner?

LifecycleOwner es una interfaz del paquete androidx.lifecycle que contiene un único método getLifecycle(), que devuelve un objeto Lifecycle. Este objeto rastrea el estado actual del componente (CREATED, STARTED, RESUMED, DESTROYED) y notifica a todos los observadores suscritos cuando cambia. LifecycleOwner forma parte de Architecture Components y se incluye en la librería lifecycle-runtime.

El objetivo principal de la interfaz es estandarizar el acceso al ciclo de vida. Antes de Jetpack, los desarrolladores se suscribían manualmente en onStart y se desuscribían en onStop, lo que provocaba duplicación de código y errores. LifecycleOwner resuelve este problema proporcionando un mecanismo unificado para todos los componentes de Android. En lugar de llamar explícitamente a los métodos del ciclo de vida, el desarrollador se suscribe a Lifecycle una vez y las notificaciones llegan automáticamente.

La interfaz se declara en Kotlin como una interfaz funcional con un único método abstracto:

interface LifecycleOwner {
    val lifecycle: Lifecycle
}

Gracias a la naturaleza funcional de la interfaz, es fácil de implementar mediante un delegado o lambda. Esto es especialmente útil para crear Custom Views y clases ViewModel que deben reaccionar a los cambios en el ciclo de vida del anfitrión. El objeto Lifecycle obtenido de getLifecycle() proporciona los métodos addObserver y removeObserver para gestionar las suscripciones.

Cómo funciona LifecycleOwner

LifecycleOwner funciona en conjunto con dos clases clave: Lifecycle y LifecycleObserver. Lifecycle almacena el estado actual del componente como un enum State (INITIALIZED, CREATED, STARTED, RESUMED, DESTROYED) y rastrea las transiciones entre ellos. Cuando el estado cambia, Lifecycle notifica a todos los observadores registrados llamando a los métodos anotados correspondientes. Este mecanismo se llama “lifecycle-aware” — el código se ejecuta solo cuando el componente está en un estado adecuado.

El mecanismo de entrega de eventos se basa en el patrón Observer. LifecycleOwner actúa como Observable y la implementación de LifecycleObserver como Observer. Cuando Activity o Fragment cambia su estado (onCreate → onStart → onResume → onPause → onStop → onDestroy), notifica a Lifecycle a través del mecanismo interno ReportFragment, que se añade automáticamente al sistema AndroidX. El desarrollador no necesita llamar manualmente a los métodos de Lifecycle — todo sucede automáticamente.

Un detalle importante: Lifecycle garantiza que los eventos ON_STOP y ON_DESTROY se entreguen incluso en caso de cierre inesperado del proceso. Esto convierte a LifecycleOwner en una herramienta fiable para liberar recursos críticos. Para la conservación regular del estado, se recomienda usar SavedStateHandle en ViewModel, pero LifecycleOwner proporciona un nivel básico de seguridad.

LifecycleObserver y DefaultLifecycleObserver

Hay dos formas de suscribirse a los eventos de LifecycleOwner: el clásico LifecycleObserver con anotaciones y el moderno DefaultLifecycleObserver con métodos explícitos. Google recomienda el segundo enfoque desde 2022, ya que proporciona mejor seguridad de tipos y evita la reflexión utilizada en el enfoque basado en anotaciones. DefaultLifecycleObserver requiere Java 8+ o Kotlin y es la opción preferida para nuevos proyectos.

Ejemplo de suscripción mediante DefaultLifecycleObserver:

class MyObserver : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        // Iniciar seguimiento GPS solo cuando el componente esté activo
        startLocationUpdates()
    }

    override fun onStop(owner: LifecycleOwner) {
        // Detención segura al pasar a segundo plano
        stopLocationUpdates()
    }
}

// Conexión:
lifecycleOwner.lifecycle.addObserver(MyObserver())

Cada método de DefaultLifecycleObserver recibe un LifecycleOwner como parámetro. Esto permite al observador acceder al contexto del componente en ejecución sin necesidad de pasarlo por separado. Este enfoque hace que el código sea más modular y comprobable — el Observer no depende de la implementación específica de Activity o Fragment, sino que trabaja con la abstracción LifecycleOwner.

Enfoque basado en anotaciones LifecycleObserver

El método antiguo que utiliza la anotación @OnLifecycleEvent todavía se encuentra en proyectos heredados, pero no se recomienda su uso para código nuevo. La reflexión necesaria para procesar las anotaciones añade sobrecarga y puede provocar errores que no se detectan en tiempo de compilación. Google recomienda oficialmente migrar a DefaultLifecycleObserver.

// Enfoque obsoleto — no recomendado para proyectos nuevos
class MyLegacyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        startLocationUpdates()
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun onStop() {
        stopLocationUpdates()
    }
}

El enfoque basado en anotaciones tiene un inconveniente significativo: falta de control sobre el ciclo de vida del Observer. Si el desarrollador olvida desuscribir al Observer cuando se destruye LifecycleOwner, el objeto Observer permanece en la memoria hasta que el recolector de basura actúe. DefaultLifecycleObserver resuelve este problema — el Observer está vinculado al Lifecycle y se desuscribe automáticamente al pasar al estado DESTROYED.

LifecycleOwner en Activity y Fragment

Desde AppCompat 1.1.0 y AndroidX Fragment 1.2.0, todas las Activities y Fragments que heredan de AppCompatActivity o Fragment son automáticamente LifecycleOwners. Esto significa que el método getLifecycle() está disponible por defecto y la suscripción a eventos del ciclo de vida funciona sin configuración adicional. El desarrollador simplemente llama a lifecycle.addObserver() desde cualquier lugar de Activity o Fragment.

Veamos un ejemplo de integración de LifecycleOwner en una Activity:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        lifecycle.addObserver(LocationObserver(this))
    }
}

En este ejemplo, lifecycle es una propiedad de extensión disponible gracias a AndroidX Activity. El LocationObserver recibirá automáticamente notificaciones sobre el inicio (ON_START) y la detención (ON_STOP) de la Activity. Al rotar la pantalla, el Observer es notificado de ON_DESTROY y luego de ON_CREATE, lo que permite manejar correctamente los cambios de configuración sin código adicional.

LifecycleOwner en Fragment

Fragment implementa LifecycleOwner a través de su interfaz, y su Lifecycle está vinculado al ciclo de vida del Fragment, no al de la Activity padre. Esto es importante: el Lifecycle del Fragment pasa a DESTROYED cuando el Fragment se elimina de la transacción, mientras que la Activity puede permanecer en RESUMED. Esta distinción permite que los Observers se suscriban por separado al ciclo de vida de cada componente.

class MyFragment : Fragment() {
    private val uiStateObserver = UiStateObserver()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        lifecycle.addObserver(uiStateObserver)
    }
}

Una ventaja importante de usar LifecycleOwner en Fragment es la desuscripción automática cuando el Fragment pasa a DESTROYED. Esto es especialmente relevante para ViewPager, donde los Fragments pueden crearse y destruirse dinámicamente. La gestión manual de suscripciones en este escenario sería extremadamente compleja y propensa a errores.

Crear un LifecycleOwner personalizado

La interfaz LifecycleOwner se puede implementar en cualquier clase que tenga un ciclo de vida. Esto es útil para Custom Views, Services e incluso ViewModel en algunas soluciones arquitectónicas. Google proporciona la clase auxiliar LifecycleRegistry, que gestiona el estado de Lifecycle y genera eventos. El desarrollador debe llamar manualmente a los métodos apropiados de LifecycleRegistry cuando cambie el estado del componente.

Ejemplo de implementación de LifecycleOwner en una Custom View:

class MyCustomView(
    context: Context,
    attrs: AttributeSet?
) : FrameLayout(context, attrs), LifecycleOwner {

    private val lifecycleRegistry = LifecycleRegistry(this)

    override val lifecycle: Lifecycle
        get() = lifecycleRegistry

    fun onStart() {
        lifecycleRegistry.setCurrentState(Lifecycle.State.STARTED)
    }

    fun onStop() {
        lifecycleRegistry.setCurrentState(Lifecycle.State.CREATED)
    }
}

En este ejemplo, LifecycleRegistry actúa como almacén de estado. Los métodos onStart/onStop deben ser llamados por el componente padre (por ejemplo, Activity) cuando la Custom View se vuelve visible o se oculta. LifecycleRegistry calcula automáticamente los eventos necesarios para la transición entre estados y notifica a todos los Observers suscritos.

Al implementar un LifecycleOwner personalizado, es importante seguir la regla: el estado de LifecycleRegistry debe actualizarse al final en el método de ciclo de vida correspondiente, después de todas las demás operaciones. Esto garantiza que los Observers reciban la notificación cuando el componente ya esté completamente listo para el nuevo estado. Usar LifecycleRegistry.createUnsafe como alternativa también es posible, pero requiere precaución con los hilos.

LifecycleOwner en componentes Jetpack

LifecycleOwner es la base de varios componentes clave de Android Jetpack. LiveData utiliza LifecycleOwner para determinar el estado activo y desuscribirse automáticamente cuando el componente se destruye. ViewModel no implementa LifecycleOwner directamente, pero puede recibir Lifecycle a través de SavedStateHandle. Navigation Component utiliza LifecycleOwner para gestionar suscripciones en NavBackStackEntry. Comprender esta relación ayuda a construir la arquitectura de la aplicación sobre una base sólida.

Interacción de LiveData con LifecycleOwner:

class ExampleActivity : AppCompatActivity() {
    private val viewModel: ExampleViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        viewModel.userData.observe(this) { data ->
            // this — LifecycleOwner (Activity)
            // El código se ejecuta solo cuando la Activity está en estado RESUMED
            updateUI(data)
        }
    }
}

LiveData requiere un LifecycleOwner en el método observe() porque garantiza que las actualizaciones de la interfaz de usuario solo ocurran en el estado activo. Si la Activity está en segundo plano, LiveData conserva el último valor pero no notifica al Observer. Al volver a RESUMED, el Observer recibe el valor actual sin necesidad de solicitudes adicionales a la red o la base de datos.

DataBinding también utiliza LifecycleOwner para vincular campos observables al ciclo de vida de Activity o Fragment. Esto ayuda a evitar fugas de memoria en la combinación ViewModel + DataBinding — todas las suscripciones se limpian automáticamente cuando se destruye LifecycleOwner. Este enfoque hace que el código sea declarativo y seguro.

Mejores prácticas

El uso correcto de LifecycleOwner requiere seguir varias reglas clave. La primera y más importante: suscríbase siempre al Observer en onCreate/onViewCreated, no más tarde. Esto garantiza que el Observer reciba el estado inicial de Lifecycle (CREATED después de onCreate) y no se pierda eventos. La segunda regla: use DefaultLifecycleObserver en lugar del enfoque basado en anotaciones para todos los proyectos nuevos.

• No almacene una referencia a LifecycleOwner en campos estáticos o singletons — esto provoca fugas de toda la Activity
• Verifique el estado de Lifecycle mediante getCurrentState() antes de realizar operaciones sensibles al estado
• No cree Observers dentro de lambdas — cada recomposición crea un nuevo objeto y los Observers antiguos no se desuscribirán automáticamente
• Use repeatOnLifecycle para corrutinas — el bloque se inicia al entrar en el estado especificado y se cancela al salir de él
• No llame a setCurrentState en LifecycleRegistry desde un hilo secundario — esto viola la garantía de un solo hilo del ciclo de vida

El enfoque moderno para trabajar con corrutinas y LifecycleOwner es la extensión repeatOnLifecycle:

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.flow.collect { value ->
            updateUI(value)
        }
    }
}

Este patrón garantiza que collect en Flow esté activo solo en el estado STARTED o RESUMED. Al pasar a STOPPED, la colección se cancela automáticamente y al volver a STARTED se reinicia. repeatOnLifecycle reemplaza la desuscripción manual de Flow en Fragments y es el enfoque recomendado por Google para trabajar con flujos de datos asincrónicos en componentes de UI.

Otra recomendación importante: no abuse de LifecycleObserver para lógica no relacionada con el ciclo de vida. Si un componente necesita realizar una acción en un estado específico pero no requiere desuscripción al destruirse, es mejor usar llamadas explícitas a métodos en onStart/onStop. LifecycleObserver está justificado para componentes de larga duración (LocationListener, SensorManager) donde la gestión manual de suscripciones es compleja y propensa a errores.