ViewController Error | Optimierung von Prozessen

cannot set data for key | Swift Apps | NSUserdefaults
lel | sudo purge

Auf dem Bild kannst du den Log von einem Verzögerungsfehler sehen, der passiert ist, weil ein User.Defaults Key mit nil gefüllt werden sollte. Ich muss ehrlich sagen, dass ich lachen musste als ich den Fehler in den Xcode Crash-Reports sah, denn schlussendlich passiert dieser Fehler nur , weil gleichzeitig hohe Energy-Reports auftreten, der RAM voll ist und die GPU Caches auch, desweiteren kam es beim Rendern zu einem Fehler.  Ich denke, dass der Fehler neben dem Absturz auch kurzzeitig den Swift Compiler verlangsamt hat. Tipps:

 

1.Only render what the user should see. Du kannst dies unterstützen in dem du Statistiken über den Zugriff führst.

Joke | Time Exception | Swift

2.Beende Threads, wenn diese länger als eine gewisse Dauer gehen und starte diese neu.

3.Vergleiche das Bild damit: problem 23:00:55.992496 +0200 UserEventAgent libsystem_network.dylib: networkd_privileged_reload_managed_network_settings :: received NULL response

4.Mache deine App effizienter :)

5.Das NSUserdefaults Fehler nicht selber bemerken können, macht es Sinn diese als dynamische Variabeln zu speichern.

Vielleicht findest du meine Beispiels-Projekt Dokumentation praktisch:

3.1: Programmierung der AR Funktion

 

 

 

Um die Nutzer zu schützen, hat Apple dafür gesorgt, dass eine App nur dann Zugriff auf die Kamera bekommen kann, wenn der Nutzer dem bereits zuvor zugestimmt hat. Da meine App die Kamera braucht, war dies der erste Schritt, den ich gemacht habe. Wenn der Nutzer der Nutzung zustimmt, dann wird ein Zertifikat hinzugefügt, welches einmalig ist.

 

 

Damit die Mexikaner nicht ständig verrutschen musste ich einen sogenannten Anker (SCNAnchor) setzen, welcher gleichzeitig der Mittelpunkt, von der gesamten Welt darstellt.  Die ARKit Szene ist in einem Koordinatenraster aufgebaut, welches man auch in der Mathematik benutzen kann, der einzige Unterschied ist, dass es noch eine dritte Variable, nämlich die Tiefe (also x,y und z, nicht nur x/z) gibt. Normalerweise ist das Handy des Spielers, der Mittelpunkt, doch dies ist absolut gar nicht praktisch, denn dan würde sich die ganze Welt ständig bewegen und die Positionen müssten ständig neuberechnet werden, weshalb ich mich entschieden habe, den Anker als Mittelpunkt zu wählen.

 

Die Mexikaner sind wie oben bereits gesagt eigentlich nur Quader, über die das Bild gelegt wird, damit der Erstellungsprozess aber besser verstanden werden kann, möchte ich kurz den dazu gehörigen Teil aus dem Code erklären:

 

(Netz zur Erstellung des Obeflächenrasters)

 

Der Spieler wird gebeten, sein Handy auf eine dunkle Oberfläche zu halten und dann auf sein Handy zu drücken. Dabei kommt die sogenannte plane-detection (Oberflächenerkennung ins Spiel). Ich habe mich entschieden, wie folgt fortzugehen:

 

 

 

 

 

 

  • Der Spieler klickt auf den Bildschirm und ich lasse das Handy, die Punkte markieren.
  • Der Spieler bewegt sein Handy nach vorne und nach hinten, was es ermöglicht, die Distanz abzuschätzen (die Strecke zwischen den beiden Punkten).
  • Das iPhone wählt sich einige markante Pixel aus, welche dann als Mittelpunkt genutzt werden.

 

(Im Bild oben, kann man ein solches Netz sehen. Allerdings ist die Oberfläche in diesem Fall nicht gerade, sondern abgerundet.)

 

 

 

Da eine Einheit im Koordinatensystem von Apple, einem Meter entspricht, nutze ich einfach eine Funktion, welche Zahlen generiert. Die kleinstmögliche Zahl, die ich gewählt habe, ist -1 und die grösste 1. Danach startet einfach ein Timer und der Nutzer kann damit beginnen, die Mexikaner anzutippen. 

 

3.1.1: Performance in ARKIT

 

 

Als ich die App zum ersten mal ausgeführt habe, ist mir aufgefallen, dass die App gerade dann wenn der Nutzer etwas zitterte, stark laggte (kommt vom Wort laggen, bedeutet einfach gesagt, dass eine Grafik stockt und nicht flüssig läuft). Also musste ich mir überlegen, was ich machen könnte, um das Problem zu beheben. Es ist zwar so, dass ich die Mexikaner bereits beim initieren (dem ersten Starten der Kamera) hinzufüge, aber die Grafikkarte berechnet trotzdem jedesmal, wie die Mexikaner aussehen würden, auch dann, wenn der Nutzer in eine andere Richtung schaut. Grafiken und Animationen werden aus einzelnen Bildern hergestellt, je mehr dieser Bilder pro Sekunde verarbeitet werden können, desto klarer sehen die Animationen aus. (Die Anzahl der Bilder pro Sekunde, kann bei dem Wort FPS und Animations gesehen werden).  

Diese einzelnen Bilder werden jedesmal gesamt (also als 360° Bild) gerendert, was mich auf die Idee gebracht hat, Inhalte aus nicht angezeigten Chunks (Teile des Bildes) einfach zu entfernen. Da die Bilder so häufig neugerendert werden und gleichzeitig eine Plane Detection lief und Fake-News EasterEggs (kleine Features, die Entwickler programmieren, aber normalerweise versteckt sind) geladen wurden, war der Cache, der GPU (Grafikkarte)) völlig „vollgestopft“. 

 

 

Cache: Ein Smartphone verfügt über einen sogenannten Arbeitsspeicher, der die Daten, die benötigt werden, enthält. Wenn nun eine Grafik ausgeführt werden soll, dann lädt die Grafikkarte die benötigten Daten in den eigenen kleinen Arbeitsspeicher, damit sie schneller auf die Daten zugreifen kann.

 

Der Cache ist flüchtig, was bedeutet, dass der Cache automatisch gelöscht wird, wenn ein Prozess beendet ist. Man könnte die Situation des Caches in diesem Moment also mit einem Bus vergleichen: Wenn man 100 Leute von A nach B bringen will, der Bus aber nur Platz für 20 hat, dann gehen die Leute halt nacheinander und man presst nicht 100 Leute hinein, da die sonst ersticken oder der Bus platzen könnte :)

Um eben die Situation (welche ich mit dem Bus verglichen habe) zu verhindern, prüfe ich beim Laden von jedem Einzelbild in welche Richtung der Nutzer schaut und verarbeite nur die Mexikaner, die der Nutzer auch wirklich sehen kann, denn ansonsten würden alle Mexikaner (auch die, die man nicht sieht) ihre Animationen durchlaufen, was wertvolle Ressourcen verschwenden würde.

 

 

Das Hauptproblem war aber, dass normale Apps keinen Zugriff auf die Speicherverwaltung hat, weshalb ich die 3D Modelle einfach nacheinander geladen habe und bevor ein neues kam, habe ich einfach den Arbeitsspeicher gelöscht (dies kann man auf Unix Geräten mit dem Befehl: sudo purge, tun (Unix ist die Urversion von Linux auf der auch macOS und iOS basieren).

 

 

Bei meiner App konnte ich beobachten, dass  es sogar effizienter war, Variabeln (Daten) auf der Festplatte zu speichern, obwohl diese langsamer ist, denn dies hatte den Vorteil, dass der Arbeitsspeicher geschont wurde.

 

21th Century The Game ist keine sehr komplizierte AR App, aber trotzdem belegte meine App c.a 80 % des Arbeitsspeichers bzw. Des GPU Caches und dazu kommen dann noch andere Funktionen des Handys, so laufen ständig Prozesse, die auf den Push-Messaging Servern von anderen Apps nach neuen Nachrichten suchen und weitere Prozesse. 

 

Wenn man im Augmented-Reality Screen auf das Plus drückt, dann kann man die Verbrauchsstatistiken sehen, so fällt zum Beispiel auf, dass beim ersten Laden (dort habe ich noch nicht mit der Sparmethode gearbeitet), der Cache sehr voll ist und dann nach ca. 1 Sekunde fast leer ist.

 

Um einen Absturz zu verhindern, greift die App ständig auf die Statistiken zu, werden zum Beispiel weniger als 30 Bilder pro Sekunde angezeigt, so ist die Wahrscheinlichkeit gross, dass die App abstürzen wird bzw. dass das Nutzer-Erlebnis schlecht ist, weshalb die App in diesem Fall, den Prozess selbst beendet und den Nutzer zum nächsten Gamemode sendet.

 

 

 

 

Abschliessend kann ich jedem App Entwickler, die folgenden Tipps geben:

 

 

 

  • Verwenden Sie die NSURLSession-Hintergrundsitzung
  • Minimieren Sie die Verwendung des kontinuierlichen Standortes und wählen Sie die Genauigkeit effizient aus
  • Vermeiden Sie Timer

Kommentar schreiben

Kommentare: 0

Click the button



KONTAKT

Bitte den Code eingeben:

Hinweis: Bitte die mit * gekennzeichneten Felder ausfüllen.


ADCELL

Hey! Thats me!

Severin Kämpfer Bremgarten bei Bern

16 years old trekkie.

Persönliche Webseite:

https://www.severin-kaempfer.ch

Unterstütze KKTVCAM mit 1 CHF! Bezahle mit Bitcoin!


*: Bedeutet, dass KKTVCAM das Produkt/die Seite evtl. getestet hat und nun Affiliate der betreffenden Firma ist.

Made with ♥ in Bern (Switzerland)!

KKTVCAM ÜBERNIMMT KEINE HAFTUNG FÜR ALLE ANGABEN AUF DIESER SEITE.