IssueTracker

Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

We are closing this issue based on above comment, Thanks

Thanks. I checked with my colleague, and http://b/36933020 is obsolete on ART runtime.

However, SoftReference is not recommended. ART GC usually reclaims SoftReferences only during a last ditch, avoid-OOME, block-the-allocation collection. But at that point, things have gotten rather janky already.

LruCache is still the best solution.

@9 So if you agree that SoftReference shouldn't be used for Android, as in the docs (and in other places) from many years ago, why close this?

LruCache isn't the best solution because it is not efficient at all, and can still cause OOM.

The best solution would be what I wrote, to have a cache that can expand and shrink automatically by how the framework dictates that's allowed, so it prevents OOM while allowing absolute maximal memory usage for the cache.

Not to mention that Bitmaps have made the situation even weirder on Android, as they aren't saved on the heap memory anymore (was in the past, which could cause OOM, but at least you could manage it). Yet if you use a lot of memory by Bitmaps, you can't catch any exception/error of it, so it makes it even impossible to manage with LruCache, as it's unknown what's the max memory that the app can use that is outside of the heap memory...

@9 I requested to have a better LruCache that has no clear boundaries, not the existing one. I've presented the disadvantages and you've ignored them all, while agreeing about alternatives that shouldn't be used.

And then you just say "best is LruCache". How is X better than X ? It's illogical conclusion...

@9 You also say 36933020 is obsolete , yet you reached the same conclusion that Google wrote there:

https://issuetracker.google.com/issues/36933020#comment2

So nothing has changed and this is why I request for a better solution.

I think that you pointed out the known caveat of LrcCache, as the javadoc points out

There is no specific size or formula that suits all applications, it's up to you to analyze your usage and come up with a suitable solution. A cache that is too small causes additional overhead with no benefit, a cache that is too large can once again cause java.lang.OutOfMemory exceptions and leave the rest of your app little memory to work with.

For your original request,

please offer something that automatically uses memory as needed, without setting a boundary,

We don't recommend a cache without a specific size, for LruCache or a cache based on SoftReference, because it will result in one of OutOfMemoryError / jank / early clearance of SoftReference in the older implementation. We don't have a GC that can avoid all of these problems if the application doesn't choose an appropriate size of the cache.

However, you can still architect your cache for your own application and purpose, because ART can't determine a good cache eviction strategy for your application, even though SoftReference is guaranteed to avoid OOME. If you use SoftReference-based cache, your application will need additional mix of cache eviction strategies, including a cache size limit, least-recent-used, time expiration, etc, to avoid janks. Application shouldn't solely rely on GC to evict members in a SoftReference-based cache. You may consider more than 1 layers of cache, e.g. a very small cache strongly-referencing members avoided being GC-ed too early.