Wie erhält ein iOS-Gerät (iPad oder iPhone) „Push“-Benachrichtigungen?

Ein iOS-Gerät (iPad oder iPhone) erhält Benachrichtigungen, auch wenn das Gerät im Ruhezustand ist. Apple nennt diese „Push-Benachrichtigungen“ .

Wie empfängt das Gerät diese Benachrichtigungen? Gibt es periodische (wiederkehrende) Aktionen? Wenn ja, um welche Aktionen handelt es sich und wie oft treten sie auf?

Apple hat dazu ein Dokument auf der Entwicklerseite: developer.apple.com/library/ios/documentation/…
@Mateusz — Ich hatte dieses Dokument von Apple gesehen. Darin habe ich nichts zu meiner Frage gesehen.
Halten Sie diese Frage für unbeantwortet? Wenn ja, sagen Sie mir bitte, wie ich meine Antwort verbessern kann.

Antworten (2)

Aus der Apple Push Notification Service-Dokumentation:

Jedes Gerät stellt eine akkreditierte und verschlüsselte IP-Verbindung mit APNs her und empfängt Benachrichtigungen über diese dauerhafte Verbindung.

Dies bedeutet, dass es eine Art Socket-basierte dauerhafte Verbindung verwendet. Es könnte sich um ein eigenes proprietäres Protokoll oder WebSocket usw. handeln. Die "periodischen Aktionen", nach denen Sie fragen, werden normalerweise in diesen Protokollen auf der niedrigsten möglichen Ebene mithilfe von TCP/IP-Sockets implementiert und werden ständig nach neuen Daten auf dem Socket abgefragt . Wenn das Lesen der Daten aus dem Socket abgeschlossen ist, wird ein Ereignis ausgelöst, um eine Aktion auszuführen, z. B. das Anzeigen einer Benachrichtigung auf dem Gerät.

Um dies weiter zu erklären, funktioniert Sockets so, dass Ihr Gerät eine Verbindung zu einem Remote-Server herstellt, der Remote-Server Daten auf Ihr Gerät überträgt und in den Socket-Puffer gelegt wird, dann liest Ihr Gerät den Socket-Puffer und macht etwas mit den Daten. Sobald die Daten auf Ihr Gerät übertragen werden, verarbeitet Ihr Gerät sie. Dies liegt daran, dass Ihr Gerät ständig nach neuen Daten im Puffer des Sockets sucht . Es versucht, Daten zu lesen, und wenn es Daten erhält, sendet es sie zur Verarbeitung und versucht dann erneut, Daten zu lesen; Wenn es jemals keine Daten erhält, versucht es einfach erneut, Daten zu lesen - für immer. Wenn die Verbindung zum Remote-Server jemals getrennt wird, versucht er einfach erneut, eine Verbindung herzustellen, bis die Verbindung erfolgreich ist.

Die Codedokumentation, die ich zuvor verlinkt habe, stammt aus der ASIO-Bibliothek von Boost , die häufig für Sockets in C++ verwendet wird. Die Implementierung und Verwendung kann wie folgt vereinfacht werden:

01 start program
02 try to connect to server by using a socket
03 if not connected to server, goto 02
04 try to read data on socket
05 if data was read, process data
06 goto 03

Im 03obigen Schritt weiß das Gerät, wann Sie offline sind, und versucht nicht, erneut eine Verbindung herzustellen, bis Sie wieder online sind (das Gerät sendet ein Ereignis, wenn Sie eine Verbindung zum Internet herstellen, sodass alles sofort geschieht).

Wenn im obigen Schritt keine Daten gelesen wurden 04, wird sofort versucht, sie erneut zu lesen, ohne zu warten (vorausgesetzt, Sie sind noch mit dem Server verbunden). Es wird nur sehr wenig Rechenleistung benötigt, um wiederholt zu versuchen, Daten auf dem Socket zu lesen, sodass Sie sich keine Gedanken über den Akku oder verschwendete Ressourcen machen müssen (siehe die Antwort von @malhal hier für eine bessere Erklärung dazu und auch, wie es funktioniert, wenn das Gerät schläft).

Danke Andreas. Es besteht also eine dauerhafte Verbindung. Aber was passiert, wenn das iDevice keine Internetverbindung hat und wenn es wieder eine Internetverbindung bekommt?
Andrew, ich verstehe deinen Teil über periodische Aktionen nicht. Wären Sie so freundlich, umzuformulieren oder zu präzisieren?
@NicolasBarbulesco Ich habe meine Antwort aktualisiert und erklärt, wie Sockets funktionieren und wie das Gerät versucht, sich wieder mit dem Server zu verbinden, wenn die Verbindung unterbrochen wird.
@NicolasBarbulesco Ist meine Antwort jetzt klar genug?
Danke Andreas. Der Algorithmus ist schön und klar. Aber gibt es beim Verbindungsversuch im Offline-Modus eine Wartezeit, bevor ein erneuter Verbindungsversuch unternommen wird? Wenn ja, wie viel Zeit? Dieselben Fragen für den Versuch, Daten auf dem Socket zu lesen, wenn keine Daten zu lesen sind (das ist meistens der Fall).
@NicolasBarbulesco Das Gerät weiß, wann Sie offline sind, und stellt keine Verbindung her, bis Sie wieder online sind. Das Gerät sendet ein Ereignis, wenn Sie sich mit dem Internet verbinden, sodass alles sofort passiert. Wenn es keine zu lesenden Daten gibt, versucht es sofort, sie erneut zu lesen, ohne zu warten. Es braucht nur sehr wenig Rechenleistung, um wiederholt so zu lesen, also wird weder der Akku verbraucht noch Ressourcen verschwendet.
Danke Andreas. Das ist sehr klar. Das ist interessant. Sie können das in Ihre Antwort schreiben.
Ich habe diese Informationen zu meiner Antwort hinzugefügt. Halten Sie es jetzt für abgeschlossen?
Danke Andreas. In Bezug auf Ihren letzten Absatz in der Antwort bin ich jetzt verwirrt über den „Schritt 05“. Ich würde das eher mit der Aufgabe verknüpfen 04. Ist das mit „immer wieder so zu lesen“ richtig, oder meinst du „immer wieder versuchen so zu lesen“?
Im Ernst, dies ist die richtige Antwort und viel besser erklärt als die Informationen, die ich über andere Quellen gefunden habe. @Nicolas, achte auf Chamäleonfragen.
@NicolasBarbulesco Ich habe den letzten Absatz umformuliert, um ihn klarer zu machen, und den Verweis auf from step 04to step geändert 05. Macht das mehr Sinn?
@NicolasBarbulesco Wenn ich keine weiteren Klarstellungen vornehmen muss, könnten Sie dies bitte als die richtige Antwort markieren? Danke.
So funktioniert es nicht. Wenn das Gerät schläft, schläft die CPU, sodass sie nichts verarbeiten kann.

Ja, die Geräte-CPU ist im Ruhezustand, aber das Mobilfunkmodem hat eine andere CPU namens Baseband-Prozessor, die weiterläuft, auf eingehende Pakete überwacht, die einem bestimmten Filter entsprechen, und dann die CPU mit einem Interrupt aufweckt und ihr ermöglicht, die eingehenden Daten zu verarbeiten. Dies ist ein Trick von Microsofts Pocket PC Direct-Push, der eine Verbesserung gegenüber der Implementierung von Blackberry war, die eine BB-Infrastruktur auf der Telekommunikationsseite erforderte.

Das wusste ich nicht! Danke! Es ähnelt also dem, was ich beschrieben habe, außer dass der Basisbandprozessor den Großteil der Arbeit erledigt und nicht die normale CPU? Was ich in meiner Antwort beschrieb, war nur mehr darüber, wie Socket Polling im Allgemeinen funktioniert, da das, was ich verstand, gefragt wurde (hauptsächlich über Push-Benachrichtigungen im Allgemeinen und dass der schlafende Teil nur Hilfsinformationen waren).