La capacidad de diagnosticar un proceso Dart en ejecución depende fundamentalmente del VM Service Protocol. No es una simple herramienta de terminal, sino un protocolo de comunicación basado en JSON-RPC sobre WebSockets que permite que procesos externos hablen con la Dart VM. Esto es lo que hace posible que Dart DevTools (una suite de herramientas web) pueda extraer información sobre la memoria, el CPU o el estado de los objetos en tiempo real.
Cuando ejecutas un proceso con dart run --observe, activas este servidor de inspección en un puerto local. A partir de ahí, el protocolo permite que herramientas externas realicen operaciones como tomar un heap snapshot o trazar la ejecución de hilos. Esta arquitectura desacoplada es la que permite que DevTools sea tan potente sin necesidad de modificar el runtime de la VM para cada nueva funcionalidad de visualización.
Debes recurrir a este ecosistema cuando la lógica de negocio se vuelve demasiado compleja para un simple print, cuando sospechas de un memory leak en un proceso de larga duración, o cuando necesitas identificar un cuello de botella en el uso de CPU mediante flame graphs. Si intentas diagnosticar problemas de rendimiento complejos usando solo logs de consola, lo más probable es que no solo pierdas el tiempo, sino que el propio overhead de imprimir strings en el estándar de salida altere la latencia que intentas medir, invalidando tus conclusiones.
Para una observabilidad profunda, no basta con ver el estado; hay que instrumentar el código. Esto se logra mediante la librería dart:developer, que nos permite enviar eventos estructurados directamente al protocolo.
import 'dart:developer' as dev;
// Representa un objeto complejo que queremos inspeccionar en el Heap
class DataPayload {
final int id;
final String metadata;
final List<int> buffer;
DataPayload(this.id, this.metadata, this.buffer);
@override
String toString() => 'DataPayload(id: $id)';
}
class HeavyProcessor {
void process(List<DataPayload> batches) {
for (var batch in batches) {
// Usamos Timeline para marcar el inicio de una operación crítica.
// Esto aparecerá como un bloque visual en la pestaña 'Timeline' de DevTools.
dev.Timeline.startSync('BatchProcessing');
try {
_performComputation(batch);
} finally {
// Es vital cerrar el intervalo de la timeline para que el gráfico sea coherente.
dev.Timeline.finishSync();
}
}
}
void _performComputation(DataPayload batch) {
// Log estructurado: No es un print. Esto permite filtrar por categoría
// en la pestaña 'Logging' de DevTools.
dev.log(
'Iniciando computación de batch',
name: 'processor.core',
level: 0,
data: {'batch_id': batch.id},
);
if (batch.id == 42) {
// debugger() detiene la ejecución si hay un debugger conectado.
dev.debugger();
// inspect(batch) permite que el programador haga clic en el objeto
// dentro de DevTools y vea su estructura completa en el árbol de objetos.
dev.inspect(batch);
}
// Simulamos carga de trabajo
final result = batch.buffer.fold<int>(0, (a, b) => a + b);
// Enviamos un evento personalizado que puede ser capturado por extensiones
dev.postEvent('data_processed', {
'id': batch.id,
'sum': result,
});
}
}
void main() async {
final processor = HeavyProcessor();
final data = [
DataPayload(1, 'Normal', [1, 2, 3]),
DataPayload(42, 'Caso Especial', [10, 20, 30]), // Aquí se activará el inspector
DataPayload(3, 'Normal', [5, 5, 5]),
];
processor.process(data);
print('Proceso finalizado. Si el debugger se activó, la VM está en pausa.');
}
En el ejemplo anterior, el flujo de trabajo de observabilidad se divide en tres capas. Primero, la instrumentación temporal mediante dev.Timeline.startSync('BatchProcessing'). Al ejecutar este código, DevTools no solo ve que el programa “está corriendo”, sino que puede dibujar un bloque de tiempo exacto que representa la duración de esa función, permitiéndonos correlacionar picos de CPU con bloques de código específicos.
Segundo, la inspección de estado. Cuando llegamos al batch.id == 42, el método dev.inspect(batch) no solo imprime el toString() en la consola. Lo que realmente hace es registrar la referencia del objeto en el VM Service. Si tienes abierta la pestaña Memory en DevTools, puedes buscar ese objeto exacto, ver todas sus propiedades, su dirección en el heap y su árbol de referencias, lo cual es vital para rastrear por qué un objeto no está siendo recolectado por el Garbage Collector.
Tercero, el logging semántico. A diferencia de print(), que es una salida de texto sin estructura, dev.log() con el parámetro name: 'processor.core' permite que en la herramienta de logging de DevTools puedas filtrar todos los eventos que pertenecen a ese módulo, ignorando el ruido de otras librerías o del runtime.
El uso de dev.postEvent es una técnica de nivel avanzado para enviar eventos de negocio personalizados al flujo de la VM. Aunque es menos común que el profiling de CPU, permite crear visualizaciones personalizadas si se implementa una registerExtension para escuchar esos eventos y procesarlos.
El error frecuente
Un error común al usar dev.inspect() o dev.log() es colocarlos dentro de bucles de altísima frecuencia (como un loop que procesa millones de elementos por segundo).
// MAL: Esto saturará el canal de comunicación del VM Service
for (var i in listaMilenes) {
dev.inspect(i);
dev.log('Iteración $i');
}
Esto produce un fenómeno de “observador invasivo”: el volumen de datos JSON-RPC que intentas enviar por el WebSocket es tan masivo que el propio proceso de comunicación consume más CPU que la lógica de tu aplicación y satura el canal, provocando que la herramienta de DevTools se congele o que las métricas de performance que estás intentando medir sean totalmente erróneas. La observabilidad debe ser quirúrgica, no masiva.
N° 119