Boehrsi.de - Blog

Programmieren und gut bzw. optimiert programmieren sind leider nicht immer einerlei und somit möchte ich mal auf einige Dinge eingehen, welche mir im Bezug auf Optimierung bei der Software-Entwicklung so aufgefallen sind. Dies wird meine eigenen Projekte betreffen, bzw. Software die ich kenne oder mit der ich Erfahrungen sammeln konnte. Es wird also keinen allgemeinen “How To’s” geben, solltet ihr aber etwas wissen wollen oder Fragen haben, gehe ich darauf sehr gerne ein. Also zögert nicht einfach zu fragen! Als erstes Thema möchte ich heute auf meine App FileSize eingehen und auf ein konkretes Speicher-Problem, welches ich dort hatte (Stichwort: Speichermangel durch mieses Speichermanagement). Vorweg noch der Hinweis ich rede hier über Coding und dementsprechend kann es sein, dass ohne etwas Grundwissen einiges nicht direkt verständlich ist. Falls ihr dort Fragen habt, versuche ich natürlich auch in diesem Kontext zu helfen.

Wie erwähnt geht es heute um meine App FileSize, welche große Dateien auf eurem Androiden entdeckt und ermöglicht diese zu entfernen. Denn man sollte immer mal wieder sein Smartphone aufräumen, weil auch 16 oder 32GB schnell mal voll sind.

Um dies zu bewerkstelligen durchsucht die App alle Dateien, ausgehend von einem zuvor gewählten Ordner. Dafür wählte ich beim ersten Ansatz einen simplen rekursiven Ansatz und speicherte die Elemente in einer ArrayList. Dort wurde dann nach Größe sortiert und das Ergebnis dem Nutzer präsentiert. Dies funktionierte sogar recht lange ohne Probleme, doch dann sah ich in meiner Developer Konsole App Abstürze, aufgrund von zu wenig verfügbarem Arbeitsspeicher. Als ich das Problem dann grundsätzlich betrachtete, wurde mir schnell klar das ich hier ziemlich unsicheren Kram programmiert hatte. Denn ließt man alle Dateien und Ordner eines Geräts ein, kommt man schnell in eine missliche Lage, sofern man sich nicht um die Speicherverwaltung kümmert. Ich änderte nach etwas Recherchen also meinen Ansatz. Dabei wechselte ich auf eine iterative Lösung (Stichwort: BFS open_in_new und DFS open_in_new), welche nicht auf einer Liste (ArrayList open_in_new), sondern auf einer Warteschlange (ArrayDeque open_in_new) arbeitet. Ich verarbeite nun immer das erste Element der Warteschlange. Im Falle eines Ordners werden alle Elemente des Ordners vorne in der Liste eingefügt und der Ablauf beginnt von vorn. Im Falle einer Datei wird zu erst die Ausgabeliste bis zum maximalen Wert gefüllt (z.B. 25 Dateien). Sobald die Liste voll ist, wird bei größeren Dateien die jeweilige Datei in die Ausgabeliste eingefügt und die kleinste aus der Liste entfernt. Dies geschieht einfach und ohne großen Aufwand durch eine sortierte Warteschlange (PriorityQueue open_in_new) und eine dafür erstellte Vergleichsfunktion (Comparator open_in_new). Hier kann man nun natürlich variieren und z.B. Objekte eines Ordners ans Ende der Warteschlange anhängen, anstatt sie vorne einzufügen, aber nach meinen Versuchen und Überlegungen gefiel mir diese Lösung am Besten. Doch warum ist dies besser als die vorherige Lösung? Eigentlich ganz einfach, jedes Element was ich verarbeite wird direkt aus der Warteschlange entfernt und ich arbeite erst bestimmte Bereich ab, anstatt alles auf einmal zu laden und dabei zu betrachten. Außerdem nutze ich vom System bereitgestellte Dateitypen, die optimierter und grundsätzlich für diesen Einsatzzweck gedacht sind (Stichwort: Automatische Sortierung). Auf diese Art und Weise konnte ich die Performance um mindestens 50 Prozent steigern und die Speichernutzung um mindestens 80 Prozent reduzieren. Dies ist vor allem bei günstigeren Smartphones, mit weniger guter Hardware, sehr spürbar und selbst bei meinem Nexus 5 war ein großer Unterschied bemerkbar.