onStop — ocultación de Activity en el ciclo de vida de Android

¿Qué es onStop en Android?

onStop — un método callback de la clase AppCompatActivity (y su predecesor Activity), llamado por el sistema operativo Android cuando la Activity deja de ser completamente visible para el usuario. En este momento, la Activity está oculta por otra Activity, una ventana de diálogo, el lanzador del sistema o la pantalla de bloqueo. Desde la perspectiva del ciclo de vida, onStop sigue a onPause e indica que la Activity ya no es visible en la pantalla, aunque el objeto Activity y su estado permanecen en la memoria.

Cuando la Activity pasa al estado Stopped (detenida), conserva su estado en la memoria RAM — todos los campos, la jerarquía de vistas y la ViewModel siguen siendo accesibles. Esto distingue Stopped del estado Destroyed (destruido), donde la Activity se elimina por completo. La interfaz de sistema puede eliminar el proceso de la aplicación en estado Stopped cuando falta memoria — esto se conoce como process death (muerte del proceso). El desarrollador debe guardar los datos críticos (borradores, posición de desplazamiento) en onSaveInstanceState(), que se llama antes de onStop, para garantizar la restauración en caso de muerte del proceso.

Según el Documento de Definición de Compatibilidad de Android (CDD) para la versión 14+, un proceso en estado Stopped tiene una prioridad reducida para ser eliminado por OOM Killer — menor que los procesos en fase Background, pero mayor que los procesos en caché. Según las estadísticas de Google, el 68% de los casos de muerte de procesos ocurren cuando la Activity está en estado Stopped, no en Paused.

¿Cuándo se llama a onStop?: escenarios y orden

onStop se llama cuando la Activity pierde completamente la visibilidad, independientemente de la razón: iniciar una nueva Activity sobre la actual, minimizar la aplicación (presionar Inicio), bloquear la pantalla, una llamada entrante o abrir un diálogo del sistema. En todos estos casos, la Activity primero recibe onPause (pérdida parcial del foco) y luego onStop (pérdida total de visibilidad).

Escenarios principales de llamada a onStop:

• Iniciar una nueva Activity sobre la actual — la Activity actual recibe onPause, luego onStop; la nueva Activity pasa por onCreate → onStart → onResume.
• Minimizar la aplicación (Inicio) — la Activity pasa a onPause → onStop en 200–300 ms, permanece en memoria en estado Stopped.
• Bloquear la pantalla — el sistema llama a onPause → onStop porque la pantalla de bloqueo cubre completamente la Activity.
• Llamada entrante — la aplicación de teléfono (Dialer) se inicia encima, la Activity actual pasa a onStop.
• Cambiar a otra aplicación (Recientes) — la Activity se oculta, recibe onStop, pero permanece en la memoria caché de procesos.

Es importante entender que onStop no se llama al rotar la pantalla — en este caso, la Activity se destruye (onPause → onStop → onDestroy) y se recrea (onCreate → onStart → onResume). La excepción es la bandera android:configChanges="orientation" en el manifiesto, que evita la recreación de la Activity y en su lugar llama a onConfigurationChanged().

onStop en el ciclo de vida de Activity

onStop ocupa un lugar central en la secuencia del ciclo de vida de Activity entre el estado visible e invisible. La secuencia completa: onCreate → onStart → onResume → (estado activo) → onPause → onStop → onDestroy (o onRestart → onStart → onResume al regresar).

*En el estado Stopped, la Activity se conserva en memoria, pero puede ser eliminada por el sistema cuando faltan recursos. La prioridad de eliminación de procesos Stopped es la penúltima, solo por encima de los procesos vacíos en caché.

onStop y onSaveInstanceState: El sistema llama a onSaveInstanceState(Bundle) antes de onStop para guardar el estado dinámico de la interfaz. El desarrollador sobrescribe este método para guardar en el Bundle los valores de los campos de entrada, la posición del RecyclerView y los elementos seleccionados. Incluso si la Activity no se destruye (el usuario simplemente minimizó y regresó), el Bundle se pasa a onCreate en cambios de configuración. Google recomienda guardar solo el estado transitorio de la interfaz — no los datos del repositorio o ViewModel, que viven fuera de la Activity.

Qué recursos liberar en onStop

En onStop, el desarrollador debe liberar todos los recursos que no son necesarios cuando la Activity no es visible. Esto reduce la carga de la batería, la CPU y la memoria, y también previene ANR al regresar a la actividad.

Qué liberar en onStop:

• Animaciones y transiciones — detener ObjectAnimator, ValueAnimator, ViewPropertyAnimator. Las animaciones en ejecución en una Activity invisible desperdician ciclos de GPU.
• Sensores — cancelar la suscripción de SensorManager (acelerómetro, giróscopo, magnetómetro). Los sensores consumen energía incluso cuando la Activity está oculta.
• Cámara y micrófono — liberar Camera2 o CameraX, detener MediaRecorder. Dejar la cámara activa con la Activity oculta está prohibido por la política de Google Play.
• LocationListener — cancelar la suscripción de FusedLocationProviderClient o LocationManager. La geolocalización es el recurso que más energía consume.
• Listeners de red — cerrar WebSocket, cancelar solicitudes HTTP que no son necesarias en segundo plano.
• MediaPlayer y ExoPlayer — pausar o detener la reproducción si no debe continuar en segundo plano.

Qué no hacer en onStop: No realice operaciones largas — guardar grandes cantidades de datos en la base de datos, solicitudes de red, cálculos complejos. onStop se ejecuta en el hilo principal y bloquea el regreso a la Activity. Para operaciones largas, use WorkManager con retardo o corrutinas en viewModelScope. No libere recursos de ViewModel — ViewModel sobrevive a onStop y se usará al regresar.

Diferencia entre onStop y onPause

onPause y onStop se diferencian en el grado de pérdida de visibilidad y el alcance de las acciones obligatorias. onPause se llama al perder parcialmente el foco (por ejemplo, al abrir una ventana de diálogo o un menú del sistema), onStop — al perder completamente la visibilidad. Esta diferencia es importante para elegir qué recursos liberar en cada etapa.

Regla general: en onPause, libere los recursos del sistema que inmediatamente afectan la experiencia del usuario de otra aplicación (cámara, reproductor multimedia); en onStop — todos los demás recursos que no son necesarios cuando la Activity está oculta. Google recomienda guardar los datos críticos del usuario (borrador de correo, configuraciones) en onPause, ya que onStop puede no llamarse durante un cambio rápido.

onStop → onRestart: volver a la pantalla

Cuando el usuario regresa a una Activity oculta, el sistema llama a onRestart → onStart → onResume. El método onRestart señala que la Activity está regresando del estado Stopped. Esta es una etapa importante para restaurar la interfaz y los recursos que se liberaron en onStop.

Secuencia de llamadas al regresar:

• onRestart() — la Activity es notificada de que se mostrará nuevamente. Acciones típicas: recargar datos, actualizar listas.
• onStart() — la Activity se vuelve visible pero aún no activa. Aquí se reinicializan los recursos liberados en onStop.
• onResume() — la Activity obtiene el foco y está lista para la interacción. Se inician las animaciones, se registran los sensores.

Si el proceso de la aplicación fue eliminado por el sistema en estado Stopped, se llama a onCreate en lugar de onRestart, y el Bundle de onSaveInstanceState se pasa para restaurar el estado. Este escenario (process death) es una de las causas más comunes de errores en aplicaciones Android: los desarrolladores implementan onRestart pero olvidan considerar la restauración a través de onCreate después de la muerte del proceso.

Ejemplos de código con onStop en Kotlin

Ejemplo 1: Implementación básica de onStop con liberación de sensores

Demuestra la cancelación correcta de la suscripción a sensores y la detención de animaciones al ocultar la Activity. Al regresar a la pantalla, los recursos se restauran en onStart.

class MainActivity : AppCompatActivity() {
    private lateinit var sensorManager: SensorManager
    private var accelerometer: Sensor? = null
    private var rotationAnimator: ObjectAnimator? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
        accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    }

    override fun onStart() {
        super.onStart()
        accelerometer?.let {
            sensorManager.registerListener(sensorListener, it, SensorManager.SENSOR_DELAY_NORMAL)
        }
        rotationAnimator = ObjectAnimator.ofFloat(findViewById(R.id.icon), "rotation", 0f, 360f)
        rotationAnimator?.apply {
            duration = 3000
            repeatMode = ValueAnimator.RESTART
            repeatCount = ValueAnimator.INFINITE
            start()
        }
    }

    override fun onStop() {
        super.onStop()
        sensorManager.unregisterListener(sensorListener)
        rotationAnimator?.cancel()
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("MainActivity", "Activity regresa del estado Stopped")
    }

    private val sensorListener = SensorEventListener { event, _ ->
        Log.d("MainActivity", "Acel: x=${event.values[0]}, y=${event.values[1]}, z=${event.values[2]}")
    }
}

El código registra el sensor de acelerómetro e inicia una animación de rotación infinita en onStart. En onStop, el sensor se desregistra y la animación se cancela — esto evita el consumo de batería cuando la Activity está oculta. Después de regresar mediante onRestart → onStart, los recursos se recrean.

Ejemplo 2: onStop con conservación de estado mediante SavedStateHandle

Un enfoque moderno que usa ViewModel + SavedStateHandle. Los datos del formulario se guardan automáticamente durante onStop sin necesidad de manejar Bundle manualmente.

class FormViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    var email: String
        get() = savedStateHandle["email"] ?: ""
        set(value) { savedStateHandle["email"] = value }

    var message: String
        get() = savedStateHandle["message"] ?: ""
        set(value) { savedStateHandle["message"] = value }
}

class FormActivity : AppCompatActivity() {
    private val viewModel: FormViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_form)
        Log.d("FormActivity", "onCreate: email=${viewModel.email}")
    }

    override fun onStop() {
        super.onStop()
        Log.d("FormActivity", "onStop: datos guardados en SavedStateHandle")
    }
}

SavedStateHandle guarda automáticamente los valores en el Bundle durante onSaveInstanceState, que se llama antes de onStop. Al rotar la pantalla o en caso de muerte del proceso, los datos se restauran sin pérdida. Google recomienda SavedStateHandle para formularios y borradores en lugar de onSaveInstanceState directo.

Ejemplo 3: lifecycleScope para operaciones en onStop

Uso de lifecycleScope con corrutinas para guardar datos de forma asíncrona durante la transición a onStop. La corrutina se ejecuta en el despachador IO sin bloquear el hilo principal.

class NoteActivity : AppCompatActivity() {
    private val noteRepository = NoteRepository()

    override fun onStop() {
        lifecycleScope.launch(Dispatchers.IO) {
            val text = findViewById<EditText>(R.id.note_content).text.toString()
            noteRepository.saveDraft(text)
            withContext(Dispatchers.Main) {
                Log.d("NoteActivity", "Borrador guardado en onStop")
            }
        }
        super.onStop()
    }
}

La corrutina lifecycleScope.launch se cancela automáticamente si el ciclo de vida de la Activity finaliza. El uso de Dispatchers.IO garantiza que la escritura en la base de datos o en un archivo no bloquee el regreso a la Activity. Según Google, las corrutinas en lifecycleScope son la forma preferida de realizar operaciones asíncronas en onStop.