La muerte del proceso: por qué el sistema te mata y cómo provocarlo

Hay una frase que conviene decir sin rodeos porque cambia la forma de escribir código para siempre: en Android tu aplicación no termina, la terminan. No existe un cierre ordenado que puedas anticipar, no hay un aviso previo fiable, no se ejecuta ningún callback de despedida. Un día el usuario deja tu app para responder un mensaje, abre dos cosas más, el sistema necesita memoria, elige tu proceso porque es el candidato más barato, y lo elimina. Cuarenta minutos después el usuario vuelve, ve tu icono en la lista de recientes, lo toca esperando encontrar la pantalla donde lo dejó, y lo que ocurra en ese instante depende por completo de decisiones que tomaste al escribir el código.

Matar procesos es la optimización, no el fallo

La intuición traída del escritorio dice que un programa en segundo plano debería seguir ahí hasta que alguien lo cierre, y que matarlo es un síntoma de que algo va mal. En un dispositivo móvil la lógica se invierte. Arrancar un proceso desde cero es caro: hay que bifurcar desde el proceso plantilla del sistema, cargar clases, inicializar la aplicación, reconstruir la pantalla. Mantener vivo un proceso que ya hizo todo eso, aunque nadie lo esté usando, es la forma más barata que existe de que volver a la app sea instantáneo.

Hay además una razón de arquitectura que refuerza la decisión. Android no tiene memoria de intercambio en disco como un ordenador de escritorio: no existe un fichero donde volcar páginas de un proceso dormido para recuperarlas más tarde, entre otras cosas porque la memoria de estado sólido de un teléfono se desgasta con la escritura y porque la latencia arruinaría la sensación de fluidez. Sin intercambio, la única forma de liberar memoria es eliminar procesos enteros. Lo que en otros sistemas es una degradación gradual, aquí es necesariamente una decisión binaria sobre quién vive.

Por eso Android conserva procesos inactivos en caché mientras haya memoria libre, y por eso mismo tiene que poder eliminarlos sin contemplaciones cuando deja de haberla. Un teléfono con memoria libre no está desperdiciando nada solo si esa memoria libre se usa; la política óptima es llenarla de procesos en caché y desalojarlos por orden de menor valor cuando llegue una petición legítima. Tu proceso en segundo plano no es un ciudadano al que el sistema maltrata: es una entrada de caché que el sistema mantiene por cortesía y desaloja por necesidad.

Cómo se elige la víctima

El componente responsable es un vigilante de baja memoria que, en las versiones modernas, corre en espacio de usuario y observa las señales de presión de memoria del núcleo en lugar de esperar a que el sistema se ahogue. A cada proceso le corresponde una puntuación de ajuste que refleja su importancia según la categoría en la que esté, y cuando la presión supera un umbral se eliminan procesos empezando por la puntuación peor. Dentro de la misma categoría, el criterio de desempate suele ser el uso más antiguo y el consumo de memoria: un proceso en caché grande y viejo es el candidato ideal.

Antes de llegar al desalojo, el sistema ofrece un aviso intermedio que casi nadie aprovecha. A través de las llamadas de recorte de memoria, la plataforma informa a los procesos de que la presión está subiendo y les da la oportunidad de soltar lo que puedan reconstruir: cachés de imágenes, estructuras derivadas, buffers grandes. No es una despedida ni una garantía de nada, porque una caída brusca de memoria puede saltárselo por completo, pero un proceso que responde a esas señales adelgazando su huella se vuelve un candidato menos apetecible y sobrevive más tiempo en caché.

class App : Application(), ComponentCallbacks2 {
    override fun onTrimMemory(nivel: Int) {
        super.onTrimMemory(nivel)
        if (nivel >= TRIM_MEMORY_BACKGROUND) cacheDeImagenes.vaciar()
    }
}

Hay dos matices que conviene conocer porque cambian el comportamiento observado. El primero es que los procesos en caché de las versiones recientes se congelan, es decir, dejan de recibir tiempo de procesador por completo: no consumen batería mientras esperan, pero tampoco pueden reaccionar a nada. El segundo es que hay presiones que no vienen de la memoria sino de la política de energía, como los cubos de inactividad y el modo de reposo profundo, que no matan el proceso pero restringen tanto lo que puede hacer que el efecto práctico para tu trabajo pendiente es equivalente.

A esa lista hay que sumar una tercera fuente de muertes que no depende de la escasez sino de tu propio comportamiento. Un proceso que consume demasiada memoria puede superar el límite del montón asignado a su aplicación y morir por falta de memoria aunque el dispositivo tenga de sobra. Un servicio en primer plano que no muestra su notificación en el plazo debido se cierra. Un trabajo que excede su tiempo permitido se detiene. Y en muchos dispositivos existen capas del fabricante con políticas de ahorro más agresivas que las del sistema base, que cierran procesos con criterios propios y no documentados. Diseñar suponiendo únicamente el comportamiento del sistema puro es optimista.

Lo que muere y lo que no

Cuando el proceso desaparece se lleva absolutamente todo lo que vivía en memoria: instancias de Activity, cada ViewModel con su contenido, los objetos únicos del grafo de dependencias, las cachés, las corrutinas en vuelo, las propiedades de nivel superior. No queda nada y no se ejecuta ningún callback tuyo para despedirlas. Esta es la diferencia esencial con el cambio de configuración de la lección anterior: allí el ViewModel sobrevivía porque alguien lo pasaba de mano en mano dentro del mismo proceso; aquí no hay ninguna mano.

Conviene subrayar una consecuencia que rompe muchos diseños ingenuos. Un objeto único que guarda la sesión iniciada, el carrito de la compra o el usuario actual solo en memoria funciona impecablemente durante todo el desarrollo y desaparece en producción con una frecuencia que nadie sabe medir. El síntoma que llega al equipo no es un fallo sino un comentario difuso: que la app a veces pide iniciar sesión otra vez, que a veces se pierde lo que estaba haciendo. Detrás de ese a veces hay siempre el mismo suceso.

Lo que sí sobrevive vive fuera de tu proceso, en el sistema. La tarea, que es la pila de actividades que el usuario percibe como una app en la lista de recientes, la mantiene el gestor de actividades, y con ella conserva el estado de instancia guardado de cada actividad de la pila. Por eso al volver el usuario no aterriza en la pantalla inicial sino en la que dejó: el sistema arranca un proceso nuevo, recrea la actividad correcta y le entrega el paquete de datos que guardaste. También sobrevive, por definición, todo lo que escribiste en disco y todo lo que delegaste al sistema en forma de trabajo programado o alarma.

Esa última categoría explica una pregunta que aparece pronto y cuya respuesta parece burocrática hasta que se entiende: por qué existe un gestor de trabajo en segundo plano si una corrutina ya sabe hacer las cosas en otro hilo. La diferencia no está en la concurrencia sino en dónde vive la promesa. Una corrutina es memoria de tu proceso y desaparece con él; un trabajo programado es un registro que custodia el sistema, con sus condiciones y sus reintentos, y que sobrevive incluso al reinicio del dispositivo. Cualquier cosa que deba ocurrir aunque el usuario cierre la app pertenece al segundo mecanismo, y confundirlos produce sincronizaciones que funcionan en las pruebas y se pierden en producción.

// Muere con el proceso: valido solo mientras la pantalla exista
viewModelScope.launch { repo.sincronizar() }

// Sobrevive al proceso: la promesa la custodia el sistema
WorkManager.getInstance(contexto).enqueueUniqueWork(
    "sincronizacion",
    ExistingWorkPolicy.KEEP,
    OneTimeWorkRequestBuilder<SincronizarWorker>().build(),
)

flowchart TD
A[El usuario deja la app] --> B[El proceso pasa a estar en cache]
B --> C{Hace falta memoria}
C -->|no| D[El proceso sigue congelado y esperando]
C -->|si| E[El vigilante elige por puntuacion e importancia]
E --> F[Se elimina el proceso sin ejecutar callbacks]
F --> G[La tarea y el estado guardado siguen en el sistema]
G --> H[El usuario vuelve desde recientes]
H --> I[Proceso nuevo y Activity recreada con el estado guardado]
D --> H
style F fill:#f38ba8,color:#11111b
style G fill:#a6e3a1,color:#11111b

Provocarla a propósito, y los métodos que engañan

La distinción que invalida más pruebas de las que nadie sospecha es la que separa la muerte iniciada por el sistema de la parada iniciada por el usuario. Si el usuario desliza la app fuera de la lista de recientes o pulsa forzar detención en los ajustes, está expresando la voluntad de empezar de cero: el sistema descarta la tarea y el estado guardado, y la próxima apertura arranca limpia. Eso no es lo que quieres probar. El botón de detener de tu entorno de desarrollo hace exactamente eso, y por eso no sirve como simulación.

El procedimiento correcto es corto. Pon la app en segundo plano con el botón de inicio, no la cierres, y desde la terminal ejecuta la orden de matar el proceso; después vuelve a la app desde la lista de recientes. Esa orden solo actúa sobre procesos que el sistema podría haber matado por su cuenta, que es precisamente la garantía de fidelidad que buscas.

Hay dos condiciones que arruinan la prueba si se pasan por alto. La primera es tener el depurador conectado: mientras lo esté, el proceso recibe un trato distinto y algunas rutas de reciclado no se comportan igual, así que la comprobación seria se hace con la aplicación ejecutándose por su cuenta. La segunda es el orden de los pasos: si mandas la app al fondo y la matas antes de que el sistema haya terminado de guardar su estado, estás probando algo que en la práctica no ocurre. Espera un par de segundos tras salir y tendrás la secuencia realista.

adb shell am kill com.ejemplo.app          # simula la muerte del sistema
adb shell am kill-all                      # mata todos los procesos en segundo plano
adb shell dumpsys activity processes | head # ver la importancia actual de cada proceso

Hay una segunda vía, complementaria y muy útil para pruebas repetidas: limitar desde las opciones de desarrollador el número de procesos en segundo plano a cero. Con ese ajuste activo, salir de la app la convierte en candidata inmediata y el reciclado ocurre casi siempre, lo que permite recorrer toda la aplicación comprobando cada pantalla sin tener que lanzar una orden por cada prueba. Es agotador como modo de trabajo diario, pero es el mejor barrido que existe antes de una publicación.

La plataforma ofrece además una vía para saber, ya dentro del proceso nuevo, por qué terminó el anterior. La lista de razones de salida que expone el gestor de actividades incluye la muerte por baja memoria, la parada forzosa por el usuario, el cierre por exceder límites y el fallo de la propia aplicación, con marca de tiempo y con la importancia que tenía el proceso en ese instante. Registrarla al arrancar convierte un fenómeno invisible en una métrica que se puede vigilar en producción, y es la única forma honesta de saber con qué frecuencia les ocurre de verdad a tus usuarios.

val am = getSystemService(ActivityManager::class.java)
val razones = am.getHistoricalProcessExitReasons(packageName, 0, 5)
razones.firstOrNull()?.let { salida ->
    // salida.reason distingue baja memoria de parada forzosa o fallo propio
    registrar("Salida anterior: " + salida.reason + " importancia " + salida.importance)
}

Queda el malentendido más extendido del tema: la opción de desarrollador que no conserva actividades. Esa opción destruye cada actividad en cuanto el usuario sale de ella, y es una prueba excelente de recreación, pero el proceso sigue vivo. Los objetos únicos siguen ahí, las cachés en memoria siguen ahí, y aunque el ViewModel se limpie con la actividad, cualquier estado que hayas colgado del proceso seguirá tapando el agujero. Una app puede pasar esa prueba con nota y romperse en la muerte real. Úsala como primer filtro y nunca como certificado.