Der Versuch, eine App zu implementieren, die Offline-Daten, die in der lokalen Datenbank gespeichert sind, an den Webserver sendet, wenn sie mit dem Internet verbunden ist. Ich benutze den unten gezeigten Code. Soweit ich es getestet habe, funktioniert es gut, nicht sicher, dass es für eine große Anzahl von Datensätzen gut funktionieren wird. Ich würde gerne wissen, ob irgendwelche Verbesserungen an diesem Code die Leistung erhöhen können ???
HINWEIS
Es ist eine Einweg-Synchronisation von App zu Server.
%Vor%Wenn dieser Code vor mir wäre, wäre mein Ansatz:
Meine Optimierungsmöglichkeit wäre die Gruppenbearbeitung. Der grobe Algorithmus wäre etwas wie:
%Vor%Dies setzt voraus, dass Sie den Servercode ändern können. Sie könnten Gruppen von 10, 20, 50, usw. tun, alles hängt von der Art der Daten ab, die gesendet werden, und von der Größe.
Ein Gruppenalgorithmus bedeutet ein bisschen mehr Vorverarbeitungsclientseite, hat aber den Vorteil, HTTP-Anfragen zu reduzieren. Wenn Sie nur eine kleine Anzahl von Updates erhalten, ist dies YAGNI und eine vorzeitige Optimierung.
Lassen Sie sich durch diese Entscheidung nicht vom Versand abhalten!
Ihr Code hat ein paar Probleme. Eine Möglichkeit besteht darin, immer den Rückgabewert zu überprüfen, bevor Sie den Fehlerparameter testen. Der Fehlerparameter könnte gesetzt sein - obwohl die Methode erfolgreich war.
Wenn Sie NSURLConnection für etwas anderes als ein schnelles Beispiel oder einen Test verwenden, sollten Sie immer den asynchronen Stil verwenden, um die Delegate-Methoden zu behandeln. Da die Verwendung von NSURLConnection richtig schnell umständlich und fehleranfällig sein kann, würde ich vorschlagen, ein Framework von Drittanbietern zu verwenden, das ein NSURLConnection -Objekt und alle verbindungsbezogenen Statusinformationen als Unterklasse von NSOperation kapselt. . In den Apple-Beispielen finden Sie eine Beispielimplementierung: QHTTPOperation . Ein weiterer geeigneter Rahmen für Dritte wäre AFNetworking (auf GitHub).
Wenn Sie den asynchronen Stil mit Delegaten oder einer Unterklasse eines Drittanbieters verwenden, können Sie die Verbindung abbrechen, detaillierte Fehler- oder Fortschrittsinformationen abrufen, eine Authentifizierung durchführen und vieles mehr - was mit der synchronen API nicht möglich ist.
>Ich denke, sobald Sie dies erreicht haben und Ihr Ansatz korrekt funktioniert, können Sie testen, ob die Leistung akzeptabel ist. Aber wenn Sie keine großen Daten haben - sagen wir & gt; 2 MByte - würde ich mir keine allzu großen Sorgen machen.
Wenn Ihre Daten wirklich groß werden, sagen Sie & gt; 10 MByte, dass Sie überlegen müssen, wie Sie Ihren Ansatz verbessern können. Zum Beispiel könnten Sie die POST-Daten als Datei-Stream anstelle eines NSData -Objekts bereitstellen (siehe NSURLRequest s-Eigenschaft HTTPBodyStream ). Die Verwendung eines Streams verhindert, dass alle POST-Daten in den RAM geladen werden, wodurch das Problem mit dem begrenzten RAM verringert wird.
Wenn Sie stattdessen kleinere POST-Daten haben, aber möglicherweise viele von ihnen, sollten Sie in Erwägung ziehen, ein NSOperationQueue zu verwenden, in dem Sie Ihre Verbindungsunterklasse NSOperation angeben. Legen Sie die maximale Anzahl von gleichzeitigen Vorgängen auf 2 fest. Dies kann dann das HTTP-Pipelining nutzen - wenn der Server dies unterstützt, wodurch die Latenzzeit verringert wird.
Natürlich gibt es in Ihrer App möglicherweise andere Teile, z. B. Sie erstellen oder rufen die Daten ab, die Sie senden müssen, was sich auf die Gesamtleistung auswirken kann. Wenn Ihr Code jedoch fehlerfrei ist und Dispatch-Warteschlangen oder NSOperationen verwendet, bei denen die Dinge parallel ablaufen, gibt es nicht viele weitere Optionen, um die Leistung der Verbindung zu verbessern.
Tags und Links objective-c sqlite ios synchronization