I've read a lot about Memory Leaks in Wiki Managing Memory Leaks and Forum posts.
I removed nearly all memory leaks in my app. At least on iOS. It's very easy to monitor them on iOS. But on Android, the heap / memory usage is always growing and nothing is released (and least it seems so). I'm not sure whether it's caused by a few Titanium issues ( eg TableViewRow Leak ) or whether it's my code.
Thus my question. If I removed all my memory leaks on iOS. Does this also remove my memory leaks on Android? Granted that the code is the same.
Thx + Greetings
Well in android the garbage collection is maintain automatically and we dont have to code anything separately for that i guess that the default nature of java. Well but i am not sure with the v8 functionality. But memory leaks in android is not an issue unless your app is using a lot of memory where its not even needed.
When looking for memory leaks on Android, people are usually over-paranoid. The thing is that memory management and GC (garbage collection) is very sensitive action in terms of performance and Android handles this very randomly (GC occurs when there are enough free resources in system). Garbage collector will clean memory when it thinks that it should and it releases it as much as it thinks it should.
So, because of that, people usually are paranoid because they released an object (variable = null;) but memory has not been released. Nulling a variable is just like you said to GC - I don't need this memory anymore (and most people think they said - free this memory at once! :D ). That does not guarantee anything in terms of free memory. To see do you have memory leaks, run your app for some time and see how free memory levels behave. If free memory is constant over time, you can say that you don't have memory leaks.
I guys I am also having a similar issue. I have nulled all variables and removed everything in my iOS version, so in theory that should also clean up memory in my Android version. None of the above post really answered the original question. In my Android version the memory only gets cleaned up a little bit but over time continues to grow and crash the app, this does not happen in my iOS version. Does anyone else have similar behavior?? I am using single context with 1 window and views that get created and removed as needed. Which version of 1.9 may fix this issue? Thanks for any input.
NB: SDK 1.7.5 on Android, haven't tried any other SDK versions and don't know if this affects iOS - This doesn't necessarily answer all memory leaks/out of memory scenario's but certainly this one caused me a big headache and the workaround is NOT obvious at all. See my comments on 'sean sean' post above for the background but basically if you use the 'backgroundImage' property of any type of view and you then 'remove' that view from it's parent you will get a lot of native memory left unfreed until the next GC. This can result in you're app getting OutOfMemory errors in the log or even a 'Force Close'.
Long story short to workaround this issue you can do one of two things:
1 - If you don't need your image stretched to fit the view then use an 'ImageView' and set the 'image' property instead of the 'backgroundImage' property. Then when you want to remove your view and free the memory be sure to remove it from it's parent view, set the 'image' property to empty string and then 'null' your reference variable. e.g.
win.remove(imgView); imgView.image = ''; imgView = null;
2 - If you do need your image stretched to fit then because 'ImageView' maintains aspect ratio you have to use a bit of a hack. Basically you can use a 'Button' view but make it disabled (i.e. enabled = false), set 'style = 0', and 'width' and 'height' to 100% otherwise it won't expand to fill the parent. Then use the 'backgroundDisabledImage' property to set your desired image. Then you want to remove your view and free the memory it's the same as above but you set the 'backgroundDisabledImage' to an empty string, e.g.
win.remove(button); button.backgroundDisabledImage = ''; button = null;
NB: For tracking this problem down the DDMS tools was absolutely essential. Strongly recommend you know how to use this tool effectively for investigating memory leaks.
good. thank ! hinh anh girl xinh de thuong