Zum Inhalt springen
RECDiagnosticSDK
Design
RECDiagnosticSDK
02 / SCREEN MAP

Traffic im Kontext.

Jeder Besuch eines UIViewControllers, der Requests startet, wird zu einem eigenen Kapitel. Die Navigationschronologie bleibt erhalten, auch wenn ein Screen zweimal besucht wird.
  1. 1Das SDK merkt sich den aktuellen ScreenJedes Mal, wenn ein View Controller viewDidLoad oder viewWillAppear ausführt, notiert das SDK seinen Klassennamen. Er ersetzt den vorherigen.
  2. 2Ein Request übernimmt den aktuellen ScreenBeim Aufruf von resume() wird der Request sofort dem angezeigten Screen zugeordnet.
  3. 3Ein Besuch wird zum KapitelDer erste Request eines Besuchs öffnet sein Kapitel, die folgenden kommen hinzu. Zurück auf einem Screen? Das ist ein neuer Besuch, also ein neues Kapitel.
  1. HomeViewControllerviewWillAppear→ aktueller Screen10:32:04
    GET/v1/accounts200124ms
    GET/v1/me20086ms
    GET/v1/notifications?unread=true200141ms
    HomeViewController3 Requests · Kapitel geöffnet um 10:32:04
  2. SettingsViewControllerviewWillAppear→ aktueller Screen10:32:06

    Kein Request bei diesem Besuch: Er erscheint nicht in der Karte.

  3. TransferViewControllerviewWillAppear→ aktueller Screen10:32:08
    GET/v1/beneficiaries20097ms
    POST/v1/transfers422302ms
    TransferViewController2 Requests · Kapitel geöffnet um 10:32:08
  4. HomeViewControllerviewWillAppear→ aktueller Screen10:32:15
    GET/v1/accounts200118ms
    HomeViewController · zweiter Besuch1 Request · Kapitel geöffnet um 10:32:15

Was gespeichert wird

Eine Session, ihre Besuche, deren Requests.

Die Session-Datei behält diese drei Ebenen. Session History, Replay und Session Studio lesen die Karte genau so, wie sie aufgezeichnet wurde.

Session

sessionId
4f2a9c1e-…
startedAt
10:32:04
metadata.deviceModel
iPhone16,1
metadata.osVersion
18.2
metadata.appVersion
3.4.0

  1. Screen-Besuchscreens[0]

    HomeViewControllerenteredAt 10:32:04

    RequestsnetworkInteractions

    GET/v1/accounts200124ms
    GET/v1/me20086ms
    GET/v1/notifications?unread=true200141ms

  2. Screen-Besuchscreens[1]

    TransferViewControllerenteredAt 10:32:08

    RequestsnetworkInteractions

    GET/v1/beneficiaries20097ms
    POST/v1/transfers422302ms

  3. Screen-Besuchscreens[2]

    HomeViewControllerenteredAt 10:32:15

    RequestsnetworkInteractions

    GET/v1/accounts200118ms

Was Sie davon haben

Jeder Request in seinem Kontext.

  • Den Weg nachvollziehen

    QA und Entwickler sehen die Screens, die der Nutzer vor dem Bug durchlaufen hat, in der richtigen Reihenfolge.

  • Abspielen in Navigationsreihenfolge

    Wurde derselbe Request bei zwei Besuchen aufgezeichnet, liefert Replay den ersten, in Navigationsreihenfolge.

  • Die Karte in Session Studio bearbeiten

    Screens umbenennen, duplizieren, neu ordnen oder entfernen und dann eine Session exportieren, die Replay lesen kann.

Genauigkeit

Wann die Karte falsch sein kann.

Zuverlässig in den meisten UIKit-Abläufen: Push, Pop, Tabs und Requests, die der Screen selbst startet. System-Screens und die Screens des SDK werden ignoriert.

  • HintergrundarbeitEin Token-Refresh, Analytics oder Polling landet unter dem Screen, der gerade angezeigt wird.
  • Child View ControllerEin eingebetteter oder vorgeladener View Controller kann zum aktuellen Screen werden.
  • Schließen eines SheetsDer Screen darunter führt viewWillAppear eventuell nicht aus: Requests bleiben unter dem geschlossenen Sheet.
  • SwiftUISwiftUI-Navigation wird nicht erkannt. Requests bleiben unter dem letzten UIKit-Screen.
  • Screens ohne RequestsEin Besuch ohne Request wird nicht gespeichert und erscheint daher nicht in der Karte.
  • ZeitenDie Zeit eines Kapitels ist der Start seines ersten Requests. Wann der Nutzer einen Screen verlässt, wird nicht erfasst.
  • Vor dem ersten ScreenRequests, die starten, bevor ein Screen bekannt ist, landen in einem Kapitel namens Background.
Das Session-Format, in der Doku Weiter: Session-Verlauf