Depurar en producción: ANRs, Play Console y reproducir lo irreproducible

Todo lo anterior en este nivel comparte una comodidad que se da por descontada hasta que desaparece: el problema estaba delante, en un dispositivo al alcance de la mano, y podía provocarse tantas veces como hiciera falta. En producción nada de eso existe. No hay depurador que enganchar, no hay perfilador que abrir, no hay forma de pedirle a los usuarios que repitan el gesto exacto, y el fallo que arruina la valoración de la aplicación ocurre en un modelo que nadie del equipo posee, con una versión del sistema que ya nadie recuerda y bajo una combinación de memoria, red y latencia que jamás se dio en el escritorio. Lo único que queda es un flujo de evidencia parcial que el sistema recoge por su cuenta: trazas de hilos capturadas en el instante del bloqueo, informes agrupados por firma, tasas comparadas contra umbrales. Depurar en producción es la disciplina de extraer conclusiones firmes de esa evidencia incompleta y, sobre todo, de convertirla en una receta que reproduzca el fallo a voluntad.

El ANR: quién lo dispara y con qué plazo

Un ANR no es un bloqueo del programa: es un veredicto del sistema. Alguien —el despachador de eventos, el gestor de actividades, el gestor de trabajos— le pidió algo a tu proceso, midió el tiempo de respuesta y decidió que había excedido el plazo. Ese origen importa muchísimo, porque cada disparador tiene su propio plazo y su propia semántica, y el enunciado del informe ya reduce el espacio de búsqueda antes de mirar una sola pila.

El detalle contraintuitivo es que la mayoría de los ANR no los causa un cálculo largo. Los causa una espera: una transacción hacia un servicio del sistema que está saturado, una lectura de disco en el hilo principal, un candado retenido por un hilo trabajador que a su vez espera a la red, una llamada bloqueante que fuerza al hilo principal a aguardar a una corrutina, una escritura síncrona de preferencias. La firma común es un hilo principal que no consume tiempo de procesador y aun así no avanza.

Leer la traza de hilos sin engañarse

Cuando el sistema declara un ANR captura una fotografía de todos los hilos del proceso. Esa traza llega por el informe de errores del dispositivo, por Play Console y, lo más útil de todo, se puede recuperar desde el propio proceso en el arranque siguiente.

// En el arranque: recuperar por que murio el proceso la vez anterior.
val am = getSystemService(ActivityManager::class.java)
am.getHistoricalProcessExitReasons(packageName, 0, 5).forEach { salida ->
    if (salida.reason == ApplicationExitInfo.REASON_ANR) {
        val traza = salida.traceInputStream?.bufferedReader()?.readText()
        val migas = salida.processStateSummary?.decodeToString()
        registrar(traza, migas, salida.timestamp)
    }
}

Ese mecanismo es la pieza más infravalorada del arsenal de producción. Devuelve el motivo real de la última muerte del proceso —ANR, fallo, falta de memoria, cierre por el usuario, cierre por el sistema— junto con la traza completa, y además permite adjuntar un bloque de estado propio que se guarda con el registro, de modo que el informe llega acompañado de las migas de pan que el equipo decidió dejar.

La lectura de la traza tiene un orden que conviene respetar. Primero el enunciado, que dice el disparador. Segundo el hilo principal, y ahí hay tres desenlaces posibles. Si aparece ejecutando código propio, el diagnóstico es directo y el culpable está en la pila. Si aparece bloqueado esperando un monitor, la traza indica qué candado espera y qué hilo lo retiene, y entonces la investigación se traslada a ese otro hilo, que es donde está el problema real. Si aparece inactivo en la espera de mensajes, el hilo principal ya se había recuperado cuando se tomó la fotografía y la traza no contiene la causa: hay que buscarla en el consumo de procesador que acompaña al informe, en otros procesos, o aceptar que el instante quedó fuera del encuadre.

# Recuperar el informe completo con las trazas de bloqueo del dispositivo.
adb bugreport informe.zip

# Provocar un ANR de manual para practicar la lectura antes de necesitarla.
adb shell am broadcast -a com.ejemplo.LENTO

Umbrales, agrupación y la reproducción deliberada

Play Console presenta la fiabilidad como dos tasas medidas sobre sesiones percibidas por el usuario: la de fallos y la de bloqueos. Superar el umbral de mal comportamiento no produce un aviso amable, produce pérdida de visibilidad en la tienda, y superar el umbral excesivo en un modelo concreto puede llevar a que se advierta al usuario o se limite la distribución en ese modelo. El matiz que se pasa por alto es el adjetivo percibida: solo cuentan los sucesos que el usuario pudo notar, lo que descarta muchos bloqueos en segundo plano y explica por qué las cifras internas del equipo nunca coinciden con las de la consola.

La agrupación es la segunda fuente de malentendidos. Los informes se agrupan por una firma derivada de la pila, y eso produce dos errores simétricos: una única agrupación gigantesca puede contener varias causas distintas que casualmente comparten el marco superior, y una sola causa puede aparecer repartida en decenas de agrupaciones porque la pila varía ligeramente entre versiones o modelos. Por eso la primera acción sobre un informe nunca es leer la pila, sino leer la distribución: qué modelos, qué versiones del sistema, qué versión de la aplicación, cuánta memoria. Una tasa concentrada en un fabricante o en una gama de memoria es un diagnóstico casi hecho.

Todo esto sería inútil sin ofuscación invertida. La subida del archivo de correspondencia y de los símbolos de depuración nativos es lo que convierte una pila de nombres de una sola letra en algo legible, y omitirla equivale a renunciar a los informes de producción por completo.

Llegado el diagnóstico, queda lo difícil: reproducir. La estrategia es dejar de intentar repetir el gesto del usuario y empezar a recrear sus condiciones, que es donde de verdad estaba la diferencia.

flowchart TD
A[Informe de bloqueo en produccion] --> B[Leer el disparador y su plazo]
B --> C{Estado del hilo principal}
C -->|Ejecutando codigo propio| D[La causa esta en la pila]
C -->|Bloqueado en un monitor| E[Ir al hilo que retiene el candado]
C -->|Inactivo esperando mensajes| F[La fotografia llego tarde]
F --> G[Usar distribucion por modelo memoria y version]
E --> G
D --> H[Recrear condiciones no gestos]
G --> H
H --> I[Fallo determinista y prueba de regresion]
style A fill:#f38ba8,color:#11111b
style H fill:#fab387,color:#11111b
style I fill:#a6e3a1,color:#11111b