Zurück aus dem Hintergrund: nicht warten, nicht schweigen, nicht lügen - #199
Merged
Merged
Conversation
Die Seite behandelte das Entsperren bis hierher GAR NICHT.
`visibilitychange` gab es genau einmal, und zwar um das Mikrofon
loszulassen. Was dabei wirklich passiert:
* Der WebSocket ist tot, aber `onclose` kommt erst, wenn das System
die Seite auftaut -- und der Wiederholungsabstand ist inzwischen auf
10 s gewachsen. Man sieht sekundenlang nichts, obwohl das Funkgeraet
bereit ist. LIVE GEMESSEN, gleiche Ausfalldauer (55 s):
ohne Wecken: Server zurueck 05:23:37, Seite da 05:23:45 -> 8 s
mit Wecken: Server zurueck 05:25:10, Seite da 05:25:13 -> 0 s
(dieselbe Sekunde wie das Wecken)
* Der AudioContext ist von iOS angehalten. Ein angehaltener Kontext
ruft seinen Rueckruf nie wieder auf -- der Ton bliebe stumm, bis
jemand TON AUS und wieder EIN drueckt.
* Wasserfall und S-Meter zeigen den Stand von VOR dem Sperren, ohne
das zu sagen. Dieselbe Gattung Luege wie ein stehender Wasserfall:
er behauptet ein leeres Band, und danach wird nicht gerufen. Jetzt
zieht das Aufwachen denselben Strich, den ein Bandwechsel zieht --
oben das Neue, unten das Alte.
Entschieden wird in `aufwachen.js`, und NICHT am `readyState` allein:
iOS friert die Seite ein, die Gegenseite raeumt auf, und der Socket
meldet noch OFFEN. Wer darauf wartet, dass `onclose` kommt, wartet unter
Umstaenden ewig. Darum zaehlt der Zustand UND die Stille -- kommt seit
drei Sekunden nichts an, wird neu verbunden, ganz gleich was der Socket
behauptet. Eine ueberfluessige Neuverbindung kostet eine halbe Sekunde,
eine ausgelassene den Moment, in dem man das Telefon in die Hand nimmt.
Die Grenze fuer "das Bild ist alt" liegt mit 1,5 s UNTER der fuer "der
Socket ist tot" (3 s): lieber einmal zu frueh sagen, dass das Bild von
vorhin ist, als einmal zu spaet. Ein falsch beschriftetes altes Bild ist
harmlos, ein unbeschriftetes nicht.
Die Abonnements muessen nicht erneuert werden -- sie haengen am
`open`-Ereignis und kommen mit der neuen Verbindung von selbst. Die
Spots schon, die laufen waehrend des Schlafens ab.
Drei Wege ins Aufwachen, weil nicht jedes System `visibilitychange`
zuverlaessig meldet: `visibilitychange`, `pageshow` mit `persisted`,
`focus`. Mehrfaches Aufwachen schadet nicht -- die Entscheidung wirft
eine lebendige Verbindung nicht weg, und genau das ist geprueft.
17 Pruefpunkte (pruefe-aufwachen.mjs), dazu die Live-Messung oben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Punkt 4 der App-Zeitachse. Die Seite behandelte das Entsperren bis hierher
gar nicht —
visibilitychangegab es genau einmal, und zwar um dasMikrofon loszulassen.
Live gemessen, gleiche Ausfalldauer (55 s)
Der Wiederholungsabstand wächst beim Schlafen auf 10 s.
onclosekommt erst,wenn das System die Seite auftaut — man sieht sekundenlang nichts, obwohl das
Funkgerät bereit ist.
Drei Lücken, drei Antworten
Der tote Socket. iOS friert die Seite ein, die Gegenseite räumt auf, und
readyStatemeldet nochOPEN. Wer darauf wartet, dassonclosekommt,wartet unter Umständen ewig. Entschieden wird darum am Zustand und an der
Stille: kommt seit drei Sekunden nichts an, wird neu verbunden, ganz gleich was
der Socket behauptet. Eine überflüssige Neuverbindung kostet eine halbe
Sekunde, eine ausgelassene den Moment, in dem man das Telefon in die Hand
nimmt.
Der stumme Ton. Der AudioContext ist von iOS angehalten, und ein
angehaltener Kontext ruft seinen Rückruf nie wieder auf. Der Ton bliebe stumm,
bis jemand TON AUS und wieder EIN drückt.
Das Bild von vorhin. Wasserfall und S-Meter zeigen den Stand von vor dem
Sperren, ohne das zu sagen — dieselbe Gattung Lüge wie ein stehender
Wasserfall: er behauptet ein leeres Band, und danach wird nicht gerufen. Jetzt
zieht das Aufwachen denselben Strich, den ein Bandwechsel zieht.
Die Grenze für „das Bild ist alt" liegt mit 1,5 s unter der für „der Socket
ist tot" (3 s): lieber einmal zu früh sagen, dass das Bild von vorhin ist, als
einmal zu spät. Ein falsch beschriftetes altes Bild ist harmlos, ein
unbeschriftetes nicht.
Was nicht nötig war
Die Abonnements müssen nicht erneuert werden — sie hängen am
open-Ereignisund kommen mit der neuen Verbindung von selbst. Nachgesehen, nicht angenommen.
Die Spots schon: die laufen während des Schlafens ab.
Drei Wege ins Aufwachen, weil nicht jedes System
visibilitychangezuverlässigmeldet:
visibilitychange,pageshowmitpersisted,focus. MehrfachesAufwachen schadet nicht — die Entscheidung wirft eine lebendige Verbindung
nicht weg, und genau das ist geprüft.
17 Prüfpunkte (
pruefe-aufwachen.mjs), dazu die Live-Messung oben.🤖 Generated with Claude Code