WP8.1 WinRT Filehandling auf Low-Memory-Devices

Hallo Leute,
schon wieder ein Thread von mir - langsam wird es aber auch wirklich zur Party hier :D

Heute dreht sich das Thema um Memorylimits und Filehandling. Wie jeder von euch wissen dürfte, hat WP ja ein Memorylimit für jeden Gerätetyp, welches unterschiedlich ausfällt je nach verfügbarer Menge des Gesamtarbeitsspeichers, den das Gerät hat. Ein 512MB Phone hat bspw. ein Limit von 150MB, welches eine App nutzen kann, während mein NL 1520 ein Limit von 8xx MB hat (genaue Zahl grad nicht im Kopf)
Dieses Memorylimit wird mir allerdings auch gerade zum Verhängnis. Vielleicht kennt jemand ja meine App PhotoKeeper, genau da tritt das Problem nämlich auf. Die App arbeitet prinzipbedingt mit vielen Bildern und entsprechender Datenmenge, welche schlussendlich in einen Container geschrieben wird. Teilweise klappte bei Tests im Emulator alles, teilweise bekam ich aber auch schnell eine OutOfMemoryException, weshalb mir bewusst ist, dass es zu einem Speicherengpass kommt.

Meine Frage ist nun, wie ich das am geschicktesten anstelle, dass ich die OOM-Exception umgehen kann, aber dennoch am Ende einen Container habe, in dem alle Daten drin sind? Ich dachte bereits daran, öfter vielleicht mal dann ein Flush durchzuführen, also die Daten zwischendrin zu speichern, um den Buffer zu leeren, allerdings, wie soll ich das im Code gut umsetzen? Gibt es vielleicht noch andere Tricks, um die Arbeit mit prinzipiell großen Dateien (also mindestens mal >50MB, wenn nicht gar größer) so zu gestalten, dass auch 512MB-Geräte damit klarkommen?
Was ich nicht möchte, ist 512MB-Geräte aussperren, denn einerseits gehen mir dadurch viele Nutzer verloren, da ja gerade die günstigen WPs gerne gekauft werden und andererseits ist dies unter WinRT meines Wissens nach gar nicht wirklich möglich (bei Silverlight gibt es ja entsprechend einen Eintrag im Manifest, um das zu ermöglichen)

Ich hoffe, es kann mir hier jemand helfen, denn das Problem ist relativ dringend.

Niemand ne Idee, wie ich das gut und einfach umsetzen könnte? Es bringt mir ja nichts, wenn die App crasht aufgrund mangelndem Speicher und egal, was ich tue, irgendwann führt kein Weg an nem Container vorbei, da ich ja nicht Abermillionen an kleinen Dateien verwalten will

So, ich bin jetzt wieder aus dem Urlaub retour - die erste Frage die sich mir stellt ist wie dein Code zum schreiben/suchen im Container momentan eigentlich aussieht. Kannst du da ein kompaktes Beispiel reinstellen das nur das schreiben/lesen zeigt?

Ich kann gerne ein Beispiel zeigen, allerdings geht es im Grunde so ab:

1. Öffne Container als Stream
2. Öffne nach und nach alle Dateien, die mit in den Container wandern und schreibe diese zusammen mit anderen Infos in den Container
3. Wenn alles geschrieben ist, speichere die Daten mittels StoreAsync

Das Problem dürfte bei 2. auftreten, da der Stream irgendwann zu groß wird und die Datenmenge dann das Memorylimit triggert. Falls Code gewollt ist, stelle ich dennoch mal welchen rein, aber das ist im Grunde der bisherige Ablauf.

Na ja, wenn du eine kleine Demo-Solution basteln kannst bei der das Problem auftritt dann kann sich das von uns einfach wer runterladen und durchtesten. So können wir tendenziell nur theoretisieren. Werden die geöffneten Dateien dann nach dem Abschluss der Kopie auch wieder geschlossen? Evtl. behältst du da offene Referenzen die zum Problem führen? Ansonsten wäre bei deiner Frage oben ein StoreAsync nach jeder Datei eine Variante (oder zumindest naheliegend).

Die Dateien lasse ich immer wieder schließen (benutze konsequent using-Blöcke). Ich vermute einfach, dass der Stream, in den ich schreibe, zu groß wird, um noch in die 150MB reinzupassen, weil die App an sich ja schon selbst einen Teil des Speichers belegt.

Führt denn ein StoreAsync nicht theoretisch dazu, dass es Performanceprobleme geben könnte? Auf jeden Fall wäre es doch aber theoretisch eine Belastung für den Flashspeicher.
Ich werde morgen mal noch einmal was ausprobieren und mich ggf. wieder melden.

Normalerweise wird in einen Puffer geschrieben damit der Rest des Programms nicht darauf warten muss bis der (langsame) Schreibzugriff auf den Flash-Speicher passiert ist. Das ist insbesondere dann relevant wenn die Daten die geschrieben werden von der Software selbst generiert werden - in deinem Fall ist es aber eher so dass die ja auch vom (langsamen) Flashspeicher geladen werden - da sollte die Performance nicht im großen Stil leiden (irgendwann muss es ja sowieso geschrieben werden und du rufst das ja nicht alle 1 kB auf sondern halt wenn eine sinnvolle Größe (z.B. ein Bild) zu schreiben ist).

Für den Flashspeicher ist das keine Belastung. Flash-Speicher altert jedes Mal wenn eine bestimmte Zelle geschrieben wird. Du schreibst bei mehreren Aufrufen aber nicht jede Zelle wieder sondern nur die für die neuen Daten. Ob du jetzt 1000 Zellen auf einmal schreibst oder in 10 Runden jeweils 100 Zellen ist da egal.

Generell würde ich ja meinen dass der Writer normalerweise schon von selbst in die Datei schreiben sollte bevor der Speicher überläuft (sollte ja nur ein Puffer sein und der hätte wohl eine beschränkte Größe) aber einen Versuch ist es jedenfalls wert. Sonst fällt mir gerade wie gesagt nur Memory Profiling ein um rauszufinden was wirklich so groß wird.

Sorry, dass ich den Thread hier nach Monaten wieder hochhole, aber ich habe heute Nacht nochmals das Problem gehabt und dachte mir, ich nenne hier meine Lösung, falls das für jemanden relevant sein könnte: Zu der Zeit, als das Problem auftrat, habe ich noch den DataReader und den DataWriter verwendet, um alles auszulesen und zu schreiben. Anscheinend haben beide Klasse aber ein Problem mit dem Speicherhandling, so dass die App irgendwann aufgrund des MemoryLimit gecrasht ist. Daraufhin habe ich auf die konventionellen .NET-APIs gewechselt (sprich StreamReader/-Writer bzw. in meinem Fall BinaryReader/-Writer) und war so in der Lage, auch Dateien in einem Stück zu schreiben, die weitaus größer als 150MB waren (mit den anderen APIs konnte ich mit Glück Daten schreiben, die so 80-90MB brachten bzw. ich konnte auch größere Datenmengen schreiben, wenn ich alles auf mehrere Files verteilt habe, was allerdings dennoch anfällig für Fehler war)
Ich vermute mal einfach, dass dadurch, dass DataReader/-Writer unmanaged sind, der GC nicht verwendet wird und die beiden Klassen ihren Speicher nicht schnell genug freiräumen konnten, wie der Code ihn aber gebraucht hätte.
Auf jeden Fall hoffe ich, dass diese Lösung jemandem helfen kann, der dasselbe Problem wie ich hat