The Android developer site also explains why SoftReference and
WeakReference are no longer a good solution. It also goes into detail on
how to developer a good solution:
http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

"In the past, a popular memory cache implementation was a
SoftReference<http://developer.android.com/reference/java/lang/ref/SoftReference.html>
 or 
WeakReference<http://developer.android.com/reference/java/lang/ref/WeakReference.html>
bitmap
cache, however this is not recommended. Starting from Android 2.3 (API
Level 9) the garbage collector is more aggressive with collecting soft/weak
references which makes them fairly ineffective."

On Thu, Apr 26, 2012 at 11:49 AM, bruce <palant...@gmail.com> wrote:

> I found that the soft references works when you are dealing with
> smaller allocations but if you deal with images, it gc()'s the
> reference took quick for it to be useful.  There used to be some
> control around what thresholds are used but that isn't a good way to
> do it anyway.  My solution was to go ahead and implement an LRU cache
> with hashmap and software references as Daniel mentions.  Then I have
> a subset of that which are have hard references to a minimal number.
> That way, I don't get immediately gc'd and for systems that work
> better I get the benefit.  If an OutOfMemoryError occurs, I can flush
> the cache, perform a couple of gc() calls, and continue.  After doing
> some performance analysis of the rest of the code, minimizing memory
> churn, making sure bitmaps are manually recycled, reduced these errors
> greatly.  I would suggest using TraceView and MemoryAnalyzer to make
> sure you really are releasing properly and just to see how the app is
> performing in general.  You might spot some problems.
>
> On 3.0+ devices you can add to your AndroidManifest, in the
> <application   />  area: 'android:largeHeap="true"'.  This gives lots
> of room for large pics (256M I believe).  I wouldn't use it if you use
> mostly small allocations because there is a performance hit with the
> large heap.
>
> Cheers,
> Bruce
>
>
> On Apr 26, 4:01 am, Daniel Drozdzewski <daniel.drozdzew...@gmail.com>
> wrote:
> > The thing is that Android OS will allocate the memory according to the
> > needs of a process (up to maximum memory allowed).
> >
> > So, if were able to establish the amount of free memory that your app
> > has available, the OS might increase this allowance as soon as you
> > allocate next bitmap, therefore the whole method makes little sense.
> >
> > Instead build a HashMap that uses soft references to build a primitive
> > cache with random eviction policy. The bitmaps will get removed as the
> > process is running low on memory. There are few good articles about
> > the usage of soft and weak references to implement primitive caches in
> > Java. This gives you a solution that will adapt to whatever memory
> > allowance is there (different per OS version) with all the memory
> > management duties shifted to the platform.
> >
> > Here is one such article:
> http://www.javaspecialists.eu/archive/Issue015.html
> >
> > Daniel
> >
> > On 25 April 2012 16:57, Anieeh <animesh.andr...@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > Hi all
> > >    I am having problem with releasing memory problem, i have a
> > > Hashmap in which i am adding Bitmap object, and the no. of bitmaps are
> > > quite large. for this reason i am getting "OutOfMemoryError". So for
> > > this i have decided to release Bitmap whic is least used from
> > > Collection, on memory crunch or system getting low heap memory.
> > >  For getting current memory available i used
> > > "ActivityManager.MemoryInfo.availMem" but it gives total RAM size
> > > memory, not Available Heap memory. And i found that this memory is not
> > > getting updated on releasing  Bitmap from collection.
> >
> > > Then i have used these three method
> > > "Debug.getNativeHeapAllocatedSize()"
> > > "Debug.getNativeHeapFreeSize()"
> > > "Debug.getNativeHeapSize()"
> >
> > > but found the NativeHeapSize goes on increasing upto some certain say
> > > 16MB changing after that an "outOfMemoryError" occur. In this also i
> > > found that the NativeHeapAllocatedSize and getNativeHeapSize not
> > > decreasing on releasing  Bitmap from collection.
> >
> > > So please help me for solving the problem if anyone facing the same
> > > problem and fixed earlier it.
> >
> > > My problem is i want to calculate "Max Available application memory
> > > allocated" and "currently available memory", for such that if
> > > "currently available memory" goes beyond the Threshold memory i will
> > > release some Bitmap from the collection and GC will reclaim the memory
> > > and free it without generating error.
> >
> > > Thanks in advance
> > > Anieeh
> >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Android Developers" group.
> > > To post to this group, send email to
> android-developers@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > android-developers+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > >http://groups.google.com/group/android-developers?hl=en
> >
> > --
> > Daniel Drozdzewski
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to