Android Question Large bitmaps: is use of reflector.RunMethod("recycle") still relevant

[JackKirk]

Because of these posts/threads:

https://www.b4x.com/android/forum/threads/out-of-memory.10760/#post-62144
https://www.b4x.com/android/forum/threads/java-method-recycle-not-found.17950/#post-104268

I have been attempting to manage out of memory problems by using the following code as soon as I finish with a large bitmap:

reflector.Target = bitmap  
reflector.RunMethod("recycle")

However both the reference posts/threads are 4 to 5 years old.

Some other reading seems to suggest that the "recycle" approach was useful because various bits of bitmaps were kept in different heaps and "recycle" would immediately release the actual pixel data (the main memory gobbler).

Looking at:

https://developer.android.com/training/displaying-bitmaps/manage-memory.html

specifically this quotation:

On Android 2.3.3 (API level 10) and lower, the backing pixel data for a bitmap is stored in native memory. It is separate from the bitmap itself, which is stored in the Dalvik heap. The pixel data in native memory is not released in a predictable manner, potentially causing an application to briefly exceed its memory limits and crash. As of Android 3.0 (API level 11), the pixel data is stored on the Dalvik heap along with the associated bitmap.

Does the bold sentence above negate the rationale for using reflector.RunMethod("recycle") on Android 3.0 and above or is the approach still valid?

 

[Erel]

It is not required as the memory will be released when there are no more live references to the bitmap.

Calling recycle can be dangerous as there may be still references to the bitmap object.

If you are creating large bitmaps (it usually happens when using Canvas) then you should avoid creating unnecessary bitmaps. You can for example create a process global mutable bitmap once and then reuse it.

 

[JackKirk]

It is not required as the memory will be released when there are no more live references to the bitmap.

Question: what if you use 2 large bitmaps in the one sub - you initialize and use first one then you are finished with it - you then want to initialize and use the second one - how do you "dereference" the first one so that if the garbage collector is fired while trying to initialize the second one the first ones memory will be recovered?

Calling recycle can be dangerous as there may be still references to the bitmap object.

But surely this would be a simple error of logic that will be revealed during debugging - never to be seen by the end user.

If you are creating large bitmaps (it usually happens when using Canvas) then you should avoid creating unnecessary bitmaps

Yes, I'm doing this (avoiding unnecessary that is).

You can for example create a process global mutable bitmap once and then reuse it.

Yes, I have also done this - I have 2 versions of the app - this just means that you have a constant memory overhead - in the case of my app the memory required to run it is comparable to the dynamic version - I guess the upside is a reduced reliance on the garbage collector.

Question: getting back to my question in post #1, is the approach still valid?

 

[Erel]

In the case you described calling recycle can help.

 

[JackKirk]

In a similar vein, what if you use 2 large integer arrays in the one sub - you declare and use first one then you are finished with it - you then want to declare and use the second one - how do you "dereference" the first one so that if the garbage collector is fired while trying to declare the second one the first ones memory will be recovered?

 

[Erel]

The memory will only be released after the sub completes.