Bitmap Recycle with Largeheap Enabled

Bitmap memory leaks

In any android version whether it is froyo,gingerbread or honeycomb. You have to check yourself for memory management. Yes, from 2.2+ you can adjust you application from sdcard, but keeping the bitmaps in heap memory, always will create problem for whether you use either version. If you want pure using of bitmaps, then why dont you follow their way, try this link. They have given you many ways to managing the bitmaps efficiently. Follow this link:
Displaying bitmaps efficiently

What are advantages of setting largeHeap to true?

Way too late for the party here, but i will offer my 0.02$ anyways.

It's not a good idea to use android:largeHeap="true" here's the extract from google that explains it,

However, the ability to request a large heap is intended only for a
small set of apps that can justify the need to consume more RAM (such
as a large photo editing app). Never request a large heap simply
because you've run out of memory and you need a quick fix—you should
use it only when you know exactly where all your memory is being
allocated and why it must be retained. Yet, even when you're confident
your app can justify the large heap, you should avoid requesting it to
whatever extent possible. Using the extra memory will increasingly be
to the detriment of the overall user experience because garbage
collection will take longer and system performance may be slower when
task switching or performing other common operations.

here's the complete link of the documentation
https://developer.android.com/training/articles/memory.html

UPDATE

After working excrutiatingly with out of memory errors i would say adding this to the manifest to avoid the oom issue is not a sin, also like @Milad points out below it does not affect the normal working of the app

UPDATE 2

Here are a few tips to deal with out of memory errors

1) Use these callback that android gives onLowMemory, onTrimMemory(int) and clear the cache of image like (picasso, glide, fresco....) you can read more about them here and here

2) compress your files(images, pdf)

3) read about how to handle bitmap more efficiently here

4) Use lint regularly before production pushes to ensure code is sleek and
not bulky

Bitmap recycle in finalize method not working properly

If you're that close to using the max size of the heap, you may just be getting lucky (or unlucky). Calling recycle() directly vs. calling it from the finalizer may change the timing and behavior of the GC in such a way that you see differences.

Are you certain that your finalizer (and recycle()) are being called before you try re-allocating the bitmap? Finalizers are unreliable, and can be deferred indefinitely. Even if it you currently see the finalizer being called before re-allocation during your testing, there's no guarantee that this will always happen (especially for different heap states or future/different versions of Dalvik).

If you can, try as hard as you can to call recycle() from outside of the finalizer. If you know when you're done, just call the method; otherwise consider using a ReferenceQueue (https://stackoverflow.com/a/10879076/150001).

It's been a while since I looked at Dalvik, but I seem to remember that bitmap buffers could take a few GC cycles to be cleaned up, because the VM needed to be sure that no native code had any remaining pointers into it. So, the buffer may not be freed exactly when you expect it to be.

There's also the possibility that heap fragmentation is causing a problem, though there's a good chance that large buffers are allocated using mmap() and will not contribute to fragmentation (again, depending on the current version of Dalvik).

Bitmaps in Android

The memory that backs a Bitmap object is allocated using native code (malloc()), rather than the Java new keyword. This means that the memory is managed directly by the OS, rather than by Dalvik.

The only real difference between the native heap and Dalvik's heap is that Dalvik's heap is garbage collected, and the native one isn't.

For these purposes though, here's not much difference. When your Bitmap object gets garbage collected, it's destructor will recycle the associated memory in the native heap.

Source:

  • http://osdir.com/ml/AndroidDevelopers/2009-03/msg00023.html
  • android:platform/frameworks/base/graphics/java/android/graphics/Bitmap.java
  • android:platform/frameworks/base/core/jni/android/graphics/Bitmap.cpp

Asynchronous download of Bitmaps in an Adapter, with emphasis on Bitmap.recycle()

In the end, I chose to disregard the recycling bug entirely. it just adds a layer of impossible difficulty on top of a manageable process.

Without that burden (just making adapters, etc stop showing images), I made a manager using Map<String, SoftReference<Bitmap>> to store the downloaded Bitmaps under URLs.

Also, 2-4 AsyncTasks (making use of both doInBackground and onProgressUpdate; stopped by adding special jobs that throw InterruptedException) taking jobs from a LinkedBlockingDeque<WeakReference<DownloadingJob>> supported by a WeakHashMap<Object, Set<DownloadingJob>>.
The deque (LinkedBlockingDeque code copied for use on earlier API) is a queue where jobs can leave if they're no longer needed. The map has job creators as keys, so, if an Adapter demands downloads and then is removed, it is removed from the map, and, as a consequence, all its jobs disappear from the queue.

A job will, if the image is already present, return synchronously. it can also contain a Bundle of data that can identify which position in an AdapterView it concerns.

Caching is also done on an SD card, if available, under URLEncoded names. (cleaned partially, starting with oldest, on app start, and/or using deleteOnExit()

requests include "If-Modified-Since" if we have a cached version, to check for updates.

The same thing can also be used for XML parsing, and most other data acquisition.

If I ever clean that class up, I'll post the code.

how to solve out of memory bitmap size exceeds exception in android

You use memory heap more than gcc allowed size. You must use slaced bitmaps
or
+3.0 in manifest add application

android:largeHeap="true" to allocate more heap size.

<application
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
android:largeHeap="true">...


Related Topics



Leave a reply



Submit