Medir el hilo principal

El presupuesto

Los dieciséis milisegundos no son arbitrarios: es lo que dura un fotograma a sesenta imágenes por segundo. Una tarea del hilo principal que se pase de ahí hace que se pierda un fotograma, y varias seguidas se perciben como pastosidad.

Instrumentar sin herramientas

No hace falta un perfilador. Un envoltorio alrededor de lo que encolas y de tus manejadores del bucle da el noventa por ciento de la información:

/// Ejecuta el bloque midiendo, y avisa si se pasa del presupuesto.pub fn en_principal<F: FnOnce() + Send + 'static>(app: &AppHandle, que: &'static str, f: F) {    let _ = app.run_on_main_thread(move || {        let t = std::time::Instant::now();        f();        let d = t.elapsed();        if d > std::time::Duration::from_millis(5) {            log::warn!("bloque '{que}' ocupó el hilo principal {d:?}");        }    });}

Y para los manejadores del bucle, lo mismo alrededor del cuerpo. Con eso, cualquier cosa que se pase del presupuesto deja constancia con su nombre, que es infinitamente mejor que descubrirlo probando.

Dejarlo activo en desarrollo cuesta nada y caza los casos 3 y 5 del nivel 24.3 antes de que lleguen a producción.

Las dos cifras que se perciben

De todo lo medible, dos son las que el usuario nota:

El bloqueo máximo. No la media: el peor. Una aplicación con una media de dos milisegundos y un pico de ochocientos se percibe como una aplicación que se traba, porque lo que se recuerda es el pico. Vigilar el máximo es lo que corresponde a cómo funciona la percepción.

El tiempo hasta la primera pintura. El arranque en frío del nivel 11.5, que se mide desde el doble clic hasta que hay algo en pantalla. Es la primera impresión y no hay segunda.

Las dos se pueden registrar con el envoltorio de arriba más una marca al arrancar, y las dos merecen aparecer en el fichero de registro para poder compararlas entre versiones.

Lo que se mide en el otro lado

Conviene separarlo, porque el caso 6 del nivel 24.3 no se ve desde aquí. El bloqueo del hilo de la webview se mide con las herramientas del navegador: el registro de tareas largas, el perfilador de la pestaña de rendimiento, las métricas de interacción.

Es el mismo problema con otra instrumentación, y el track de Rendimiento Web lo cubre entero. Lo que hay que llevarse de este nivel es que son dos presupuestos distintos y hay que vigilar los dos: una aplicación puede tener el hilo principal impecable y sentirse pastosa por el frontend, y al revés.