Trazas propias: poner TU código en el timeline de Perfetto

Al abrir una traza de sistema por primera vez ocurre algo desconcertante: el sistema operativo se ve con una nitidez asombrosa —cada medida, cada disposición, cada dibujo, cada transacción, cada cambio de contexto— y tu aplicación aparece como un vacío. Hay un hueco de cuarenta milisegundos en el hilo principal y nadie dice qué pasó ahí dentro. La razón es sencilla y desagradable: el marco de trabajo está instrumentado y tu código no. Todos esos segmentos con nombre que hacen legible el cronograma existen porque alguien, en el código de la plataforma, escribió una marca de inicio y una de fin alrededor de un bloque. Instrumentar el código propio consiste exactamente en hacer lo mismo, y el resultado transforma el análisis: el hueco opaco se convierte en una jerarquía anidada que dice carga de red, deserialización, escritura en base de datos, mapeo al modelo de la interfaz. Ese es el momento en que una traza deja de describir la plataforma y empieza a describir tu programa.

El contrato de una sección síncrona

Una sección de traza es un par de marcas emitidas por el mismo hilo: una de apertura con un nombre y una de cierre sin él. El sistema de captura las empareja por orden, no por nombre, y de ahí salen las tres reglas que hay que respetar sin excepción.

La primera es el anidamiento estricto: las secciones se cierran en orden inverso al de apertura, como una pila. Si dos secciones se solapan parcialmente, el cronograma resultante no es incorrecto, es incomprensible. La segunda es el hilo único: apertura y cierre deben ocurrir en el mismo hilo, porque el emparejamiento es por pila de hilo. Una sección abierta antes de una suspensión y cerrada después, posiblemente en otro hilo trabajador, produce un cronograma corrupto. La tercera es el límite de longitud del nombre, unos pocos decenas de caracteres; lo que sobra se trunca silenciosamente.

La forma cruda de emitir el par es propensa al error más caro de todos, que es olvidar el cierre en un camino de excepción o de retorno temprano. Una sección abierta y nunca cerrada no desaparece: se traga todo lo que venga después en ese hilo y contamina la traza entera. Por eso la forma correcta es siempre la que envuelve un bloque y garantiza el cierre.

import androidx.tracing.trace

suspend fun cargarPantalla(id: String): EstadoUi {
    val crudo = trace("pantalla:red") { api.obtener(id) }
    val entidad = trace("pantalla:mapeo") { mapeador.aEntidad(crudo) }
    trace("pantalla:persistencia") { dao.guardar(entidad) }
    return trace("pantalla:estado") { entidad.aEstadoUi() }
}

Cada llamada abre la sección, ejecuta el bloque y cierra en un bloque final aunque se lance una excepción. Obsérvese que las secciones envuelven fragmentos que no cruzan una suspensión: cada una empieza y termina dentro del mismo tramo de ejecución. Esa es la traducción práctica de la regla del hilo único al mundo de las corrutinas, y es el error que más trazas arruina.

Asíncrono, contadores y composición

Cuando el trabajo empieza en un sitio y termina en otro, la sección síncrona no sirve. La sección asíncrona resuelve el problema emparejando apertura y cierre por un testigo numérico en lugar de por la pila: se abre con un nombre y un testigo, se cierra con el mismo nombre y el mismo testigo, y entre medias pueden pasar hilos, suspensiones y milisegundos. El testigo debe ser único entre las instancias vivas de esa misma operación, y ese es el matiz que se olvida: dos descargas simultáneas con el mismo testigo producen un emparejamiento arbitrario.

Los contadores cubren la otra carencia. Hay magnitudes que no son duraciones y que sin embargo explican el cronograma: elementos en cola, tamaño de una caché, peticiones en vuelo, número de recomposiciones. Un contador se dibuja como una serie temporal bajo los carriles del proceso, y correlacionar visualmente un pico de cola con un frame perdido resuelve diagnósticos que ninguna pila de llamadas resolvería.

import androidx.tracing.Trace

// Trabajo que cruza hilos: emparejamiento por testigo, no por pila.
fun iniciarDescarga(tarea: Tarea) {
    Trace.beginAsyncSection("descarga", tarea.id)
    cola.enviar(tarea) { Trace.endAsyncSection("descarga", tarea.id) }
    Trace.setCounter("descargas:en-vuelo", cola.tamano.toLong())
}

Para que nada de esto aparezca en el cronograma hace falta que la captura incluya la categoría de instrumentación de aplicación; sin ella, las marcas se emiten y se descartan, y el resultado es una traza del sistema perfecta con el mismo hueco opaco de siempre.

# La categoria de aplicacion es la que recoge TUS secciones y contadores.
adb shell perfetto -o /data/misc/perfetto-traces/traza.pftrace \
  -t 15s -b 64mb \
  sched freq gfx view app dalvik binder_driver

Queda un tercer plano, específico de la interfaz declarativa: la trazabilidad de la composición. Activada mediante las bibliotecas correspondientes y la opción adecuada en la captura, hace que cada función componible aparezca como un segmento con su propio nombre dentro del segmento de preparación de frame. Es la única forma de responder qué parte del árbol se está recomponiendo y cuánto cuesta, en vez de contemplar un bloque monolítico de composición. Su coste es alto y exige una compilación depurable, así que se enciende para investigar y se apaga para medir.

flowchart TD
A[Hueco opaco en el hilo principal] --> B[Instrumentar fronteras de fase]
B --> C{El trabajo cruza hilos o suspensiones}
C -->|No| D[Seccion sincrona con bloque]
C -->|Si| E[Seccion asincrona con testigo unico]
D --> F[Cronograma anidado y legible]
E --> F
F --> G[Contadores para magnitudes que no son duracion]
G --> H[La seccion se convierte en metrica de regresion]
style A fill:#f38ba8,color:#11111b
style F fill:#89b4fa,color:#11111b
style H fill:#a6e3a1,color:#11111b