Android: Wie funktioniert Bitmap recycle ()?

Angenommen, ich habe ein Bild in ein Bitmap-Objekt wie geladen

Bitmap myBitmap = BitmapFactory.decodeFile(myFile);

Was passiert nun, wenn ich eine andere Bitmap wie lade?

myBitmap = BitmapFactory.decodeFile(myFile2);

Was passiert mit der ersten myBitmap? Wird es Garbage Collected oder muss ich es manuell sammeln, bevor ich eine andere Bitmap lade, z. myBitmap.recycle()?

Gibt es auch eine bessere Möglichkeit, große Bilder zu laden und nacheinander anzuzeigen, während Sie unterwegs recyceln?

Die erste Bitmap wird beim Dekodieren der zweiten nicht als Müll gesammelt . Garbage Collector wird es später tun, wann immer es entscheidet. Wenn Sie so schnell wie möglich Speicher freigeben möchten, sollten Sie recycle()kurz vor dem Dekodieren der zweiten Bitmap aufrufen .

Wenn Sie ein wirklich großes Bild laden möchten, sollten Sie es erneut abtasten. Hier ein Beispiel: Seltsames Speicherproblem beim Laden eines Bildes in ein Bitmap-Objekt .

Ich denke, das Problem ist folgendes: In Vor-Honeycomb-Versionen von Android werden die tatsächlichen Bitmap-Rohdaten nicht im VM-Speicher, sondern im nativen Speicher gespeichert. Dieser native Speicher wird freigegeben, wenn das entsprechende Java- BitmapObjekt GC-fähig ist.

Allerdings , wenn Sie von nativem Speicher ausgeführt wird, wird die Dalvik GC nicht ausgelöst, so ist es möglich , dass Ihre App nutzt sehr wenig von der Java - Speicher, so der Dalvik GC wird nie aufgerufen, aber es Tonnen von nativem Speicher verwendet für Bitmaps was schließlich einen OOM-Fehler verursacht.

Zumindest ist das meine Vermutung. Zum Glück werden in Honeycomb und höher alle Bitmap-Daten in der VM gespeichert, sodass Sie sie überhaupt nicht verwenden müssen recycle(). Aber für die Millionen von 2,3 Benutzern (Fragmentierung schüttelt die Faust ) sollten Sie verwenden, recycle()wo immer dies möglich ist (ein massiver Aufwand). Alternativ können Sie stattdessen den GC aufrufen.

Sie müssen myBitmap.recycle () aufrufen, bevor Sie das nächste Bild laden.

Abhängig von der Quelle Ihrer myFile (z. B. wenn Sie keine Kontrolle über die Originalgröße haben) sollten Sie beim Laden eines Bildes, anstatt nur eine beliebige Zahl neu abzutasten, das Bild auf die Anzeigegröße skalieren.

if (myBitmap != null) {
    myBitmap.recycle();
    myBitmap = null;
}
Bitmap original = BitmapFactory.decodeFile(myFile);
myBitmap = Bitmap.createScaledBitmap(original, displayWidth, displayHeight, true);
if (original != myBitmap)
    original.recycle();
original = null;

Ich speichere displayWidth & displayHeight in einer Statik, die ich zu Beginn meiner Aktivität initialisiert habe.

Display display = getWindowManager().getDefaultDisplay();
displayWidth = display.getWidth();
displayHeight = display.getHeight();

Nachdem die Bitmap in den Speicher geladen worden war, wurde sie tatsächlich aus zweiteiligen Daten erstellt. Der erste Teil enthält einige Informationen über die Bitmap, der andere Teil enthält Informationen über die Pixel der Bitmap (sie besteht aus einem Byte-Array). Der erste Teil existiert im verwendeten Java-Speicher, der zweite Teil existiert im verwendeten C ++ - Speicher. Es kann den Speicher des anderen direkt verwenden. Bitmap.recycle () wird verwendet, um den Speicher von C ++ freizugeben. Wenn Sie dies nur tun, sammelt der GC den Teil von Java und der Speicher von C wird immer verwendet.

Timmmm hatte recht.

laut: http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

Darüber hinaus wurden vor Android 3.0 (API Level 11) die Sicherungsdaten einer Bitmap im nativen Speicher gespeichert, der nicht vorhersehbar freigegeben wurde. Dies kann dazu führen, dass eine Anwendung kurzzeitig ihre Speichergrenzen überschreitet und abstürzt.