OutOfMemory

Es gibt in Java verschiedene Fehlerklassen.
Exceptions sind Ausnahmezustände, die man behandeln kann, weil die gesamte Applikation dadurch nicht beeinträchtigt wird.
Errors sind Fehler, die die Lauffähigkeit der gesamten VM in Frage stellen und NICHT GEFANGEN werden sollten.

Wenn ein OutOfMemoryError auftritt, können bereits mehrere Speicheranforderungen ins Leere gelaufen sein und Objekte, von denen du erwartest, dass die gültig sind, können ins Leere zeigen ... usw, usw. Die VM ist in einem undefinierten Zustand.

Du solltest dir besser überlegen, ob du die Größe des zu ladenden Bildes vorher ermitteln kannst und ausprobieren wie groß ein Bild als Datei sein kann, um Menge X an Speicher zu benötigen. Dann enscheidest du VOR dem Laden, ob der Speicher noch reicht.

Kleiner Tipp noch am Rande:
Teste das mal mit einem Emulator. Beim Galaxy z.B. ist der maximale Heap auf 48MB pro App eingestellt. Standard ist 16. D.h. der Fehler wird eher auf den schwachbrüstigeren Geräten auftauchen, denn auf den High-End-Modellen.

Also ich hab das damals, als ich ein Speicherleck gesucht habe, mit den Standard Java Methoden gemacht.
Wenn es da in Android noch was besseres gibt...nimm evtl. das

Sonst:
http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html

freeMemory, maxMemory und totalMemory

Wobei man wissen muss, dass die Heap Größe bei Bedarf bis auf maxMemory ansteigen darf,
totalMemory den aktuellen verbrauchten Speicher ausgibt und freeMemory den freien Speicher in der aktuellen Größe der VM.

Also wenn 16 das Maximum ist, die VM aber mangels Bedarf erst 8 groß ist, wovon 7 belegt sind, wird freeMemory 1 liefern.
Interessant ist also maxMemory - totalMemory.

— geändert am 06.10.2011, 09:13:30

Diese Bitmap Error haben mich in allen Projekten immer wieder begleitet. Ich nutze derzeit mehrere Strategien:

* Handelt es sich um Images die ich nicht kenne und von denen ich erwarten muss das sie etwas größer sein werden (z:B. in meiner Gallery for Wuala App) dann missbrauche ich ein WebView Widget zur Anzeige. Solange es sich um die reine Anzeige handelt nimmt einem dieses Widget alles ab.

* Handelt es sich um Images die ich kenne und deren Größe im Thumbnail Bereich liegen dann verwende ich einen eigenen DrawableCache zur Verwaltung und füge der App eine extended Application bei. Dort fange ich die Memory Hinweise ab und veranlasse den DrawableCache sich zu shrinken bzw. zu löschen. Auch in dem DrawableCache ist eine maximale Obergrenze so dass dort jederzeit der Cache verkleinert werden kann. Das ImageView wird von mir hierzu extended und erhält ein Member zur Aufnahme der Ressource-Id. Das Nachladen erledigt dann der DrawableCache selbständig wenn ein Image gezeichnet werden soll und das Drawable aus dem Cache entfernt wurde.

* Kenne ich die Images und deren Größen und es handelt sich um fette Bilder dann werden diese von mir mit Hilfe der Factory kleiner skaliert.

Wenn man sich nicht sicher ist dann würde ich jedem das WebView zur Anzeige empfehlen. Man hat dann zwar nur rudimentäre Touchscreen Features aber für die Anzeige reicht das.

Gruß
Harald

Das tut nicht das was du erreichen willst!
Bitte genau lesen !

Jupp, so ists recht
Mit der Grenze von 100000 musst du halt mal ein bisschen rumspielen und ausprobieren...was so ein Bild tatsächlich braucht.
Gib den totalMemory aus, lade ein Bild, gib totalMemory nochmal aus.
Dann hast du den ungefähren Speicherverbrauch und solltest das mit einem Sicherheitspolster als Grenze nehmen.

Ansonsten finde ich die Ansätze von Harald sehr interessant.
Würde ich auch mal testen. Klingt jedenfalls eleganter als diese Lösung