El ciclo de vida de una Activity: seis puertas y un contrato

Todo el que llega a Android recibe el mismo diagrama con seis cajas y flechas, lo memoriza y sigue adelante creyendo que ya lo entendió. Casi siempre lo entendió mal, porque el diagrama sugiere una escalera de métodos que se llaman en orden y lo que realmente describe es otra cosa: un canal por el que el sistema operativo te informa, en tiempo real, de cuánta atención del usuario tiene tu pantalla ahora mismo. Tu app no decide cuándo se ejecuta ninguno de esos métodos. Los ejecuta Android en respuesta a hechos que ocurren fuera de tu programa: una llamada entrante, un usuario que gira el dispositivo, otra app que reclama la mitad de la pantalla, un sistema al que se le acaba la memoria. Aprender el ciclo de vida no es aprender seis nombres, es aceptar un reparto de poder.

Estados que duran, callbacks que solo avisan

La primera corrección de modelo mental es esta: Lifecycle expone un estado, no una secuencia. Los valores son INITIALIZED, CREATED, STARTED, RESUMED y DESTROYED, y en cualquier instante tu Activity está exactamente en uno de ellos, que puedes consultar con lifecycle.currentState. Los callbacks que tanto se memorizan no son el estado: son los eventos que se emiten al cruzar de un estado al siguiente. onStart no es un lugar donde tu app vive, es un aviso momentáneo de que acaba de pasar de CREATED a STARTED.

Esta distinción parece pedante hasta que produce el primer bug. Un componente que se suscribe en onStart y se desuscribe en onStop funciona porque los eventos vienen emparejados. Un componente que se registra tarde, después de que el evento ya pasó, jamás recibe el aviso y se queda esperando eternamente algo que no volverá. Por eso las librerías modernas no te dejan escuchar eventos sueltos: te dejan preguntar por el estado actual con lifecycle.currentState y te entregan la transición con un observador que se pone al día en el momento de registrarse. La API que ves como una lista de métodos es, por debajo, una máquina de estados con memoria.

class DetalleActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent { Pantalla() }        // el arbol de UI se declara una sola vez
    }

    override fun onStart() { super.onStart() }      // ya se ve, aun sin foco
    override fun onResume() { super.onResume() }    // tiene el foco de entrada
    override fun onPause() { super.onPause() }      // pierde el foco, puede seguir visible
    override fun onStop() { super.onStop() }        // deja de verse por completo
    override fun onDestroy() { super.onDestroy() }  // puede no llegar nunca
}

Falta un séptimo nombre que rompe la simetría aparente y suele desconcertar: onRestart. No corresponde a ninguna transición nueva, solo distingue la primera subida a visible de las siguientes. Se ejecuta cuando una pantalla que ya estuvo parada vuelve al frente, justo antes de su onStart, y su única utilidad legítima es refrescar datos que pudieron quedarse obsoletos mientras nadie miraba. En una app moderna, donde los datos llegan como flujos observables que ya se reactivan solos, casi nunca hace falta escribirlo.

La forma profesional de trabajar con todo esto, sin embargo, no es sobrescribir métodos sino registrar observadores. Sobrescribir obliga a que la lógica de cada componente viva dentro de la Activity y a que alguien recuerde llamarlo desde los seis sitios; observar deja que cada componente se ate a sí mismo y sobreviva a cualquier refactorización de la pantalla que lo aloja.

class ReproductorConCiclo(propietario: LifecycleOwner) : DefaultLifecycleObserver {

    init { propietario.lifecycle.addObserver(this) }   // se pone al dia al registrarse

    override fun onStart(propietario: LifecycleOwner) = reanudar()
    override fun onStop(propietario: LifecycleOwner) = pausar()
}

// consultar el estado en cualquier momento, sin depender de haber visto el evento
val puedeMostrar = lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)

flowchart TD
A[Creada tras onCreate] --> B[Visible tras onStart]
B --> C[Con foco tras onResume]
C -->|otra ventana reclama el foco| D[onPause y sigue visible]
D -->|recupera el foco| C
D -->|queda tapada del todo| E[onStop y deja de verse]
E -->|el usuario regresa| F[onRestart y luego onStart]
F --> B
E -->|finish o cambio de configuracion| H[onDestroy]
E -->|el sistema recicla el proceso| G[No se ejecuta nada mas]
style G fill:#f38ba8,color:#11111b
style C fill:#a6e3a1,color:#11111b

Los tres pares y el recurso que gobierna cada uno

Los seis callbacks son en realidad tres pares simétricos, y la simetría no es estética sino operativa: cada recurso que adquieras en una puerta ascendente debe liberarse en su gemela descendente, sin excepciones y sin atajos. onCreate y onDestroy acotan la existencia de la instancia y por tanto la construcción de todo lo que dura tanto como ella. onStart y onStop acotan la visibilidad, es decir, el intervalo en que lo que hagas puede llegar a los ojos de alguien. onResume y onPause acotan el foco de entrada, el intervalo en que las pulsaciones y el teclado se dirigen a ti.

De ahí se deduce dónde va cada cosa sin necesidad de tablas. Un sensor cuya lectura solo tiene sentido si se muestra pertenece al par de visibilidad. Una cámara, que es un recurso exclusivo del sistema y solo puede tenerla una ventana a la vez, pertenece al par del foco en dispositivos con multiventana, porque una app visible pero sin foco debe cederla. La recolección de un flujo que alimenta píxeles pertenece a la visibilidad, no al foco, y esa decisión es tan importante que la última lección del nivel entera va sobre ella.

class MapaActivity : ComponentActivity() {

    private lateinit var sensores: SensorManager

    override fun onStart() {
        super.onStart()
        sensores.registerListener(oyente, brujula, SensorManager.SENSOR_DELAY_UI)
    }

    override fun onStop() {
        super.onStop()
        sensores.unregisterListener(oyente)   // gemelo exacto: sin esto, fuga garantizada
    }
}

La disciplina tiene una consecuencia que conviene decir en voz alta: si tu código de adquisición y el de liberación no están en callbacks emparejados, tienes un bug latente aunque la app funcione hoy. Registrar en onCreate y desregistrar en onStop deja un oyente vivo la segunda vez que la pantalla vuelve al frente, porque onCreate no se repite pero onStop sí. Registrar en onResume y desregistrar en onStop duplica la suscripción cada vez que el usuario abre y cierra un diálogo del sistema. Ninguno de esos errores produce un fallo inmediato; producen consumo de batería que nadie sabe atribuir.

Lo que no se hace en cada puerta

onCreate es el sitio donde más daño se hace, porque todo lo que escribas ahí se ejecuta antes de que el usuario vea el primer fotograma. Cualquier lectura de disco, cualquier consulta a base de datos, cualquier inicialización de librería pesada se convierte directamente en tiempo de arranque percibido y, si se pasa de unos pocos segundos, en un cierre por no responder. La regla operativa es que onCreate solo declara: instala el árbol de interfaz, pide el ViewModel, conecta la inyección de dependencias, y delega todo lo que tarde a una corrutina o a una carga perezosa.

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

    // mal: lectura de disco en el hilo principal antes del primer fotograma
    val ajustes = leerAjustesDeDisco()

    // bien: se declara la pantalla y el trabajo se delega
    setContent { Pantalla() }
}

onStart tiene un peligro más discreto: es el callback que más veces se ejecuta a lo largo de la vida de una pantalla, porque cada vuelta desde el escritorio, cada regreso de otra app y cada cierre de una pantalla superior pasan por él. Lo que pongas ahí debe ser barato y, sobre todo, idempotente. Una petición de red colocada en onStart se dispara cada vez que el usuario mira el reloj y vuelve, y esa clase de derroche no aparece en ningún perfil de rendimiento porque cada llamada individual es perfectamente razonable.

onResume sufre el mismo problema amplificado, ya que también se ejecuta al cerrar cualquier diálogo del sistema, incluido el de permisos. Un patrón que se ve con frecuencia y que hay que evitar es comprobar el permiso y pedirlo desde onResume: como la propia petición hace pasar la pantalla por onPause y luego otra vez por onResume, se construye un bucle que solo se rompe si el usuario acepta.

onPause es el segundo sitio donde más daño se hace, por una razón que casi nadie conoce: mientras tu onPause no retorne, la siguiente pantalla no puede recibir su onResume. Es decir, todo lo que hagas ahí se lo cobra el usuario como retraso al navegar. Persistir datos en onPause es una costumbre heredada de una época en la que era el último callback garantizado; desde hace muchas versiones no lo es, y el lugar correcto para guardar es onStop, que ya ocurre con la pantalla oculta y no bloquea ninguna transición visible.

onDestroy cierra el catálogo con la advertencia más importante de la lección: no está garantizado. Si el sistema decide reciclar tu proceso porque necesita memoria, lo mata sin ceremonia y ningún callback tuyo se ejecuta. Todo lo que pongas ahí es limpieza de buena voluntad, útil para el caso ordenado, inútil para el caso que de verdad importa. Cualquier promesa que deba cumplirse pase lo que pase no pertenece a onDestroy, sino a un mecanismo que sobreviva a tu proceso.

El foco dejó de ser la visibilidad

Durante los primeros años de Android, perder el foco y dejar de verse eran prácticamente lo mismo: solo había una app en pantalla y onPause era una señal fiable de que ya nadie miraba. El multiventana rompió esa equivalencia para siempre. Hoy tu Activity puede estar en STARTED y perfectamente visible en media pantalla mientras el usuario teclea en la otra mitad, y en esa situación tu onPause ya se ejecutó. Si detuviste el vídeo, vaciaste la lista o paraste la animación en onPause, el usuario ve una pantalla congelada que sí está mirando.

El cambio no fue gratuito para la plataforma. Durante años, el contrato decía que solo una actividad podía estar en RESUMED en todo el sistema, y muchas apps se apoyaron en esa exclusividad para gestionar recursos únicos. Con el multiventana, las versiones modernas permiten que varias actividades estén simultáneamente enfocadas en dispositivos que lo declaran, de modo que ni siquiera el foco garantiza ya la exclusividad. Lo único que queda garantizado es que solo una ventana recibe la entrada del teclado en cada momento, y cualquier recurso realmente exclusivo debe adquirirse comprobando y cediéndose ante el fallo, nunca asumiendo que el ciclo de vida lo reserva para ti.

La conclusión práctica es una regla que conviene grabar: el umbral para todo lo que produce píxeles es STARTED, no RESUMED. Se detiene cuando se deja de ver, no cuando se pierde el foco. RESUMED queda reservado para lo que depende de la entrada del usuario o de recursos exclusivos que solo una ventana puede tener a la vez. Esta única distinción explica por qué las APIs modernas que verás en la última lección hablan de repetir el trabajo mientras el ciclo esté al menos en STARTED y no mencionan el foco en ningún sitio.