Zum Inhalt springen
RECDiagnosticSDK
Design
RECDiagnosticSDK
01 / LIVE

Jeder Request, in Echtzeit.

Eine Live-Liste der Requests Ihrer App, gruppiert nach dem Screen, der beim Start angezeigt wurde. Suche und Filter nach Statusklasse und Methode.

Beobachten statt abfangen

Ihr Request bleibt Ihr Request.

Viele In-App-Debugger nehmen Ihren Request, stoppen ihn, bevor er rausgeht, senden eine Kopie aus ihrer eigenen Session, um die Antwort zu holen, und geben diese Antwort dann an Ihre App zurück. DiagnosticSDK hört stattdessen Ihrer Session zu.

Klassischer Interceptor

  1. 1Stoppt Ihren Request, bevor er rausgeht
  2. 2Sendet eine Kopie aus seiner eigenen URLSession
  3. 3Gibt die Antwort an Ihre App zurück
  • Ihre URLSessionConfiguration: Header, Timeouts, Cookies, Cache, Proxy
  • Ihr Delegate mit SSL-Pinning, mTLS-Zertifikaten und Authentifizierungs-Challenges

Braucht Ihr Backend diese Konfiguration (mTLS-Zertifikat, Pinning, Proxy, Session-Header), funktioniert Ihre App mit einem solchen Debugger nicht mehr. Erst wenn Sie dem Debugger diese Konfiguration übergeben, damit er sie in seiner eigenen URLSession nachbaut, läuft sie wieder.

DiagnosticSDK

  • Ihre Konfiguration wird unverändert verwendet
  • Ihr Delegate läuft: SSL-Pinning, mTLS, Authentifizierungs-Challenges
  • Kein Proxy, kein Zertifikat zu installieren

Der Request ist der, den Ihre App sendet: Er funktioniert überall, wo Ihre App funktioniert.

So funktioniert es

Ein Request, drei Momente.

Folgen Sie einem Request. In jedem Moment liest das SDK etwas mehr davon. Den Request verändert es nie.

  1. 1 · Start

    Ihr Code ruft resume() auf

    Das SDK notiert die Startzeit und den angezeigten Screen.

    Request
    GET /v1/accounts
    Screen
    HomeViewController
    Start
    10:32:04.412
  2. 2 · Unterwegs

    iOS sendet den Request wie gewohnt

    Jeder Aufruf erreicht zuerst Ihren Delegate, unverändert. Danach liest das SDK Status und Antwort.

    Request
    GET /v1/accounts
    Status
    200
    Antwort
    { "accounts": [ … ] }
  3. 3 · Fertig

    Der Request erscheint in Live

    iOS liefert seine eigenen Zeitmessungen. Der Request erscheint vollständig unter seinem Screen.

    Request
    GET /v1/accounts
    Netzwerk
    124 ms
    App
    151 ms · h2

Was genau so bleibt, wie es war

  • Der Request geht einmal raus, aus Ihrer eigenen Session.
  • Ihr Delegate erhält jeden Aufruf, unverändert.
  • Pinning, mTLS, Cookies, Cache und Timeouts funktionieren weiter.
  • Die Zeiten sind die des echten Requests.

Von iOS gemessene Zeiten

Wo sind die 124 ms geblieben?

Live misst den Request nicht von außen. Es liest die Messungen, die iOS während des Austauschs vornimmt (URLSessionTaskMetrics), und teilt sie in Schritte auf.

Netzwerkvon iOS gemessen

124 ms

Von Ihrer App gefühltvon resume() bis zu Ihrem Code

151 ms

Die schraffierten 27 ms: Der Request wartete vor dem Start, oder die Antwort wartete, bevor sie Ihren Code erreichte, zum Beispiel in einer ausgelasteten Queue.

  1. DNS-Auflösung9 msDie Serveradresse finden. Lang? Langsames DNS oder erster Aufruf dieser Domain.
  2. Verbindung18 msDie Verbindung öffnen. Entfällt, wenn eine Verbindung wiederverwendet wird.
  3. TLS-Handshake27 msDie Verschlüsselung aufbauen. Bei jedem Request? Verbindungen werden nicht wiederverwendet.
  4. Senden2 msRequest und Body verlassen das Telefon. Lang? Großer Upload oder langsames Netz.
  5. Warten auf den Server56 msIhr Backend bereitet die Antwort vor (Time to First Byte). Lang? Schauen Sie auf den Server.
  6. Download12 msDie Antwort kommt an. Lang? Schwere Antwort oder langsames Netz.
Protokoll
h2
Verbindung wiederverwendet
Nein
Aus dem Cache
Nein
Weiterleitungen
0
Empfangen
18 kB

Liefert iOS keine Messungen, sagt Live das (Quelle: Clock) und zeigt nur die von Ihrer App gefühlte Dauer.

Beispielwerte.

Zuordnung zu Screens

Jeder Request unter seinem Screen.

Live ordnet jeden Request dem Screen zu, der bei seinem Start angezeigt wurde: Sie lesen den Traffic in der Reihenfolge der Navigation.

Wie Screen Map das aufbaut

Einen Request lesen

Den richtigen Request finden und mühelos lesen.

  • Suchen und filtern

    Suche nach URL, Filter nach Statusklasse und Methode.

  • Lesbares JSON

    Bodies werden eingerückt und farbig angezeigt, bereit zum Kopieren.

  • Dekodierte Tokens

    Ein JWT in einem Header oder Body? Live zeigt, was er enthält.

Was Live nicht sieht

Die Grenzen, klar gesagt.

  • WKWebView

    Seiten in einer WKWebView laden im eigenen Prozess von WebKit, außerhalb Ihrer App. Ihre Requests, auch fetch- und XHR-Aufrufe der Seite, laufen nie über Ihre URLSession, daher sieht Live sie nicht.

    Requests, die Ihre App selbst mit URLSession rund um die Web View sendet, werden erfasst.

  • Außerhalb von URLSession

    Live sieht HTTP- und HTTPS-Requests, die mit URLSession gesendet werden. WebSockets, Network.framework-Verbindungen, rohe Sockets und Bibliotheken mit eigenem Netzwerk-Stack werden nicht erfasst.

    Bibliotheken, die auf URLSession aufbauen, werden wie alles andere erfasst.

  • Bodies ohne JSON

    Ein Body wird nur gespeichert, wenn sein Content-Type application/json oder +json enthält. Andere Bodies (HTML, Bilder, Formulardaten, Text oder JSON ohne diesen Header) werden nicht gespeichert: Eine kurze Notiz mit ihrem Typ steht an ihrer Stelle. Nur JSON-Antworten können abgespielt werden.

    URL, Methode, Header, Status, Größe und Zeiten werden weiterhin erfasst.

So funktioniert es, in der Doku Alle bekannten Einschränkungen Weiter: Screen Map