Perfetto: capturar el sistema entero y encontrar el frame perdido

Los perfiladores de proceso comparten un supuesto que casi nunca se enuncia: que la causa del problema está dentro de tu código. Es un supuesto razonable y frecuentemente falso. Un frame se pierde porque el hilo principal no terminó a tiempo, sí, pero también porque el planificador lo dejó listo y sin núcleo durante ocho milisegundos, porque el núcleo en el que corría estaba a la frecuencia mínima, porque un servicio del sistema tardó en responder a una transacción, porque el compositor no llegó a su propia fecha límite o porque otro proceso monopolizó el ancho de banda de memoria. Ninguna de esas causas aparece en una pila de llamadas. Perfetto existe porque el objeto correcto de observación en un problema de fluidez no es el proceso sino el sistema completo, y porque la única manera de atribuir la culpa con honestidad es tener a la vista, en el mismo eje de tiempo, lo que hacían simultáneamente tu aplicación, el compositor, el planificador y el hardware.

Capturar: qué se graba y a qué precio

Perfetto es un sistema de captura permanente del propio Android. Un servicio en segundo plano recoge fuentes de datos muy distintas —eventos del planificador del núcleo, marcas de instrumentación del espacio de usuario, contadores de memoria, sucesos del compositor— y las escribe en un búfer circular con un formato binario común. Esa unidad de formato es lo que permite ver en un mismo eje algo tan bajo como un cambio de contexto y algo tan alto como el nombre de una función componible.

La vía más rápida es el mosaico de captura de trazas que aparece en los ajustes de desarrollador: se activan las categorías, se pulsa para empezar, se reproduce el problema y se pulsa para terminar. Sirve para casi todo. La línea de órdenes hace falta cuando el problema exige control fino de la duración, del presupuesto de memoria o del conjunto exacto de categorías, y cuando se quiere automatizar la captura.

# Traza de 20 segundos con las categorias que importan para fluidez.
adb shell perfetto -o /data/misc/perfetto-traces/traza.pftrace \
  -t 20s -b 64mb \
  sched freq idle am wm gfx view binder_driver dalvik res memory

adb pull /data/misc/perfetto-traces/traza.pftrace .

Las dos opciones numéricas deciden si la traza servirá para algo. El presupuesto de búfer es un búfer circular: si se queda corto, los eventos más antiguos se sobrescriben en silencio y la traza aparece truncada por el principio sin ningún aviso. La categoría de planificación es con diferencia la más voluminosa, porque registra cada cambio de contexto de cada núcleo, y es también la más valiosa: sin ella no se puede distinguir un hilo que calcula de un hilo que espera turno.

Leer el cronograma sin ahogarse

Una traza recién abierta abruma porque muestra centenares de carriles de procesos que no interesan. Orientarse consiste en saber cuáles son los cinco que importan y colapsar todo lo demás.

Los estados de planificación son la lectura que más diagnósticos corrige. Un hilo ejecutándose consume tiempo de núcleo y su problema es de cálculo. Un hilo listo está preparado para trabajar y no tiene núcleo asignado, lo que significa competencia con otros procesos o migración a un núcleo pequeño, y ningún cambio en tu código lo arregla. Un hilo durmiendo espera algo: un candado, una respuesta, un temporizador. Un hilo en espera sin interrupción está casi siempre bloqueado en disco. Cuatro estados, cuatro familias de causa, cuatro clases de solución completamente distintas.

El frame perdido y su cadena causal

Un frame se pierde cuando su fecha límite pasa sin que el contenido esté listo para ser compuesto. El sistema publica esa información directamente: el carril de cronograma esperado dibuja el presupuesto que ese frame tenía, el de cronograma real dibuja lo que tardó de verdad, y cuando el segundo se sale del primero el frame aparece marcado y etiquetado con una clasificación de culpa. Esa clasificación es el primer bifurcador y ahorra horas: si dice que quien incumplió fue el compositor, o si el problema es acumulación de búferes, el trabajo no está en tu hilo principal.

Cuando la culpa es de la aplicación, se selecciona el segmento de preparación de frame correspondiente y se lee su interior. Ahí aparecen las fases conocidas —medida, disposición, dibujo— y los segmentos propios que se hayan instrumentado. El objetivo es encontrar el segmento anómalo: no el más largo en términos absolutos, sino el que dura mucho más que en los frames vecinos que sí llegaron a tiempo. Esa comparación con los frames sanos es el método, porque un frame patológico solo se define por contraste.

Encontrado el segmento anómalo, queda la última pregunta: por qué duró tanto. Aquí el cronograma ofrece firmas reconocibles.

flowchart TD
A[Frame marcado en el carril real] --> B{Quien incumplio la fecha limite}
B -->|Compositor o acumulacion de buferes| C[La causa esta fuera de la aplicacion]
B -->|La aplicacion| D[Abrir el segmento de preparacion de frame]
D --> E[Comparar con frames vecinos sanos]
E --> F[Localizar el segmento anomalo]
F --> G{Estado del hilo durante ese segmento}
G -->|Ejecutandose| H[Coste de calculo: ampliar con muestreo]
G -->|Listo sin nucleo| I[Competencia o nucleo pequeno]
G -->|Durmiendo| J[Candado o transaccion bloqueante]
G -->|Espera sin interrupcion| K[Entrada y salida de disco]
style A fill:#f38ba8,color:#11111b
style F fill:#fab387,color:#11111b
style H fill:#a6e3a1,color:#11111b