Depurar de verdad

Depurar no es avanzar línea a línea esperando ver algo raro. Es formular una hipótesis falsable sobre el estado del proceso y elegir el instrumento mínimo que la refutaría. El depurador de IntelliJ ofrece un arsenal para eso —condiciones, recuentos de impactos, puntos de ruptura que registran sin detener, rebobinado de marcos, evaluación de expresiones arbitrarias— que la mayoría de la gente no usa porque nadie se lo enseñó. Y al final del camino está el caso difícil: depurar el artefacto que realmente publicas, minificado y con los nombres borrados.

Puntos de ruptura que piensan por ti

Un punto de ruptura sin condición en un bucle de mil iteraciones no es una herramienta de diagnóstico: es una forma de perder diez minutos pulsando continuar. El diálogo que aparece al pulsar con el botón derecho sobre el punto rojo contiene todo lo que hace falta para evitarlo.

Hay dos opciones más que salvan sesiones enteras. La primera es elegir si el punto suspende todos los hilos o solo el que lo alcanza: suspender todo congela la imagen y es lo que quieres casi siempre, pero suspender solo un hilo permite observar una carrera entre dos sin detener al competidor. La segunda es el punto de observación sobre un campo, que no detiene en una línea sino cuando un valor cambia, sin que necesites saber quién lo cambia. Para código con corrutinas, además, el panel de corrutinas del depurador muestra las que están suspendidas y su estado, algo que la pila de hilos por sí sola no puede revelar.

Inspeccionar y manipular el proceso vivo

Detener el proceso es solo la mitad. La otra mitad es interrogarlo, y el depurador permite bastante más que mirar la lista de variables.

La combinación de evaluar y asignar convierte el depurador en un banco de pruebas interactivo: puedes forzar un error de red asignando null a una respuesta, comprobar la rama de fallo, descartar el marco y volver a ejecutar la misma llamada con el valor correcto. Todo eso sin una sola recompilación, que en un proyecto grande cuesta minutos.

Depurar la interfaz

El inspector de layouts muestra la jerarquía que el sistema está pintando en este instante, con las propiedades resueltas de cada nodo y, en Compose, los parámetros de cada composable junto a su semántica de accesibilidad. Resuelve de un vistazo la clase de preguntas que de otro modo se responde a base de cambiar un valor y recompilar: por qué un elemento no aparece, qué restricción lo está aplastando, qué modificador introduce ese margen que nadie escribió.

Su función más valiosa, sin embargo, no es estructural sino de rendimiento. El recuento de recomposiciones asigna a cada composable dos números: cuántas veces se ha recompuesto y cuántas veces se ha saltado la recomposición. Un composable que se recompone en cada fotograma sin que sus datos hayan cambiado es la causa más común de una interfaz que se atasca, y ese contador la convierte de sospecha en hecho. Para que funcione, la variante de depuración debe incluir las herramientas de inspección:

dependencies {
    debugImplementation(libs.androidx.compose.ui.tooling)
    implementation(libs.androidx.compose.ui.tooling.preview)
}

Depurar un release ofuscado

Aquí está el caso que separa a quien sabe depurar de quien sabe usar el depurador. La aplicación que publicas no es la que compilas en depuración: R8 la ha minificado, ha eliminado código muerto, ha incorporado métodos dentro de otros y ha renombrado clases y campos a una y dos letras. Una traza de pila procedente de producción es, literalmente, ilegible.

flowchart TD
A[Fallo en produccion] --> B[Traza ofuscada con nombres de una letra]
B --> C[Recuperar el mapping.txt de esa version exacta]
C --> D[retrace sobre la traza]
D --> E[Nombres y lineas originales]
E --> F[Reproducir en un release depurable]
F --> G[Punto de ruptura sobre el codigo real minificado]
H[Sin mapping guardado] --> I[La traza es irrecuperable para siempre]
style I fill:#f38ba8,color:#11111b
style E fill:#a6e3a1,color:#11111b

El mapa que deshace el renombrado se genera en cada compilación minificada y se escribe en app/build/outputs/mapping/release/mapping.txt. Es un artefacto irrepetible: una compilación posterior, aunque parta del mismo código, puede producir nombres distintos. Guardarlo junto a cada versión publicada no es una buena práctica, es un requisito.

# descifrar una traza de pila con el mapa de esa version
retrace mapping.txt traza_ofuscada.txt

# codigo nativo: simbolizar con los simbolos sin desnudar
ndk-stack -sym app/build/intermediates/merged_native_libs/release/out/lib/arm64-v8a \
          -dump traza_nativa.txt

Para que la traza conserve números de línea hay que preservar los atributos correspondientes en las reglas de R8, y para depurar de verdad sobre el artefacto minificado se crea un tipo de compilación intermedio que hereda del de publicación pero es depurable y está firmado con una clave de desarrollo:

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"),
                          "proguard-rules.pro")
        }
        create("releaseDebuggable") {
            initWith(getByName("release"))
            isDebuggable = true
            signingConfig = signingConfigs.getByName("debug")
            matchingFallbacks += listOf("release")
        }
    }
}

# proguard-rules.pro: sin esto, no hay numeros de linea que descifrar
-keepattributes SourceFile,LineNumberTable
-renamesourcefileattribute SourceFile