Memoria: heap dumps, fugas típicas y LeakCanary como red de seguridad

La palabra fuga viene de un mundo donde la memoria se pedía y se devolvía a mano, y donde fugarse significaba olvidarse de devolverla. En un entorno con recolector de basura ese olvido es imposible: el recolector libera absolutamente todo lo que ya no es alcanzable desde una raíz. Por eso una fuga en Android no es memoria perdida, es memoria retenida, y la diferencia no es terminológica sino operativa. No hay que buscar quién se olvidó de liberar algo, hay que buscar quién sigue apuntando a algo que ya no debería importarle a nadie. Toda la disciplina se apoya en esa inversión: el objeto sospechoso no es culpable de existir, es víctima de una referencia que alguien mantiene viva más allá de su tiempo, y encontrar la fuga consiste siempre en reconstruir la cadena de referencias que va desde una raíz del recolector hasta el cadáver que se niega a desaparecer.

El montón, la alcanzabilidad y las dos magnitudes

Un volcado del montón es una fotografía completa de los objetos vivos en un instante: sus clases, sus campos y las referencias que los enlazan. Se captura desde la tarea correspondiente del perfilador o directamente desde la consola, lo que resulta útil cuando el problema aparece en un dispositivo concreto o en un momento que no se puede reproducir con el entorno conectado.

# Fuerza recoleccion y vuelca el monton del proceso indicado.
adb shell am dumpheap com.ejemplo.app /data/local/tmp/volcado.hprof
adb pull /data/local/tmp/volcado.hprof .

Sobre esa fotografía todo el análisis se apoya en dos magnitudes que se confunden con enorme facilidad. El tamaño propio es lo que ocupa el objeto en sí mismo: sus campos, y nada más. Una actividad tiene un tamaño propio ridículo, unos pocos cientos de bytes. El tamaño retenido es lo que se liberaría si ese objeto desapareciera, es decir, todo lo que solo él mantiene vivo, y ahí una actividad filtrada puede arrastrar la jerarquía entera de vistas, los mapas de bits que estaban cargados y el estado de la pantalla completa: varios megabytes por instancia. Ordenar el volcado por tamaño propio no encuentra jamás una fuga; ordenarlo por tamaño retenido la pone en la primera fila.

La estructura que hace posible ese cálculo es el árbol de dominadores. Se dice que un objeto domina a otro cuando todos los caminos desde cualquier raíz hasta el segundo pasan por el primero, y el tamaño retenido de un objeto es simplemente la suma de lo que domina. Esa noción es la que convierte una maraña de referencias en una jerarquía legible, y es la que permite responder la única pregunta que importa: si esto desapareciera, ¿cuánta memoria volvería?

El catálogo de fugas y su patrón común

Las fugas de Android se repiten con una monotonía sorprendente, y todas responden al mismo esquema: algo cuya vida es larga —el proceso, un objeto único, un hilo, el sistema— guarda una referencia a algo cuya vida es corta: una actividad, un fragmento, una vista, un contexto de interfaz.

Hay dos casos que merecen mención aparte porque desafían la intuición. Una clase interna no estática mantiene una referencia implícita a su instancia externa, de modo que un mensaje diferido publicado en una cola desde una clase interna retiene la actividad durante todo el retardo, sin que ninguna línea de código exprese esa relación. Y un objeto observable de larga vida que acepta observadores sin ámbito de ciclo de vida convierte cada suscripción en una fuga potencial, que es exactamente la razón por la que la variante ligada al ciclo de vida existe.

La corrección estructural de casi todas ellas cabe en una idea: hacer que el ámbito de vida sea una propiedad expresada por el tipo en lugar de un acuerdo que alguien debe recordar.

class Pantalla : Fragment(R.layout.pantalla) {

    // Mal: el enlace sobrevive a la vista y retiene la jerarquia entera.
    private var enlaceMal: PantallaBinding? = null

    // Bien: el delegado lo anula al destruirse la vista, sin recordarlo nadie.
    private val enlace by enlaceDeVista(PantallaBinding::bind)

    override fun onViewCreated(v: View, estado: Bundle?) {
        // Atado al ciclo de vida: se cancela solo, no puede quedar huerfano.
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                modelo.estado.collect { enlace.titulo.text = it.titulo }
            }
        }
    }
}

Conviene además separar la fuga de su prima cercana, el exceso de ocupación. Una caché sin límite, un mapa de bits decodificado a resolución completa para mostrarse en miniatura o una lista que acumula todo el histórico no son fugas: son objetos legítimamente alcanzables y correctamente retenidos. El síntoma es el mismo —la memoria sube y no baja— pero el diagnóstico y el remedio son opuestos, y ninguna herramienta de detección de fugas los señalará jamás.

LeakCanary: qué hace exactamente y qué no ve

LeakCanary no es un analizador que se ejecuta cuando uno lo abre: es un vigilante que se instala solo en las compilaciones de depuración y observa la destrucción de los objetos cuyo fin de vida el sistema declara explícitamente. Su mecánica tiene cuatro pasos y entenderlos evita tanto la desconfianza como la fe ciega.

Primero, envuelve el objeto que acaba de ser destruido en una referencia débil y anota su identidad. Segundo, espera: le da un margen de tiempo y provoca una recolección, porque un objeto todavía alcanzable un instante después de morir no prueba nada. Tercero, si la referencia débil sigue sin vaciarse, declara el objeto retenido y vuelca el montón dentro del propio proceso. Cuarto, analiza ese volcado buscando el camino de referencias más corto desde una raíz del recolector hasta el objeto retenido, y presenta esa cadena eliminando los tramos irrelevantes: lo que queda es el nombre del campo concreto que sostiene la fuga.

// Vigilar objetos propios cuyo fin de vida conoces tu y no el sistema.
class Presentador(private val vista: Vista) {
    fun destruir() {
        AppWatcher.objectWatcher.expectWeaklyReachable(
            this, "El presentador fue destruido explicitamente",
        )
    }
}

Esa cuarta fase, la del camino más corto, es el verdadero producto de la herramienta y también la razón de su nombre popular: no dice que hay una fuga, dice quién la sostiene. El resto —la vigilancia automática de actividades, fragmentos, vistas, modelos de vista y servicios— es solo la conveniencia de no tener que pedirlo.

flowchart TD
A[El sistema destruye una actividad o fragmento] --> B[Referencia debil y espera]
B --> C[Se fuerza una recoleccion]
C --> D{La referencia debil se vacio}
D -->|Si| E[No hay fuga: fin]
D -->|No| F[Objeto retenido: volcado en proceso]
F --> G[Camino mas corto desde una raiz]
G --> H[Nombre del campo que sostiene la fuga]
style A fill:#89b4fa,color:#11111b
style E fill:#a6e3a1,color:#11111b
style H fill:#fab387,color:#11111b