Depuración remota por USB: las DevTools sobre un dispositivo real
Conectar un teléfono por cable y depurarlo con todas las herramientas, qué funciona igual y qué cambia, y el procedimiento cuando el dispositivo no aparece.
La depuración remota es la respuesta a todo lo que la emulación no puede hacer: las mismas DevTools, con todos sus paneles, operando sobre una pestaña que se está ejecutando en un teléfono real, con su CPU real, su memoria real y su motor real. Es una capacidad que la mayoría de la gente no ha usado nunca y que resuelve en minutos problemas que de otro modo se investigan a ciegas durante días.
- Conectar un dispositivo y abrir sus pestañas desde el escritorio.
- Distinguir qué paneles funcionan igual y cuáles cambian.
- Diagnosticar las cuatro causas de que el dispositivo no aparezca.
- Aplicar el flujo de trabajo que aprovecha la conexión.
Conectar
El procedimiento en el dispositivo tiene tres pasos: activar las opciones de desarrollador, activar la depuración por cable dentro de ellas, y conectar el cable. En el ordenador, se abre la página de inspección de dispositivos del navegador —una dirección interna que se escribe en la barra de direcciones— con el descubrimiento de dispositivos por cable activado.
La primera conexión pide autorización en el teléfono. Esa autorización es por ordenador y se puede revocar, y es la causa más frecuente de que el dispositivo aparezca pero sus pestañas no.
Una vez autorizado, aparece la lista de pestañas abiertas en el navegador del dispositivo, cada una con una acción para inspeccionarla. Al abrirla, se lanza una ventana de DevTools completa, con una vista en directo de la pantalla del teléfono a la izquierda.
La vista de la pantalla del dispositivo es interactiva en los dos sentidos: puedes tocar desde el ordenador y se refleja en el teléfono, y lo que hagas en el teléfono se ve en el ordenador. Eso permite trabajar sin soltar el teclado, que es más cómodo, y también permite hacer capturas y grabaciones del comportamiento real para adjuntar a un ticket.
Qué funciona igual y qué cambia
Elements, Sources, Console y Network funcionan exactamente igual. Se inspecciona el árbol real del dispositivo, se ponen puntos de parada en su código, se ejecuta código en su contexto y se ven sus peticiones reales, con su red real.
Performance funciona y es lo más valioso de todo. El perfil se graba en el dispositivo, con su CPU, su GPU y su memoria. Es la única forma de tener datos reales de rendimiento móvil, y los números no se parecen a los de una emulación con ralentización.
Memory funciona, con la advertencia de que tomar una instantánea en un dispositivo con poca memoria puede tardar bastante y llevarlo al límite.
El panel de renderizado funciona, y ver el resaltado de repintado sobre una pantalla de móvil real es una de las experiencias más instructivas que ofrecen estas herramientas: las regiones son enormes en proporción a la pantalla y su coste es proporcionalmente mayor por la densidad de píxeles.
La emulación de dispositivo no tiene sentido y hay que desactivarla: ya estás en un dispositivo.
La ralentización de red y de CPU sigue disponible y es útil para simular condiciones aún peores que las reales del aparato.
Lo que cambia notablemente es la velocidad de la propia herramienta: la comunicación pasa por el cable y algunas operaciones son perceptiblemente más lentas. Con instantáneas de memoria grandes y perfiles largos, hay que tener paciencia.
Cuando el dispositivo no aparece
Cuatro causas en orden de frecuencia.
La depuración por cable no está activada o se desactivó al actualizar el sistema.
Falta autorizar el ordenador. El diálogo aparece en el teléfono y a veces se descarta sin querer, o aparece con la pantalla bloqueada y no se ve. Desbloquear la pantalla y volver a conectar el cable lo vuelve a mostrar.
El modo de conexión del cable es de solo carga. Muchos teléfonos conectan por defecto sin transferencia de datos, y hay que cambiarlo desde la notificación de conexión.
El cable no transmite datos. Muchos cables baratos son solo de alimentación. Es sorprendentemente frecuente y se descarta probando otro cable.
Si tras las cuatro sigue sin aparecer, la herramienta de línea de comandos del sistema de desarrollo de la plataforma permite comprobar si el dispositivo está siendo detectado a nivel de sistema, lo que separa el problema entre la conexión y el navegador.
El flujo de trabajo que lo aprovecha
Conectar el teléfono para mirar cuatro cosas al azar no aporta mucho. El flujo que sí aporta tiene un orden.
Uno: reproducir el problema en el dispositivo primero, sin herramientas, para confirmar que existe y ver cómo se manifiesta.
Dos: grabar un perfil de la interacción problemática. Con el dispositivo real, ese perfil contiene el problema tal y como es. Compararlo con el equivalente en tu equipo con ralentización es además muy educativo: enseña cuánto se parecía tu aproximación a la realidad.
Tres: usar el resaltado de repintado y los bordes de capa si el síntoma es de fluidez. Es donde la diferencia entre emulación y realidad es más grande.
Cuatro: comprobar la memoria si el síntoma es de degradación o de recarga espontánea.
Cinco: ejecutar tu instrumentación desde la consola, con el dispositivo real como sujeto. Los fragmentos de medición de este track dan aquí números que valen de verdad.
// Panel de estado del dispositivo real, para ejecutar por depuracion remota
(() => {
const informe = {
agente: navigator.userAgent.slice(0, 100),
nucleos: navigator.hardwareConcurrency ?? 'no expuesto',
memoriaGB: navigator.deviceMemory ?? 'no expuesta',
areaVisible: innerWidth + 'x' + innerHeight,
relacionPixeles: devicePixelRatio,
pixelesFisicos: Math.round(innerWidth * devicePixelRatio) + 'x' + Math.round(innerHeight * devicePixelRatio),
conexion: navigator.connection?.effectiveType ?? 'no expuesta',
rttMs: navigator.connection?.rtt ?? null,
bajadaMbps: navigator.connection?.downlink ?? null,
ahorroDatos: navigator.connection?.saveData ?? null,
memoriaJS: performance.memory
? Math.round(performance.memory.usedJSHeapSize / 1048576) + ' MB'
: 'no expuesta'
};
console.table([informe]);
// Bateria, si el navegador la expone: la reduccion termica y el ahorro
// de energia cambian el rendimiento de forma medible
navigator.getBattery?.().then(b => {
console.log('Bateria:', Math.round(b.level * 100) + '%', b.charging ? '(cargando)' : '(descargando)');
console.log('Con la bateria baja y sin cargar, el rendimiento sera peor.');
}).catch(() => {});
// Cuota de almacenamiento real de este dispositivo
navigator.storage?.estimate?.().then(e => {
console.log('Cuota:', Math.round(e.quota / 1048576), 'MB | usado:', Math.round(e.usage / 1048576), 'MB');
});
})();
Esa foto del dispositivo es lo primero que conviene registrar en cualquier sesión remota, porque los números de rendimiento que vengan después solo tienen sentido junto a ella. Y la lectura de la batería es más informativa de lo que parece: un teléfono con poca carga y sin cargador entra en modo de ahorro y su rendimiento cae notablemente, que es exactamente el estado en el que muchos usuarios usan sus dispositivos por la tarde.
La razón por la que merece la pena superar la fricción de configurar esta conexión, que es real, es que cambia el tipo de error que cometes. Trabajando solo en el escritorio, los errores son de calibración: sabes qué mirar y tus números están escalados incorrectamente. Trabajando con el dispositivo real, esos errores desaparecen y aparecen hallazgos que no estaban en ninguna hipótesis. Los tres que más se repiten cuando un equipo conecta un teléfono por primera vez son estos. Uno: el trabajo que domina no es el que se esperaba. En el escritorio, el perfil está dominado por la ejecución de JavaScript; en el móvil, con mucha frecuencia, lo que domina es el pintado y la composición, porque la GPU es mucho más modesta en proporción y la densidad de píxeles mucho mayor. Un equipo que lleva meses optimizando JavaScript descubre que su problema era una sombra a pantalla completa. Dos: la red real no se parece al throttling. Las peticiones tienen tiempos irregulares, hay reintentos, la primera petición tras un rato de inactividad paga el coste de activar la radio, y una carga que en el simulador era predecible resulta ser errática. Y tres: la aplicación consume mucha más memoria de lo que nadie suponía, hasta el punto de que el sistema descarta la pestaña al cambiar de aplicación, produciendo una recarga completa al volver que los usuarios sufren a diario y que nadie del equipo había visto nunca porque en un ordenador con memoria de sobra eso no ocurre jamás. Ninguno de los tres se descubre analizando; los tres aparecen en la primera media hora de uso real con las herramientas conectadas. Por eso la recomendación no es “conecta el teléfono cuando tengas un problema móvil” sino “conéctalo una vez cada ciclo de trabajo aunque no tengas ningún problema”: lo que encuentres no será lo que ibas buscando, y ese es exactamente el motivo de hacerlo.