Teoría 70 min 32 preguntas
TeoríaPaso 1 de 13

El listener olvidado

Repaso exprés de la Clase 1:

Callback

Función que entregas para que otro la invoque. Tú decides QUÉ; quien la guarda decide CUÁNDO. Si es diferido: otra pila, quizá otro hilo.

Listener

Callback suscrito a una FUENTE. De 0 a N por fuente, con alta y baja en ejecución. La baja exige la misma referencia.

Handler

Callback responsable de un TIPO de evento. Lo elige el despacho. Hasta ahora, escrito a mano: when (evento) { … }.

Hoy: quién es el dueño de cada callback y cuánto debe vivir, y cómo montar el despacho para que sirva igual en Android, en un servidor o en un ESP32.

Quien guarda un callback mantiene vivo todo lo que ese callback referencia

Gpsfuente · vive lo que la app
listenerslista de callbacks
{ pos -> pintar(pos) }la lambda captura this
PantallaMapadebería vivir lo que la pantalla

Cada flecha es una referencia fuerte: mientras exista la primera caja, existe la última. El recolector de basura no puede liberar nada de lo que todavía es alcanzable desde el GPS.

Cadena de referencias fuertes Gps fuente listeners lista { pos -> pintar(pos) } captura this PantallaMapa ya cerrada cada flecha es una referencia fuerte Tiempo de vida Gps vive lo que la app PantallaMapa abierta cerrada… pero sigue en memoria el usuario cierra la pantalla
El listener olvidado: la pantalla cerrada sigue alcanzable desde el GPS

Síntoma 1 · Fuga de memoria

El usuario cierra la pantalla, pero el GPS sigue apuntando a ella: ni la pantalla ni sus vistas pueden liberarse. Diez aperturas = diez pantallas en memoria.

Síntoma 2 · Callbacks fantasma

La fuente sigue invocando al listener de una pantalla que ya no existe: trabajo inútil, estado incoherente y, a menudo, una excepción.

Responde para continuar

0/2
TAREA 1
La pantalla se cerró, pero no se libera. ¿Por qué?
Elige una respuesta
TAREA 2
¿Qué síntomas produce un listener olvidado?
Marca todas las correctas