AndroidStudio & LruCache

Hallo liebe Gemeinde,

ich baue meine Custom ListViews/Baseadapter mir LruCache auf.
Sinn und Zweck ist soweit ja bekannt ,

Was mich allerdings ein wenig verwundert :

Wird im getView eine ImageRecource der LruChache auf einen ImageView gesetzt, so scheinen diese nachwievor alle
im Speicher zu bleiben und erhöhen den Memory Verbrauch. (lt Aussage des Monitors -> Memory im AS)

Ergo , es wird offensichtlich kein free auf die nicht sichtbaren Items durchgeführt.
Wird die ImageResource nicht gesetzt, bleibt der Verbrauch gleich

Weis jemand von euch hierzu etwas Genaueres ?


Lieben Dank

Stefan

Und warum sollte der Speicher geleert werden? Du erzeugst Inseln im Speicher. Objekte die eine Referenz halten, werden nicht gelöscht. Besser du arbeitest mit den Methoden view.setTag() und view findViewByTag().

View | Android Developers
https://developer.android.com/reference/android/view/View.html#findViewWithTag(java.lang.Object)

Hallo Markus,,

ich danke dir .... mit setTag/getTag arbeite ich bereits

Ich habe jetzt herausgefunden , dass wirklich nur der speicher beansprucht wird, der auch an Items angezeigt wird.
(und ein bischen davor und ein bischen dahinter)
Die getView meldet sich dann schon , wenn es Elemente aus meinem Cache beim scrollen benötigt.

Was mich allerdings ungeachtet dessen noch stutzg macht .
Die Bitmaps , die ich in das ImageView eines Items setze, haben im Rawformat nur um die 2 k.(Thumbnails)
Allerdings werden an die 15 MB für ca 10 Einträge angezeigte Items reserviert. (je 80 x 80 pixel)
Passiert da irgendwas im Rendering ???

Wohlbemerkt, ich vertraue mal bei der Aussage auf die Eieruhr in AS

lg
Stefan

Die Bilder sind ja gepackt. Um den Inhalt zu lesen, muss die App das Bild entpacken. Und Bitmaps sind relativ groß. 15 MB ist aber schon sehr viel. Was passiert, wenn du mehrmals hintereinander den Screen aufrufst. Wächst der Speicherbedarf?

Hallo Markus,
du hast den entscheidenden Hinweis gegeben

Ich bin feste davon ausgegangen , dass ein Bitmap-Objekt bereits die decomprimierte raw-variante ist (so wie ich es unter C kenne)
Sie scheint allerdings nur ein Holder für die gepackte Variante des Files zu sein und wird erst beim Draw entpackt bzw gerendert.
in meinem Falle ist dann das Bitmap im raw dann 250 x 250 x 4 = 250 KB mal die 10 Images = das kommt dann hin ..

Ich nehme jetzt ein resize auf meine tatsächlich benötigte Größe bereits im Loader AsyncTask vor und schon komme ich nach unten ..

Lieben Dank für deinen Kick

Manchmal braucht man einen , der einem die Türe aufmacht

lg
Stefan

Oder jemand, der mal ein ähnliches Problem hatte.

Das wäre schon Punkt zwei

AsyncTask und Longlife und dieses hier