Hallo zusammen,
ich habe hier aus dem Doppelpost
der DP-EN,
einen eigenen Thread mit den neuesten Erkentnissen gemacht:
Ich habe einige Tests gemacht, kann aber nicht wirklich sagen, dass ich weiß, was hier los ist.
Es geht um Bluetooth auf
IOS mit verschiedenen IoT-Geräten im Hintergrundmodus.
Hier sind ein paar Fakten, die ich sehen kann:
- Die App funktioniert im Vordergrund (FG) einwandfrei und kann im Hintergrund (BG) abstürzen.
- Der BG-Absturz tritt auf, wenn das Telefon das IoT-Gerät verliert, während die Verbindung in BG hergestellt ist.
- Der BG-Absturz kommt in meinem Büro nie vor. Ich kann mich sogar außerhalb der Reichweite bewegen, während das IoT die Verbindung ordnungsgemäß trennt.
Es kann danach wieder verbunden werden (während die App in BG geöffnet werden kann,
es kein Neustart der App).
- Die App in BG kann eine Benachrichtigung senden, wenn die Verbindung getrennt wird.
Dies ist alles in Ordnung.
- Wenn ich in FG verbunden bin, kann ich mich ungefähr 15 m bewegen, die Verbindung bleibt weiterhin stabil (keine Trennung, kein Absturz)
Wenn ich in BG verbunden bin und mich 15 m bewege, wird die Verbindung getrennt (kein Absturz).
- Es scheint, dass der BG-Betrieb möglicherweise weniger Sendenergie oder weniger QoS hat
Das alles wäre in Ordnung, nur
- An einigen kritischen Orten stürzt dieselbe App auf demselben Telefon direkt bei Eintritt der BG ab
Diese Orte sind Büros, in denen viel HF-Rauschen zu sehen ist (etwa 50 BLE-Geräte im Scan, viele WiFi-Geräte, ...).
- Diese Orte enthalten viele umgebende IoT-Geräte wie Smartwatches und mehrere nahe gelegene (<50 m) WLAN-Firmenrouter
- An normalen Orten habe ich auch ungefähr 20 IoT-Geräte und einige WiFi-Geräte in der Nähe, aber vielleicht nicht so viele wie oben.
Was an diesen kritischen Orten passiert, ist
- Die App funktioniert gut im Vordergrund (FG) und stürzt kurz nach Betreten Hintergrund (BG) ab
- Es wurde noch keine Benachrichtigung gesendet. Dies bedeutet, dass OnDisconnect normalerweise nicht ausgelöst wird
- Die App kann nicht wirklich protokolliert werden, wie es an normalen Orten möglich ist
Ich habe Experimente mit verschiedenen IoT gemacht,
eines 2 Sekunden, eines
12 Sekunden Datenrate, das sind beides zwei verschiedene Geräte (Vielleicht haben sie auch noch andere unterschiedliche Einstellungen).
Das Interessante Verhalten kann ich
an den kritischen Orten sehen:
- die 2sec. Geräte arbeiten in BG, OK - kein Absturz
- die 12sec. Geräte zeigt alle negativen Verhaltensweisen von oben
Dies führt mich zu der Frage:
Wechseln die iOS-Telefone im BG in einen anderen Energiemodus oder Energiesparmodus,
wenn die Datenrate geringer ist (z. B. > 10 Sekunden)?
Dies wäre meine einzige Erklärung für das seltsame Verhalten, dass schneller sendende Geräte iOS aktiver halten (möglicherweise innerhalb des Bereichs von 10 Sekunden).
Das Telefon verfügt also anscheinend über höhere QOS Funktion, um die Verbindung aufrechtzuerhalten.
Gibt es vielleicht ein Dokument oder eine Website von Apple die ein solches Verhalten erklären würde ?
Ich habe das Web gründlich durchsucht, aber keine passenden Informationen zu meiner Annahme gefunden.
Vielleicht gibt es da draußen bei Euch eine Hilfestellung ?
Das ist eine interessante Lektüre
https://github.com/opentrace-communi...e-ios/issues/4
Auch in Bezug auf die Wiederherstellung nach dem Hintergrundzustands (BG).
Ich habe das Wiederherstellen noch nicht implementiert, das könnte natürlich helfen,
aber es wird in FMX nicht unterstützt.
Das Problem ist aber das die App echt abstürzt, was aber auch an meiner Umsetzung in BLE liegen kann (das war ursprünglich nur für FG gedacht).
Jedenfalls scheinen
an den kritischen Orten andere Events zu feuern, oder sonst etwas anders zu Laufen als in FG.
Ich kann das aber weder debuggen noch vernünftig loggen, ich versuche gerade eine ganz abgespeckte Version zu bauen.