C# Performance von Entschlüsselungsalgorithmen auf Android/iOS

[Ruheliebhaber]

ACHTUNG: Ich habe das nachfolgende geschrieben, bevor ich Deine Antwort gelesen habe.

----

Jetzt verstehe ich langsam.
Geo-Daten sind immer Leistungskiller.
Jetzt verstehe ich auch, warum Du ein sehr schnelles Entschlüsseln der Daten brauchst.

Obwohl das nicht heißt, dass Du nicht irgendwo in Deiner App Memory-Leaks hast, die man noch wegoptimieren könnte.

Das hier kennst du sicher:

var maxMemory = Java.Lang.Runtime.GetRuntime().MaxMemory();
var freeMemory = Java.Lang.Runtime.GetRuntime().FreeMemory();
var percentUsed = (double)(maxMemory-freeMemory) / (double)maxMemory;

Eventuell wäre es eine Überlegung wert mal zu schauen, ob Du irgendwo leere Teilbäume in Deine Objektstrukturen hast, die man auf NULL setzen und dadurch "abschneiden" könnte, ohne dass das Deserialisieren in einer Exception endet.
Ich meine, XML hat einen ziemlichen Overhead und das Parsen verbraucht auch schon eine Menge RAM.

Ansonsten fällt mir spontan noch das Stichwort Lazy Loading ein, da ein Prefetch der Daten keine Option zu sein scheint.
So eine Art Mip-Mapping-Ansatz für die Darstellung der Polygone scheinst Du ja schon implementiert zu haben.

Hier gibt es noch ein paar Tipps zum Memory Management.
Z.B. intensive Vererbung vermeiden.
https://developer.android.com/topic/performance/memory

Zum Thema Parallelisierung.
Das hört sich erst einmal widersinnig an, aber ich würde auch schauen, ob Du parallele Threads "sparen" kannst.
Die ThreadPool-Klasse ist super, aber parallele Verarbeitung kann auch einen ganz schönen Overhead erzeugen.
Da hilft nur nachmessen.
Vielleicht stellt sich ja heraus, dass nur ein paralleler Worker schneller ist, als z.B. viel.
Gerade bei sehr kleinen Tasks kann sequentiell manchmal schneller sein als parallel.

Zum Thema Verschlüsseln fällt mir noch so eine Art File Vault ein.
Soll heißen, die XML-Dateien sind verschlüsselt in Deinem APK gespeichert.
Nachdem die App installiert ist, sind die Dateien immer noch verschlüsselt.
Wird die App gestartet, entschlüsselt sie als erstes die Dateien in ein temporäres Arbeitsverzeichnis.
Dieses Arbeitsverzeichnis steht im Idealfall nur dem Prozess Deiner Anwendung zur Verfügung.
Ich kenne mich leider mit Android zu wenig aus, um zu wissen, was das OS in dieser Beziehung alles anbietet.
Also von einer versteckten Partition bis hin zu einer temporären RAM-Disk.
Nach Beenden der App, wird das temporäres Arbeitsverzeichnis einfach wieder gelöscht.

Das ist vielleicht keine wirkliche Sicherheit, macht es aber auf jeden Fall aber wieder etwas schwerer, Deine XML-Dateien zu entwenden.
Dieser Ansatz verfolgt so ein bisschen die Strategie Sicherheit durch Verschleierung.

 

[new Account()]

Ansonsten fällt mir spontan noch das Stichwort Lazy Loading ein, da ein Prefetch der Daten keine Option zu sein scheint.

*Prefetch mit Parsen in die Google Objekte.
Wenn ich das richtig verstehe, sind die LatLng Objekte lediglich durch zwei doubles bestimmt. Mann könnte sich ja auch selbst eine LangLng Klasse schreiben und die Objekte dann in Objekte der eigenen Klasse parsen/prefetchen. Das dürfte in einem Verbrauch von deutlich weniger als 2.5MB enden, da XML ziemlich verschwenderisch ist.
Bei Bedarf kann man dann sehr schnell die LatLng Objekte mit den eigenen Objekten erstellen.

Ergänzung (2. April 2019)

Das ist vielleicht keine wirkliche Sicherheit, macht es aber auf jeden Fall aber wieder etwas schwerer, Deine XML-Dateien zu entwenden.
Dieser Ansatz verfolgt so ein bisschen die Strategie Sicherheit durch Verschleierung.

Das sind alles Ansätze aka Sicherheit durch Verschleierung, oder?
Zum Entschlüsseln braucht die App irgendwoher einen Schlüssel, und wo ist der gespeichert, wenn die App offline funktionieren soll? hmm

 

[Ruheliebhaber]

@new Account()
Du Recht, das ist Verschleierung, aber irgendwann kommt man nicht mehr anders weiter, wenn das Entschlüsseln zur Laufzeit zu lahm ist und das alles offline funktionieren soll.

@Physikbuddha
Falls Du noch Lust hast, könntest Du noch einmal den Blowfish-Algorithmus mit 128 Bit Schlüssellänge benchen.
Der ist vielleicht nicht mehr so sicher wie AES, soll aber schneller sein und weniger RAM verbrauchen.

 

[umask007]

Also ich glaube, dass nicht der Verschlüsselungsalgorithmus das Performance und Speicher Problem ist,
sondern dass du die Daten duplizierst in Form von base64 Strings und Byte Arrays.
Wieso nicht mit Streams arbeiten?
Der Link zur Cryptostream Klasse, den ich weiter oben gepostet habe,
funktioniert als Dekorator für einen Stream und sollte kaum Speicher brauchen.
Performance Probleme sind mir auch nicht aufgefallen,
als ich die Klasse zuletzt verwendet habe...

Für die Geodaten-Objekte schlage ich das Flyweight Pattern vor.
Also anstatt die Objekte ständig neu zu erstellen und so den garbage Collector zu belasten,
verwendest du diese wieder, indem du beispielsweise die Objekte auf der Karte verschiebst,
und die, die du nicht brauchst, unsichtbar machst oder irgendwo hinverschiebst, wo der User die nicht sieht.