Ir al contenido
RECDiagnosticSDK
Tema
RECDiagnosticSDK
01 / LIVE

Cada petición, en tiempo real.

La lista en directo de las peticiones de tu app, agrupadas por la pantalla en curso cuando salieron. Busca y filtra por clase de estado y por método.

Observar, no interceptar

Tu petición sigue siendo tuya.

Muchos depuradores integrados toman tu petición, la detienen antes de que salga, envían una copia desde su propia sesión para obtener la respuesta y luego devuelven esa respuesta a tu app. DiagnosticSDK, en cambio, escucha tu sesión.

Interceptor clásico

  1. 1Detiene tu petición antes de que salga
  2. 2Envía una copia desde su propia URLSession
  3. 3Devuelve la respuesta a tu app
  • Tu URLSessionConfiguration: cabeceras, timeouts, cookies, caché, proxy
  • Tu delegado, con su SSL pinning, sus certificados mTLS y sus desafíos de autenticación

Si tu backend necesita esta configuración (certificado mTLS, pinning, proxy, cabeceras de sesión), tu app deja de funcionar con ese tipo de depurador. Solo vuelve a funcionar cuando pasas esa configuración al depurador, para que la reconstruya en su propia URLSession.

DiagnosticSDK

  • Tu configuración se usa tal cual
  • Tu delegado se ejecuta: SSL pinning, mTLS, desafíos de autenticación
  • Sin proxy, sin certificado que instalar

La petición es la que envía tu app: funciona allí donde funciona tu app.

Cómo funciona

Una petición, tres momentos.

Sigue una petición. En cada momento, el SDK lee un poco más. Nunca modifica la petición.

  1. 1 · Salida

    Tu código llama a resume()

    El SDK anota la hora de salida y la pantalla en curso.

    petición
    GET /v1/accounts
    pantalla
    HomeViewController
    salida
    10:32:04.412
  2. 2 · En camino

    iOS envía la petición como siempre

    Cada llamada llega primero a tu delegado, sin cambios. Después, el SDK lee el estado y la respuesta.

    petición
    GET /v1/accounts
    estado
    200
    respuesta
    { "accounts": [ … ] }
  3. 3 · Llegada

    La petición aparece en Live

    iOS entrega sus propias medidas de tiempo. La petición aparece bajo su pantalla, completa.

    petición
    GET /v1/accounts
    red
    124 ms
    app
    151 ms · h2

Lo que queda exactamente igual

  • La petición sale una sola vez, desde tu propia sesión.
  • Tu delegado recibe todas sus llamadas, sin cambios.
  • Pinning, mTLS, cookies, caché y timeouts siguen funcionando.
  • Los tiempos son los de la petición real.

Tiempos medidos por iOS

¿Adónde fueron los 124 ms?

Live no cronometra la petición desde fuera. Lee las medidas que iOS toma durante el intercambio (URLSessionTaskMetrics) y las divide en etapas.

Redmedido por iOS

124 ms

Percibido por tu appde resume() a tu código

151 ms

Los 27 ms rayados: la petición esperó antes de salir, o la respuesta esperó antes de llegar a tu código, por ejemplo en una cola ocupada.

  1. Búsqueda DNS9 msEncontrar la dirección del servidor. ¿Largo? DNS lento, o primera llamada a este dominio.
  2. Conexión18 msAbrir la conexión. Desaparece cuando se reutiliza una conexión.
  3. Negociación TLS27 msPreparar el cifrado. ¿En cada petición? Las conexiones no se reutilizan.
  4. Envío2 msLa petición y su cuerpo salen del teléfono. ¿Largo? Envío grande o red lenta.
  5. Espera del servidor56 msTu backend prepara la respuesta (time to first byte). ¿Largo? Mira el servidor.
  6. Descarga12 msLlega la respuesta. ¿Larga? Respuesta pesada o red lenta.
Protocolo
h2
Conexión reutilizada
No
Desde la caché
No
Redirecciones
0
Recibido
18 kB

Cuando iOS no da medidas, Live lo indica (fuente: Clock) y solo muestra la duración percibida por tu app.

Valores de ejemplo.

Asignación de pantallas

Cada petición, bajo su pantalla.

Live coloca cada petición bajo la pantalla en curso cuando salió: lees el tráfico en el orden de la navegación.

Cómo lo construye Screen Map

Leer una petición

Encuentra la petición correcta y léela sin esfuerzo.

  • Buscar y filtrar

    Búsqueda por URL, filtros por clase de estado y por método.

  • JSON legible

    Los cuerpos aparecen indentados y coloreados, listos para copiar.

  • Tokens decodificados

    ¿Un JWT en una cabecera o un cuerpo? Live muestra lo que contiene.

Lo que Live no ve

Los límites, dichos con claridad.

  • WKWebView

    Las páginas de un WKWebView se cargan en el proceso de WebKit, fuera de tu app. Sus peticiones, incluidas las llamadas fetch y XHR de la página, nunca pasan por tu URLSession, así que Live no puede verlas.

    Las peticiones que tu app hace por sí misma con URLSession, alrededor de la web view, sí se capturan.

  • Fuera de URLSession

    Live ve las peticiones HTTP y HTTPS hechas con URLSession. Los WebSockets, las conexiones de Network.framework, los sockets directos y las bibliotecas con su propia pila de red no se capturan.

    Las bibliotecas construidas sobre URLSession se capturan como el resto.

  • Cuerpos no JSON

    Un cuerpo solo se guarda si su Content-Type contiene application/json o +json. Los demás cuerpos (HTML, imágenes, formularios, texto, o JSON enviado sin esa cabecera) no se guardan: una nota breve con su tipo ocupa su lugar. Solo las respuestas JSON se pueden reproducir.

    La URL, el método, las cabeceras, el estado, el tamaño y los tiempos se siguen registrando.

Cómo funciona, en la documentación Todas las limitaciones conocidas Siguiente: Screen Map