Can someone please explain in layman terms what this means, what causes it, and how to avoid it. Especially when it comes to using Bitmaps.
Thanks
JS
Thanks
JS
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Android Question Memory Leaks
- Thread starter Johan Schoeman
- Start date
- Similar Threads Similar Threads
Not sure if this will help, since I guess your question comes from a specific problem that you have found.
To my understanding, memory leaks occur when an object's life cycle isn't a 'clean' operation. That is, the object is created, some memory is allocated for it and more resources can be allocated during calls to its methods. When this object is not longer needed, and garbage collected, there are some cases in which not all the resources used are deallocated. Don't know how internally works (reference counting?)
From my experience, there are some behaviors that could seem memory leaks although they aren't technically such: imagine a Java object in which one of its members is just a long integer that is an identifier for a big amount of memory allocated in the native C code when the object is created. Also suppose that this native memory is correctly deallocated when the object is destroyed (as there is a native call to free the memory associated with that long integer).
If during an application lifecycle this object is locally declared in an inner loop (so it is 'created' and 'forgotten' very often), the garbage collector will only see its 'Java size ' (the resources for a standard Java object plus its members), so it will not be high priority when it needs to free Java memory. If we take this situation to the limit (object locally declared in an inner loop), it can lead to crashes.
To my understanding, memory leaks occur when an object's life cycle isn't a 'clean' operation. That is, the object is created, some memory is allocated for it and more resources can be allocated during calls to its methods. When this object is not longer needed, and garbage collected, there are some cases in which not all the resources used are deallocated. Don't know how internally works (reference counting?)
From my experience, there are some behaviors that could seem memory leaks although they aren't technically such: imagine a Java object in which one of its members is just a long integer that is an identifier for a big amount of memory allocated in the native C code when the object is created. Also suppose that this native memory is correctly deallocated when the object is destroyed (as there is a native call to free the memory associated with that long integer).
If during an application lifecycle this object is locally declared in an inner loop (so it is 'created' and 'forgotten' very often), the garbage collector will only see its 'Java size ' (the resources for a standard Java object plus its members), so it will not be high priority when it needs to free Java memory. If we take this situation to the limit (object locally declared in an inner loop), it can lead to crashes.
Upvote
0
I just see that sometime in some Java projects they will call "bitmap.recycle()" to apparently avoid memory leaks. Just want to understand why this call. Does this free up the memory that the bitmap occupied?
Upvote
0
Head Office in PTA acknowledges your query and is offering the following reply:
https://plumbr.eu/blog/memory-leaks/what-is-a-memory-leak
We trust that you will be able to succeed in obtaining this resource and that it will be helpful before it is "captured" by "you know who" and left for Dubai !!
Upvote
0
Android has a powerful garbage collector so in most cases you will not encounter memory leaks.
You don't need to call bitmap.recycle. This was a best practice in older versions of Android (2.x). The bitmap memory will be released when there are no live references to the bitmap.
You don't need to call bitmap.recycle. This was a best practice in older versions of Android (2.x). The bitmap memory will be released when there are no live references to the bitmap.
Upvote
0
See this (https://developer.android.com/topic/performance/graphics/manage-memory.html). If your main audience is Android 2.3.3 and lower, then yes you may have a concern, otherwise I would just not fool with it.
Upvote
0
The main issue here is knowing how to define and use bitmaps within your code.
If you re-define your bitmap and even if you use the same code and same bitmap Android will just add another bitmap sized load of memory to the pile. At some point the pile gets full. Rather rapidly. The best way is to define the bitmap for use once and reuse that bitmap variable. You need to consider the pixel size of the bitmap as Android will happily just set aside memory for the bitmap full-sized. You can reduce this by using BitmapSample which applies some compression to your bitmap.
The best way to test these things is to create an App and use a memory 'monitor' App to see how much memory your App uses when it is being first loaded and then used again and again.
Quite a lot of Android coding and development seems to go against the grain of more traditional software development, but they are quite different devices to a normal computer.
If you re-define your bitmap and even if you use the same code and same bitmap Android will just add another bitmap sized load of memory to the pile. At some point the pile gets full. Rather rapidly. The best way is to define the bitmap for use once and reuse that bitmap variable. You need to consider the pixel size of the bitmap as Android will happily just set aside memory for the bitmap full-sized. You can reduce this by using BitmapSample which applies some compression to your bitmap.
The best way to test these things is to create an App and use a memory 'monitor' App to see how much memory your App uses when it is being first loaded and then used again and again.
Quite a lot of Android coding and development seems to go against the grain of more traditional software development, but they are quite different devices to a normal computer.
Upvote
0
Don't talk - just try: Make a small app with a timer. Add some IV's with BM's, remove the views (or do other things) and do it again for some time. See if your code works.
I do this from time 2 time to check if e.g. a sub works even after 1000 calls.
I do this from time 2 time to check if e.g. a sub works even after 1000 calls.
Upvote
0
