I have many pictures in my #drawable directory which are connected to xml layout via background property:
i.e
<ImageButton android:background="#drawable/background1" ... />
I have many activities, so, when activity is destroyed (BACK is pressed), the heap isn't freed. So, the question is:
Does android load everything in the memory once and make heap free only when application is destroyed? How I can prevent in this case memory consumption ? Only through image compression or dynamically loading background and images?
I think Android has a its own garbage collector, but for proceed it its take sometimes instead of relevent momory as the object is not in use. And whenver the bitmap is created its memory occupied in native heap and heap garbage collector is to lazzy.
So if possible use dynamic Image loading instead of static, and try to use your own recycler or freed the memory of your bitmap.
EDIT:
The gc() does not handle so-called short lived objects as fast as we
would like.
Keep the number of view objects at a stable level*, and recycle them instead of destroying and creating new ones.
A nice post of Avoiding memory leaks by Roman Guys refer it.
If I am wrong please let me know. And please share some more information on this.
Thanks.
Related
In android app, images can be changed through run-time (e.g. layout-bg, ImageButton-src, Button-bg, ..etc), so what happens to the old image in the terms of memory occupation? is it removed or still occupy a portion from the memory? and if it's not removed, how can I clear the memory from this image?
UI part of android is mainly written in Java -- once all references to a bitmap is gone, the bitmap will be flagged for garbage collection. If you do not use a bitmap texture, and you have no reference to that bitmap anywhere in the code the memory will be freed immediately. Please be careful about memory leak in android. Read this:
http://android-developers.blogspot.ca/2009/01/avoiding-memory-leaks.html
I work with several large drawables and I don't know how to manage memory leaks.
I tracked the heap size of my application and it doesn't stop to grow (as the allocated memory).
It is especially the "byte array (byte[])" type which grows up and never decrease. (in the DDMS Heap view on Eclipse)
My application is composed of one activity which uses fragments.
Those fragments are displaying several large images.
I tried to set drawables callback to null, set drawables to null, clear my volatile cache (which prevent my app from doing too many disk IO) when I pop back a fragment but the heap never decrease.
In fact, each time I call :
Drawable.createFromResourceStream(context.getResources(), value, new FileInputStream(f), f.getName(), opts);
the heap grows up. How can I free memory ?
Thanks !
A memory leak happens when Java finds objects in the memory that are referenced by your code which is preventing the Garbage Collector from freeing this memory. A common cause in Android is referencing the Activity context rather than the Application context. Make sure your context references the Application (i.e. use getApplicationContext rather than using this. Check this video for explanation on Memory leaks and also check this question.
The question seems answered but a post by Romain Guy seems relevant to get more info: Avoiding Memory Leaks.
Apparently, if you (for example) set a drawable as a background image to a text view by using setBackgroundDrawable* (thus attaching the drawable to the view) then change the orientation (destroying the Activity and redrawing the UI) the drawable will still have access to the old activity (after the old activity's destruction), thus creating a memory leak.
*(as a side note - setBackgroundDrawable has been deprecated since API level 16)
Here are some newbie memory management observations to which I would like
hear an experienced opinion.
It seems that setting android:backgound="#drawable/xyz" in a xml
layout causes memory loss in my app. The respective activities keep
stacking up until I get an OOM error. This is especially true if I rotate
the device orientation.
However, if I load the same resource with setBackgoundResource(), and then clear the
callback and set the background reference to null, there is no leak whatsoever.
that is, first in onCreate()
mMainLayout.setBackgroundResource(R.drawable.background_general_android);
and then in onDestroy()
mMainLayout.getBackground().setCallback(null);
mMainLayout.setBackgroundDrawable(null);
Is this roughly correct, or am I missing something essential?
This would only happen if you keep a copy of the drawables in a static cache for instance. You might also be leaking your activities and setting the drawables to null simply hides the problem for a little longer. You should use a tool like MAT to inspect the content of your heap and figure out what's going on.
My app uses some bitmaps with a SurfaceView. For bitmaps that a recalled often I stored them as class fields, i.e. when my extension of SurfaceView instance is created I have
bitmap_puppyicon = BitmapFactory.decodeResource(getResources(),R.drawable.puppy);
Where bitmap_puppyicon is a class variable of my extended SurfaceView. WHich means, I think, it is on the heap.
For bitmaps that are used once or twice or so, I created them on the fly in the onDraw() method.
I checked out the heap in DDMS and felt I could afford to store more bitmaps as class variables instead of creating them in onDraw().
To my surprise the heap size went down a few percentage points after doing this. Have I misunderstood something? Why would the heap get smaller with more bitmaps stored?
It use skia under the hood, and heap is not the place where bitmaps live, In the heap you have links to bitmaps only
I try to implement a Gallery where each item is a big image for a good zomm-in function.
The problem is the management of the memory.
When i try to go to the fourth element android goes to Out Of Memory, so i try to recycle the images not displayed, but android goes to RunTimeException for try to use a recycled image when i come back.
Also i try to change the bitmap of the bigs images not displayed with bitmap of small images but always goes to Out Of Memory.
How can i do, for manage the memory of the Gallery?
After you do call recycle(), make sure you don't use that Bitmap reference again as that will cause a runtime exception if certain methods are invoked. Try using SoftReferences wrapped around your bitmaps. This will guarantee that all of the memory that is no longer references will be reclaimed before an OutOfMemoryError is thrown.