Voller als voll

Wenn der Speicher voll ist, wirft Java bekanntlich einen OutOfMemoryError:

Oha.

Tatsächlich kann der Speicher sogar so knapp werden, dass er nicht einmal genügt, um ein Objekte der Klasse OutOfMemoryError zu erzeugen …

Wer genau hinschaut, kann sehen, dass der Fehler von com.android.vending geworfen wurde, also dem Play Store auf einem Android-Smartphone. Einem virtuellen allerdings, denn das Ganze ist beim Vorveröffentlichungs-Test einer App passiert.

Exkurs

Kleiner Exkurs über Speicher unter Java?

Nein … nur ein klitzekleiner, das Thema ist so groß, dass es gerade nicht in meinen Arbeitsspeicher passt.

Beim Start müssen wir der virtuellen Maschine von Java einen gewissen Spielraum einräumen – Speicher, der dann dem Programm zur Verfügung steht, sei es für Bytecode oder Objekte (es ist wirklich kompliziert). Der Garbage Collector ist ja einer der Hauptgründe, Java zu verwenden, weil er die Entwicklung so schön einfach macht. Programmierer müssen sich keine Gedanken darüber machen, wann sie ihre erzeugten Objekte wieder wegschmeißen müssen. Der Preis ist natürlich, dass der Garbage Collector Rechenzeit verbraucht – und das kann beim Verzicht auf Optimierungen durchaus merkliche Auswirkungen haben.

Zu viel Dingsbums

Beispiel Spiele: Normalerweise besitzen Spiele einen Renderer, der 30 mal pro Sekunde (oder öfter) den Bildschirm neu zeichnet. Da normalerweise bewegliche Dingsbums mit von der Partie sind, müssen Berechnungen stattfinden. Zum Beispiel sind Vektoren zu addieren, etwa so:

Vector3 newLocation = new Vector3(move(dingsbums,oldLocation,timePassed));
drawAt(dingsbums,newLocation);

Die erste Zeile erzeugt ein neues Objekt (newLocation) auf dem Heap. Am Ende der Zeichenfunktion ist es überflüssig, d.h. der Garbage Collector wird es irgendwann wegräumen. Jetzt stellen Sie sich vor, dass deutlich mehr als ein Dingsbums auf dem Bildschirm ist. Alle müssen sich bewegen, für jedes entsteht ein neues Vector3-Objekt, und das 30 mal pro Sekunde. Sie können sich leicht ausrechnen, wie viele Objekte der Garbage Collector letztlich aufzuräumen hat. Schlimmstenfalls macht sich das als Ruckeln bemerkbar, auf jeden Fall verbraucht es Prozessorzeit und damit Energie (also Akkuladung).

Besser ist es also, Objekte wiederzuverwenden. Dingsbums sollte über einen permanenten Vector3 verfügen, nur dessen Koordinaten (vielleicht native floats) ändern sich noch:

move(dingsbums,timePassed);
drawAt(dingsbums.getLocation());

Profilieren

Sie können mit Android Studio im Profiler genauso wie mit Java-Tools wie jmx die Aktivität des Garbage Collectors verfolgen. Ein guter Hinweis ist ein zackiger Sägezahnverlauf der Speicherbelegung. Wird der GC sehr oft aktiv, deutet das auf Optimierungspotenzial hin. Der Profiler zeigt dann an, in welchem initializer besonders viel Zeit draufgeht – damit wissen Sie, welche Objekte womöglich zu oft erzeugt werden.

Bekanntlich beträgt der Anteil der CO2-Ausstoßes der IT weltweit mit ihren ganzen Rechenzentren geschätzt 10-20%. Je effizienter Ihre Anwendung arbeitet, umso weniger ist sie daran schuld. Klingt vielleicht banal, aber nicht wenn Ihre App auf Milliarden Smartphones installiert ist und milliardenfach verwendet wird (und das wollen Sie doch, oder?).

Mehr zum Thema Speicherverbrauch und Effizienz in naher Zukunft und in der nächsten Auflage meines Buchs “Besser coden”.

Android: Speichern ohne Genehmigung

Ein Appetizer aus meinem in Kürze erscheinenden Buch: Android-Apps entwickeln für Einsteiger (8. Auflage).

Von Ihrem PC kennen Sie den »Speichern unter«-Dialog. Jede installierte Anwendung funktioniert in dieser Hinsicht gleich: Sie überlässt Ihnen als Nutzer die Entscheidung, wo ein Dokument landen soll und unter welchem Namen.

Tatsächlich existiert ein solcher Dialog auch unter Android, bloß verwenden ihn nur wenige Apps. Dabei hat das sich dahinter verbergende Storage Access Framework sogar einen immensen Vorteil: Es kommt ohne die Genehmigung zum Speichern von Dateien auf der SD-Karte aus!

Lassen Sie uns als Beispiel einen Mini-Editor schreiben, der es dem Nutzer erlaubt, einen Text einzugeben und ihn mittels Storage Access Framework zu speichern. Dieser bescheidene Funktionsumfang rechtfertigt eigentlich nur den Projektnamen MiniMiniEditor.

Achten Sie darauf, beim Anlegen des Projekts die minSdkVersion auf 19 zu stellen (Android 4.4), denn zuvor existierte das Storage Access Framework noch nicht.

Schalten Sie außerdem die Unterstützung für Java 8 ein, da die folgenden Codezeilen eine Methodenreferenz verwenden.

Verwenden Sie im Layout activity_main.xml ein vertikales LinearLayout, und setzen Sie einen Speichern-Button und ein EditText hinein. Damit letztere View den gesamten verfügbaren Platz ausfüllt und mehrzeiligen Text entgegennimmt, setzen Sie die Attribute wie folgt:

 <EditText android:id="@+id/text"  android:layout_width="match_parent" android:layout_height="0dp"  android:gravity="top|left"  ndroid:layout_weight="1" android:inputType="textMultiLine" />

In der Klasse MainActivity verknüpfen Sie zunächst den EditText mit der festgelegten ID text mit einem Attribut editText und den Button mit einem Listener:

editText = findViewById(R.id.text); 
findViewById(R.id.save).setOnClickListener(this::onSaveClicked);

Wenn der Nutzer auf den Speichern-Button drückt, basteln Sie ein spezielles Intent-Objekt:

Intent intent = new Intent(Intent.ACTION_CREATE_DOCUMENT); 
intent.addCategory(Intent.CATEGORY_DEFAULT); intent.setType("text/plain");
intent.putExtra(Intent.EXTRA_TITLE, "");
startActivityForResult(intent, REQUESTCODE_SAVE);

Entscheidend ist hier die Action ACTION_CREATE_DOCUMENT. Als EXTRA_TITLE können Sie einen Dateinamen vorgeben, den der Nutzer noch ändern kann.

Was Sie hier nicht sehen, ist der eingegebene Text: Der wird nicht etwa an den Intent gehängt, sondern in einem zweiten Schritt gespeichert. Dadurch erhält die Dateiauswahl nie Zugriff auf die fraglichen Daten. Für das eigentliche Speichern sind Sie selbst zuständig.

Deshalb starten Sie den Intent mit startActivityForResult() und übergeben einen frei definierbaren Request-Code.

Der Storage Access Provider horcht mit einem Intent-Filter darauf und präsentiert dem Nutzer einen Auswahldialog.

Standardmäßig zeigt der Speichern unter-Dialog nicht viele mögliche Ziele an: meist nur das Downloads-Verzeichnis und Ihr Google Drive, falls vorhanden. Aber hinter dem Zahnrad rechts oben erreichen Sie den Einstellungen-Dialog, wo Sie mit Erweiterte Geräte anzeigen dafür sorgen können, dass auch Ihr interner Speicher sowie eine eventuell eingesetzte SD-Karte erscheinen. Die meisten neueren Android-Geräte zeigen hier auch USB-Speichermedien an, die Sie einstöpseln.

Sobald der Nutzer das gewünschte Ziel ausgewählt hat, sendet das Storage Access Framework Ihrer Activity ein Ergebnis. Das nehmen Sie entgegen, indem Sie die Methode onActivityResult() überschreiben:

 public void onActivityResult(int requestCode, int resultCode, Intent resultData) { }

Da an dieser Stelle grundsätzlich ganz unterschiedliche Mitteilungen eintreffen können, müssen Sie den requestCode mit Ihrer Definition vergleichen. Der resultCode verrät Ihnen, ob der Nutzer den Vorgang erfolgreich beendet hat – nur dann möchten Sie etwas speichern:

if(requestCode==REQUESTCODE_SAVE
&& resultCode==Activity.RESULT_OK) {
}

Das Storage Access Framework übergibt Ihnen im Intent resultData das Ziel für Ihre Datei, und zwar in Form einer URI:

Uri
uri = resultData.getData();

Diese URI zeigt auf einen Dateipfad, aber dessen genauer Ort muss Sie nicht interessieren. Sie verwenden lediglich den ContentResolver, um sich einen OutputStream zu beschaffen, der Ihre Daten an die richtige Stelle schreibt. Das Storage Access Framework sorgt dafür, dass Sie temporär die nötigen Schreibrechte besitzen, obwohl Ihre App keinerlei Genehmigung zum Schreiben auf den Datenträger besitzt.

Der Schreibvorgang funktioniert im Fall von Textdaten am einfachsten über einen PrintWriter:

 try {
OutputStream stream = getContentResolver().openOutputStream(uri);
PrintWriter writer = new PrintWriter(stream);
writer.write(editText.getText().toString());
writer.flush();
stream.close();
} catch (java.io.IOException e) {
Log.e(getLocalClassName(),"caught IOException",e);
}

Das war schon alles. Natürlich können Sie dem Nutzer jetzt noch eine Erfolgsmeldung zeigen (und im Fehlerfall eine Fehlermeldung), aber das überlasse ich Ihnen.

Das Storage Access Framework kann auch dazu dienen, vorhandene Dateien zum Öffnen auszuwählen, z. B? Mediendateien. Als Intent-Action verwenden Sie dann ACTION_OPEN_DOCUMENT, der Rest funktioniert analog – ebenfalls ohne irgendwelche Permissions. Letztlich entscheidet der Nutzer im Einzelfall darüber, auf welche Dateien Ihre App zugreifen darf, deshalb ist die allgemeine Permission verzichtbar – das ist durchaus manchmal ein Vorteil, denn viele skeptische Nutzer installieren nur Apps, die möglichst wenige Genehmigungen einfordern.

Diese und viele andere nützliche Tipps finden Sie in meinem Buch: Android-Apps entwickeln für Einsteiger (8. Auflage), erschienen im Rheinwerk-Verlag