Finding the "killer" memory caching mechanism for Android [closed]

Question

Background

Android has a very limited max heap size, each device has a different max heap.

Some apps need the ability to cache things (usually images) in memory and not only on the internal/external storage.

Of course, there are plenty of nice tips regarding handling bitmaps and using as little memory as possible, but caching is also a needed thing.

The problem

I've read many possible solutions for caching, but none offer a kind of caching that would be a killer caching solution. What I would like to have is a caching mechanism that has the next features:

1. Unlimited usage of the heap, without worrying about out of memory. App needs memory and there isn't enough free memory? so free some (unreferenced) items (and their keys).

2. Thread safety / concurrency.

3. Offer LRU based caching, so that items that were recently used have higher chance of staying.

4. Staying alive as much as possible (yet not cause any crashes). However, sadly, on Android, soft/weak references are GC-ed very quickly compared to Java.

5. Ability to handle objects that hide their real size. On Android, on API 10 and below, bitmaps didn't use the heap memory but were considered as such, so the VM couldn't know when to free them since it thought the use the same amount of memory as a single reference (4 bytes or so). This is why some solutions offer to artificially tell what is the size of each item, and what to do when it's time to remove it.

Some good possible solutions

1. LruCache - a class from API 12 (you can easily copy its code though).

   Advantages: #2 (?), #3, #5.

   Disadvantages: #1, #4, plus you need to copy its source code since it was presented on API 12.

2. A hashmap with a soft/weak reference for its values, as shown here on page 50, taken from this lecture.

   Advantages: #1 (but doesn't remove keys), #2 (need to use ConcurrentHashMap)

   Disadvantages: #3, #4, #5

3. MapMaker (available from the guava library), which is like an advanced version of the previous solution.

   Advantages : #1, #2

   Disadvantages: #3, #4, #5

4. Caching solutions via the guava library. Advantages and disadvantages are based on your choice. Not sure which configurations fits the needs the best, and if it works fine on Android. Sadly I can't succeed even compiling the library for Android.

5. Android query - not sure how it works. Seems very easy to use, but not sure about its advantages and disadvantages.

Question

Does anybody know of a killer caching mechanism?

I care less about feature #5, as it's quite advanced and won't be so much needed in the future as more and more people have newer Android versions.

Answer 1

As I can see there is a practical prohibiting issue with #1. You cannot free objects that are referenced from other parts of the app; therefore, it is impossible to create a construct that frees memory on will.

The only solution I see is creating your own cache that supports LRU and is able to handle both weak and strong references. An item starts as a strong referenced thing and if not used for a while, or memory constraints enforce, you change it to a weak reference. This is not simple to create and fine tuning has to be done for sure in all applications.