Saltar a contenido

Ciclo de vida de una Activity

Ciclo de vida de una Activity

A lo largo de su vida útil, una Activity pasa por varios estados y el sistema invoca métodos de devolución de llamada (callbacks) en cada transición. Conocerlos te permite inicializar, persistir y liberar recursos correctamente.

Callbacks principales

onCreate()

  • Cuándo: al crear la Activity por primera vez.
  • Qué hacer:
  • Inicializar la interfaz de usuario con setContentView().
  • Configurar vistas, adaptadores o datos iniciales.
  • Qué evitar: operaciones largas en el hilo principal.
  • Siguiente: siempre se ejecuta onStart().

onStart()

  • Cuándo: la Activity pasa a ser visible.
  • Qué hacer: últimos ajustes antes de que el usuario interactúe (registrar listeners, animaciones ligeras).
  • Siguiente: onResume().

onResume()

  • Cuándo: la Activity está en primer plano y el usuario puede interactuar.
  • Qué hacer: reanudar lógica principal (cámara, sensores, animaciones, reproducción multimedia).
  • Qué evitar: operaciones de guardado persistente o llamadas de red.
  • Siguiente: siempre se ejecuta onPause().

onPause()

  • Cuándo: la Activity pierde el foco (otra Activity encima, diálogo, multitarea).
  • Qué hacer: pausar recursos costosos (animaciones pesadas, cámara, sensores).
  • Qué evitar: guardar datos de forma persistente, operaciones de red o base de datos (no hay garantías de tiempo).
  • Siguiente: puede ir a onResume() (si vuelve al frente) o onStop().

onStop()

  • Cuándo: la Activity deja de ser visible.
  • Qué hacer: guardar estado persistente, cancelar suscripciones y liberar recursos no visibles.
  • Siguiente: onRestart() (si vuelve al usuario) o onDestroy().

onRestart()

  • Cuándo: la Activity estaba detenida y vuelve a iniciarse.
  • Qué hacer: restaurar el estado previo, volver a configurar recursos necesarios.
  • Siguiente: siempre onStart().

onDestroy()

  • Cuándo: justo antes de que la Activity sea eliminada.
  • Qué hacer: liberar todos los recursos restantes (listeners, hilos, ejecutores).
  • Nota: no siempre se invoca si el sistema mata el proceso abruptamente.

Tabla: Ciclo de vida de una Activity

Callback Estado / Contexto Qué hacer Qué evitar
onCreate Creación inicial setContentView, inicializar IU, dependencias Tareas pesadas en el hilo principal
onStart Visible (no interactiva aún) Registrar listeners livianos Trabajo de larga duración
onResume Primer plano (interactiva) Reanudar cámara, sensores, animaciones críticas Persistencia o I/O de red
onPause Pierde foco (parcialmente visible) Pausar recursos costosos Guardado persistente, I/O bloqueante
onStop No visible Guardar estado, liberar recursos no visibles Mantener recursos que ya no se usan
onRestart Regresa desde onStop Reconfigurar para volver a primer plano
onDestroy Antes de eliminarse Limpieza total (hilos, ejecutores, receptores) Confiar en que siempre se llamará

Diagrama ciclo de vida

flowchart LR
  A[onCreate] --> B[onStart] --> C[onResume]
  C -->|pierde foco| D[onPause]
  D -->|se vuelve visible otra vez| C
  D -->|ya no es visible| E[onStop]
  E -->|regresa| F[onRestart] --> B
  E -->|finaliza| G[onDestroy]

Buenas prácticas y errores comunes

  • Persistencia: guarda preferencias/estado ligero en onStop(), no en onPause().
  • Rendimiento: evita bloqueos en UI; usa coroutines o WorkManager para trabajo en background.
  • Recursos exclusivos (cámara, micrófono, sensores): adquiérelos en onResume() y libéralos en onPause().
  • Navegación: maneja retornos y recomposición de IU pensando en recreaciones (cambios de orientación, multiwindow).
  • Evita fugas: desuscribe observadores/listeners en onStop()/onDestroy() según el caso.

Conservar el estado de una aplicación

El usuario espera que el estado de la IU se conserve en situaciones como:

  • Rotación de pantalla.
  • Cambio a modo multiventana.
  • Salida temporal de la app para abrir otra.

El problema

El sistema finaliza la Activity por defecto en estas situaciones, y se pierde el estado de la interfaz.

Estrategias para conservar el estado

  • onSaveInstanceState(Bundle)

    • Callback que guarda datos simples y ligeros (Strings, números…).
    • Los guarda en un Bundle de pares clave-valor.
    • El sistema restaura automáticamente datos de las Views con android:id.
  • ViewModel

    • Mantiene datos de la IU aunque se destruya y recree la Activity.
    • Ideal para datos más complejos o pesados.
  • Almacenamiento local persistente

    • Para conservar datos que deben sobrevivir incluso si se mata el proceso.
    • Ejemplo: SharedPreferences, Base de datos.

Importante

Un Bundle no es adecuado para grandes cantidades de datos (consume memoria y requiere serialización en el hilo principal).

Estado de la instancia

  • Si la Activity se cierra voluntariamente (finish() o botón Atrás) → el estado se pierde y no se restaura.
  • Si la Activity se finaliza por el sistema (rotación, falta de memoria) → el sistema guarda el estado en un Bundle y crea una nueva instancia con esos datos cuando el usuario vuelve.

Las aplicaciones Android suelen entrar y salir de actividades varias veces durante su uso.
Ejemplo: abrir la app de correo desde la pantalla principal, o iniciar la cámara desde una app de chat.

Cómo iniciar una Activity desde otra

  • startActivity(Intent)

    • Inicia otra Activity sin esperar resultado.
    • Puede ser de la misma app o de otra (ej. abrir un email, compartir un archivo).
  • startActivityForResult(Intent, int)

    • Inicia otra Activity esperando un resultado.
    • Ejemplo: elegir un contacto y devolverlo a la Activity que lo pidió.
    • El resultado se recibe en onActivityResult(requestCode, resultCode, data).

Códigos de resultado

  • RESULT_OK → todo correcto.
  • RESULT_CANCELED → cancelado o error.
  • RESULT_FIRST_USER → códigos personalizados.

Coordinación entre Activities

Cuando una Activity inicia otra, ambas experimentan transiciones de ciclo de vida:

sequenceDiagram
    participant A as Activity A
    participant B as Activity B

    A->>B: onPause()
    Note over B: Válido para casos onCreate(), onStart(), onResume()
    B->>B: onCreate()
    Note over B: B ahora está en primer plano
    B->>A: onStop()
    Note over B: B sigue estando en primer plano

A tener en cuenta

Así, la primera Activity no se detiene por completo hasta que la segunda esté lista. Esto permite coordinar datos y transiciones de forma predecible.

Actividades

  • AC 201 (RA1 / CE1a / IC1 / 1p) Analiza de forma teórica el ciclo de vida de una Activity en Android y reflexiona sobre su importancia.

    Tareas a realizar

    • Analogía personal: Crea tu propia analogía comparando cada estado del ciclo de vida de una Activity con situaciones de la vida real (puede ser un día de clase, un viaje, un partido de fútbol…). Explica en 1–2 frases cada relación.
    • Preguntas de reflexión

      • ¿Qué podría pasar si una app no guardara la información al pasar de onPause a onStop?
      • ¿Por qué crees que Android no garantiza siempre que se llame a onDestroy?
      • ¿En qué se parecen onPause y onStop y en qué se diferencian?
      • ¿Por qué es importante diferenciar entre estar visible y estar interactiva?
    • Resumen final: Redacta en 5–6 líneas por qué crees que el ciclo de vida es fundamental para que una app funcione correctamente en móviles, donde los recursos son limitados y el usuario cambia de tareas con frecuencia.

  • AC 202 (RA1 / CE1a / IC1 / 1p) Reflexiona sobre la conservación del estado de una aplicación y la navegación entre Activities en Android.

    1. Escenario A: Imagina que estás escribiendo un correo electrónico en una app. En mitad de la redacción, giras el dispositivo (rotación de pantalla).

      • ¿Qué esperas que ocurra con el texto que estabas escribiendo?
      • ¿Qué sucedería si la app no guardara el estado correctamente?
      • ¿Por qué crees que el sistema destruye y recrea la Activity en una rotación?
    2. Escenario B: Imagina que en una app de mensajería seleccionas “Adjuntar foto”. La app abre la galería (otra Activity).

      • ¿Qué datos debe enviar la app de mensajería a la galería?
      • ¿Qué resultado debe devolver la galería a la app de mensajería?
      • ¿Qué ocurre con la primera Activity mientras la segunda está activa?
    3. Comparación

      • ¿En qué se parecen los problemas de conservar estado y navegación entre Activities?
      • ¿Cómo afectan ambos al usuario si no se implementan correctamente?