Solving memory leak - Java for Android App Development

I am a beginner developer and I am sure I have a memory leak in my android application. When I open my app for the first time and check the heap size using DDMS tool from Eclipse it shows 4.5 MB. With every new opening of my app (close and reopen it) the heap size is increasing until it reaches 5.8 MB and then it settles at this size going up or down just a little bit. I also see that the amount of allocated objects increases from 44k to 60k. That is crazy I guess. But why it stops increasing at that particular point of memory (5.8 MB) and amount of objects (60k)? Furthermore, for some reason Android Application Manager's "Cached background processes" section shows that my app memory consuption increases from 10 MB to 24 MB and settles there. Why do these numbers differs from what DDMS shows? Anyway, these two tools show the same behaviour: that is with every opening my app's memory is increasing. I have tried setting all my instance variables to null in onDestroy() methods of my every activity or fragment but it didn't help. What else can I do?
Sent from my GT-I9300 using XDA Free mobile app

Maceee said:
I am a beginner developer and I am sure I have a memory leak in my android application. When I open my app for the first time and check the heap size using DDMS tool from Eclipse it shows 4.5 MB. With every new opening of my app (close and reopen it) the heap size is increasing until it reaches 5.8 MB and then it settles at this size going up or down just a little bit. I also see that the amount of allocated objects increases from 44k to 60k. That is crazy I guess. But why it stops increasing at that particular point of memory (5.8 MB) and amount of objects (60k)? Furthermore, for some reason Android Application Manager's "Cached background processes" section shows that my app memory consuption increases from 10 MB to 24 MB and settles there. Why do these numbers differs from what DDMS shows? Anyway, these two tools show the same behaviour: that is with every opening my app's memory is increasing. I have tried setting all my instance variables to null in onDestroy() methods of my every activity or fragment but it didn't help. What else can I do?
Click to expand...
Click to collapse
Are you really sure you have such a leak? Usually it happens on rotation or so and it keeps on increasing, using far more memory than your 5.8 megs. If you quit your app with the home button (instead of back) Android still keeps a lot of its data in memory so it is faster to be reopened. It still depends on what your app is doing, so releasing any unneeded receivers or caches is still a good thing to do, but in your case an increase of just 1.3MB is not significant enough to really worry about it. I don't know what the Android Application Manager is showing since I haven't used it yet.

SimplicityApks said:
Are you really sure you have such a leak? Usually it happens on rotation or so and it keeps on increasing, using far more memory than your 5.8 megs. If you quit your app with the home button (instead of back) Android still keeps a lot of its data in memory so it is faster to be reopened. It still depends on what your app is doing, so releasing any unneeded receivers or caches is still a good thing to do, but in your case an increase of just 1.3MB is not significant enough to really worry about it. I don't know what the Android Application Manager is showing since I haven't used it yet.
Click to expand...
Click to collapse
Well, I wouldn't worry if that 5.8 MB had gone down after I quit my app pressing back button, but it hadn't, so it keeps me thinking I have a memory leak. And yes, it keeps on increasing on rotation too, because the activity is recreated. It doesn't increase only when I close and open my app using home button because activity isn't recreated then. By the way, I use FragmentPagerAdapter for ViewPager and CursorAdapter for ListView. Maybe one of these could be the cause. Thank you.
Sent from my GT-I9300 using XDA Free mobile app

Related

Running out of memory overnight

Almost 6 MB of memory is being consumed overnight by the services.exe process while the PPC is docked. I start with about 9.5 MB of program memory and the next day I'm down to less than 3.5 MB. Other than Active Sync, nothing else is running.
I have the following processes active:
connmgr.exe
cprog.exe
device.exe
filesys.exe
gwes.exe
NK.EXE
PhotoContacts.exe
Pocket e-Sword.exe
rapiclnt
repllog.exe
sddaemon.exe
services.exe
shell32.exe
sktools.exe
srvtrust.exe
tmail.exe
VoiceCmd.exe
if you are using a cooked rom it could be because of a flaw in ur system
what rom u using
Kill the MS Voice Command. Turn it off from the start up and that alone will save you 5-7megs of ram. Make sure you disable the voice command at the starting item, and reboot. Weather services also seem drain out the memory on a long run.
ROM is latest stock version.
I'm not concerned with apps that are memory hogs, and I use Pocket Plus to fully close tasks.
I'm seeing growth of 6 MB overnight in the process services.exe. (See attached file for detailed list of processes and memory).
I'm starting to disable apps one at a time. I'm suspicious of ActiveSync so I'm starting with it first.
Photo Contacts ain't helping either. Unless they fixed it, I gave that one up last year because of a serious memory leak.
And if you're using MSVC you can definitely get rid of sddaemon.exe, that is for the Cyberon Voice Speed Dial & is what keeps putting the shorcut there in programs after you delete it.
Although the memory usage of shell32.exe is stable, it seems very large (over 10 MB). Is that normal?
basic questions/clarifications
if i may be allowed to ask a couple of questions/clarifications:
1. does it follow/mean that the larger the memory consumption the more it/app drains the battery?
2. does it follow/mean that the higher the cpu usage the more it/app drains the battery
3. what app is that shows the heap? i'm only using task manager 2.9 by dotfred, it shows the memory but no heap.
4. I don’t know if this is a good idea, but anyhow this also came, from a desperate search, for an application that determines, w/c program drains the battery more. Is it possible to log the CPU usage? configurable to log only at every 5,10, 20, 30 sec. I know this would also drain the battery more but if the log, logs the 3 tops most drainers then we could start from there. I hope I'm making myself clear. Thanks and more power…
i hope i'm not off topic..
bump
up up up ...
jmcbride is talking about the amount of allocated memory increasing overnight, rather than the battery consumption. The heap is the list of currently-unused memory locations. When a program needs additional memory, it asks the system for a block of memory of a particular size, and this memory is allocated from the heap. When the program is through using this memory, it should then release the memory back to the heap. The operating system is supposed to combine adjacent free memory blocks, if possible, so that as much memory as possible is available as a contiguous block. This procedure is known as garbage collection. If a program loses track of what memory it is no longer using, without releasing it back to the operating system, the amount of free memory gradually gets less and less. This is known as a memory leak. One application that I have noticed is prone to memory leaks is Mobipocket Reader. If I leave it running for hours, I eventually have to reboot my phone in order to get back the free memory and be able to run commands.

{Help} Pinpointing a memory leak

Hi all,
i have read all i can find on the forum on this topic and i wanted to ask is a specific procedure existed for determining a memory leak (if i have one!) i find the gwes.exe file starts at 12mb at boot and generally increases untill a soft reset. it can reach 18mb. whilst i am not sure if this effects performance it causes my memory usage to rise constantly for no reason i can determine!
my setup - rom miri wm6.5 v26.3 - premium WITHOUT manilla
interface - spb mobile shell
dialer - phone ex
not much else
any ideas hints kindly recieved!
regards
Mat
lemat1 said:
i have read all i can find on the forum on this topic and i wanted to ask is a specific procedure existed for determining a memory leak (if i have one!) i find the gwes.exe file starts at 12mb at boot and generally increases untill a soft reset. it can reach 18mb. whilst i am not sure if this effects performance it causes my memory usage to rise constantly for no reason i can determine!
Click to expand...
Click to collapse
GWES memory consumption growth is as natural as gravity and it happens to improve performance. This happens because it is smart enough to keep resources in fast RAM so that next time they will not be loaded from (comparatively slow) flash memory. Basically this is the point in having RAM and the reason why you paid for it - it has to be loaded with stuff to make things faster. This sport of freeing RAM is just ridiculous in most cases (although not always, of course). You pay for it and then don't use.
Secondly, what you describe is not a memory leak. A memory leak is a situation of uncontrolled memory usage growth (if your GWES gradually ate all available memory to a point where device would crash that would be a memory leak). In general, there's nothing wrong with applications consuming more and more RAM as they work as long as they can free this RAM on demand. See for yourself: on your PC, load a memory-hungry application such as a web browser, note how much RAM it uses initially. Then use it for a while, RAM consumption will grow. Then minimize it and see how RAM usage drops dramatically. Even if an application uses half of all RAM it doesn't mean that this RAM isn't available for other programs when needed. When it's not needed, why not use it?

X10 Memory Leak?

I have noticed behaviour pointing to a memory leak on the X10 - After turning the phone on, I get less and less free memory after running ATK - over 110 MB right after turning the phone on to ~70 MB after 24+ hours.
The phone is heavily modified/customized, so it may not be an SE sw bug (ADW, Smart Keyboard, handcent, k9, etc...)
What's the best process tool you can recommend to look into this?
Let the phone handle the memory. dont worry.
+1 on that. Android its linux based and us meant to work like that. Empty memory is wasted memory.
-------------------------------------
Sent from my X10i
Android may be Linux based, but if *after killing all idle processes* memory is systematically dwindling, that means/may mean that one or more of these processes is allocating memory which it is then NOT being released - either by the process (more probable) or the system itself (less probable).
In other words, for the same set of running processes/applications , the memory usage should *not* systematically go up over time.
Linux itself has no automatic GC. Android does (Dalvik VM), but it takes some care from developers for that to work properly - no "loose" pointers to unused but still-referenced data, etc....
acmbc said:
Android may be Linux based, but if *after killing all idle processes* memory is systematically dwindling, that means/may mean that one or more of these processes is allocating memory which it is then NOT being released - either by the process (more probable) or the system itself (less probable).
In other words, for the same set of running processes/applications , the memory usage should *not* systematically go up over time.
Click to expand...
Click to collapse
I disagree, as processes are used/exercised the kernel will allocate the memory they need, after switching on the phone the processes are idle and occupy a small amount of memory. As they are used the process size will grow in main memory as they store or cache common data used by the process. That is why applications such as facebook may be slower at start off as the data needs to be supplied, once this data is cached it will run much faster as the data is already in main memory.
Linux/Android works on the principle that it's a waste not to use as much memory as possible.
Not to get into a GC flame war here: The principle you mention is right, its just that after one KILLS these processes (facebook for example) ALL OF the memory allocated by facebook should be relinquished to the system (ergo, appear as free).
I.e. if I start up my phone, and just have processes A B and C running and have lets say 120 MB free, and after using the phone for a while kill everything and *restart* ONLY processes A B and C, then I should have 120 MB free. At least tendentially (may have a different set of resident libs at the 1st and 2nd points in time, some other minor stuff may be different, etc..). However, I find that doing this over and over results in less and less free memory being available as time passes.
I am not saying I am *right* but a good process inspection tool would help to ascertain what is going on.
acmbc said:
Not to get into a GC flame war here: The principle you mention is right, its just that after one KILLS these processes (facebook for example) ALL OF the memory allocated by facebook should be relinquished to the system (ergo, appear as free).
I.e. if I start up my phone, and just have processes A B and C running and have lets say 120 MB free, and after using the phone for a while kill everything and *restart* ONLY processes A B and C, then I should have 120 MB free. At least tendentially (may have a different set of resident libs at the 1st and 2nd points in time, some other minor stuff may be different, etc..). However, I find that doing this over and over results in less and less free memory being available as time passes.
I am not saying I am *right* but a good process inspection tool would help to ascertain what is going on.
Click to expand...
Click to collapse
Wrong.. it should NOT be returned to the system.. but it should be marked as "disposable" IF another process wants to use it. That is the way linux usually do.. That is why the "Free"-value is misleading. As the "Free"-value is not the sum of "Free" and "Cached" values. when you "unload" a lib it is not completely removed from memory, it is just marked as "cached" instead. Saving tremendous ( ) amount of battery and time when, if, the user wants to use it again before overwritten by another memory-hungry application..
Regards // OwL
does all this mean we don't really need advanced task killer?
or does the advanced task killer kill the cpu process? ( as a result longer battery life)
robbyf66 said:
does all this mean we don't really need advanced task killer?
or does the advanced task killer kill the cpu process? ( as a result longer battery life)
Click to expand...
Click to collapse
advanced task killer kills the application itself, so that nothing more is executed by that application thread(s). wether dependent libraries are kept loaded or not does not affect battery time when not used. Advanced task killer does not actually unload any libraries it only kills the process.
I personally hardly never use advanced task killer, as it is not needed as long as you make sure to run applications that does not keep the phone from going into sleepmode. Those programs are just simply bad coded.. I instead have a CPU-meter application in the task-bar and if I see that the CPU-time is extensivly used after the application has been put to background, then I might use a taskkiller to stop the bad application. But that scenario is rare... I usually get 50h+ of battery time per charge, whatever I do with it.
Regards // OwL

Available Memory, how much do you typically have?

Good day!
I've tried a few different apps now, Memory Usage, Advanced Task Killer, and I seem to hover between 110m to 25m. I kill some apps and it jumps back up to 110 and then slowly works its way back down to the mid 20's. Is this normal?
Tips? What is your available memory like?
To sum it up: Free memory is useless memory. You should have as little memory free as possible.
Explanation. Android handles memory management really well. When an app is opened and needs more memory it will shut down unused processes and free up memory on an as needed basis. For apps this can be everything from pausing individual functions all the way to saving an apps state to disk and restoring it the next time it's opened.
Task killers are mostly solutions looking for a problem, I've been running without one for months and my amount of free memory fluctuates as expected when surfing the web and things like that but so far there haven't been any times where I've had to free up memory. So don't stare yourself blind on memory meters and try freeing up memory. Android handles that well enough on its own.
+1..
The message you have entered is too short. Please lengthen your message to at least 10 characters.
That's good info! I kinda knew I was making something out of nothing with the numbers. The phone has been fine in terms of performance.
my 2 cents....i typically have between 30-60mb free. phone does not lag or anything. i used task-killer for a few days when i got phone, then actually thought about what it was doing and the way the system (linux based) is designed. i ditched it and have not looked back!
ps. my phone is rooted R2BA024 firmware, fwiw.
I usually have like 80 mb free ram just for the case and i use task manager to kill apps that are using data connection when i dont need them
I got totally obsessed with task killing but having read a lot of the lads reports on here I am on my third day of not touching it and I have to say my phone is doing fine all by itself!
goth50 said:
I usually have like 80 mb free ram just for the case and i use task manager to kill apps that are using data connection when i dont need them
Click to expand...
Click to collapse
I think you'd be better off setting up data synchronisation properly. I'm assuming you're talking about background syncing of course. So that you don't accidentally kill an app in the middle of a sync which might cause corruptions. I've had that happen when synching my gmail to a linux machine and the network went down, the cleanup required was insane and I lost a whole months worth of mails from the google servers.
ddewbofh said:
To sum it up: Free memory is useless memory. You should have as little memory free as possible.
Explanation. Android handles memory management really well. When an app is opened and needs more memory it will shut down unused processes and free up memory on an as needed basis. For apps this can be everything from pausing individual functions all the way to saving an apps state to disk and restoring it the next time it's opened.
Task killers are mostly solutions looking for a problem, I've been running without one for months and my amount of free memory fluctuates as expected when surfing the web and things like that but so far there haven't been any times where I've had to free up memory. So don't stare yourself blind on memory meters and try freeing up memory. Android handles that well enough on its own.
Click to expand...
Click to collapse
Heh...handles memory very well, but how about the battery life!? The more apps you have- the less power you've left.
mymagicmyhero said:
Heh...handles memory very well, but how about the battery life!? The more apps you have- the less power you've left.
Click to expand...
Click to collapse
That's debatable, most background apps drain miniscule amounts of power. The exception naturally being things that makes use of the hardware while backgrounded by playing music, syncing, calculating pi or things like that. Most apps though, just hang out in memory not really doing anything. A lot of the time, if not most, it's more efficient staying there as opposed to shutting it down and starting it up again later.
+1 yes, just hanging out idle in memory wont cost you any battery, the memory will be on an base current either way, what does cost you battery is the read and write actions to memory so if you frantically clean out that memory your phone will have to write alot more to it working with your different apps resulting in a slower (less prepared) device sucking more battery then neccessary. Leave the memory handling to your device ;-)
Sent from my X10i using XDA App

Android / Linux Memory Management

Hi guys,
I find myself, yet again, having to explain to users how linux and android manages ram.
Most users seem to think that more free ram is better. They couldn't be more wrong.
This article explains the concept in layman's terms so nobody should be confused or left doubting.
So there we go, I'll refer to this article and I hope you all do too if you see stupid remarks here in the forum regarding free ram.
Have fun reading
Quote
Linux memory consumption concept
Linux memory consumption concept is all about efficiency. The system’s RAM is a resource that is meant to be used; 100% of it (if possible), all the time (if possible).
Linux utilizes unused RAM to cache data and filesystem meta-data from slower storage devices (Flash or disk) because fetching the information from the RAM is much quicker: There are no bottlenecks such as slow physical media, slow buses or device clocks, and not decompression is required.
Assuming there are no memory leaks, the reason that memory report tools report low amount of free memory is because the RAM is considered to be wasted if it isn’t used. This concept may require some time to digest, because conventional thinking may lead to the conclusion that an efficient system is a system with a lot of free memory. This is not entirely correct. In Linux case, the kernel tries to utilize the most of the RAM to improve the system performance. Keeping the cache means that if the kernel or a task needs the same data again, there’s a good chance it will still be in the fast cache in memory.
Conclusion: less free ram = more cached process/application = better multitasking.
Some heavyweight app need lot of free memory, but in the daily usage better if you NOT use s*perch*rger or any similar script to get more free ram.
A typical bug with systems what have lot of free ram: when a call arrive, you need to wait several seconds to see the caller name, because the contacts app killed to get more free ram, and need to reload the app, open the contacts database, etc...
Sent from my E15i using xda app-developers app
pilu1978 said:
Conclusion: less free ram = more cached process/application = better multitasking.
Some heavyweight app need lot of free memory, but in the daily usage better if you NOT use s*perch*rger or any similar script to get more free ram.
A typical bug with systems what have lot of free ram: when a call arrive, you need to wait several seconds to see the caller name, because the contacts app killed to get more free ram, and need to reload the app, open the contacts database, etc...
Sent from my E15i using xda app-developers app
Click to expand...
Click to collapse
i have a lot of free ram and still doesn't have any problem with call delay or any other problem, I don't even use any ram script or any other script ,so in my rom I can enjoy when I use heavyweight app's or when I use a daily APPs
All this information is an overkill for the original discussion and it actually misses the most important point. Here's why.
The number reported by most users as free RAM is not free at all. When most users refer to the amount of free ram in a particular ROM, they're refering to the number reported in Running Apps. That memory is not free memory. And that's the most important point.
You don't read guys reporting the amount of free RAM memory while executing the free command in terminal.
It's true that the "running apps" doesn't report the true amount of free ram..
Terminal Emulator - type su then type free . I think that is the true amount of ram.
Sent from my Nexus 7 while being Paranoid .
Mockingbird said:
Terminal Emulator - type su then type free . I think that is the true amount of ram.
Sent from my Nexus 7 while being Paranoid .
Click to expand...
Click to collapse
Yeah that's right to a certain point since android grabs as much ram as it can.. Doesn't mean the remaining ram is all that's free though..
Quote
Memory management
Since Android devices are usually battery-powered, Android is designed to manage memory (RAM) to keep power consumption at a minimum, in contrast to desktop operating systems which generally assume they are connected to unlimited mains electricity. When an Android app is no longer in use, the system will automatically suspend it in memory - while the app is still technically "open," suspended apps consume no resources (e.g. battery power or processing power) and sit idly in the background until needed again. This has the dual benefit of increasing the general responsiveness of Android devices, since apps don't need to be closed and reopened from scratch each time, but also ensuring background apps don't waste power needlessly.
Android manages the apps stored in memory automatically: when memory is low, the system will begin killing apps and processes that have been inactive for a while, in reverse order since they were last used (i.e. oldest first). This process is designed to be invisible to the user, such that users do not need to manage memory or the killing of apps themselves.] However, confusion over Android memory management has resulted in third-party task killers becoming popular on the Google Play store; these third-party task killers are generally regarded as doing more harm than good.
CtrlAltDelIrl said:
Memory management
Since Android devices are usually battery-powered, Android is designed to manage memory (RAM) to keep power consumption at a minimum, in contrast to desktop operating systems which generally assume they are connected to unlimited mains electricity. When an Android app is no longer in use, the system will automatically suspend it in memory - while the app is still technically "open," suspended apps consume no resources (e.g. battery power or processing power) and sit idly in the background until needed again. This has the dual benefit of increasing the general responsiveness of Android devices, since apps don't need to be closed and reopened from scratch each time, but also ensuring background apps don't waste power needlessly.
Android manages the apps stored in memory automatically: when memory is low, the system will begin killing apps and processes that have been inactive for a while, in reverse order since they were last used (i.e. oldest first). This process is designed to be invisible to the user, such that users do not need to manage memory or the killing of apps themselves.] However, confusion over Android memory management has resulted in third-party task killers becoming popular on the Google Play store; these third-party task killers are generally regarded as doing more harm than good.
Click to expand...
Click to collapse
Certenly you explain the subject very good. It is my first time to understood. Thanks!
mikekgr said:
Certenly you explain the subject very good. It is my first time to understood. Thanks!
Click to expand...
Click to collapse
Certainly you didn't care enough about the subject before. Otherwise you would have found the same information in Wikipedia: http://en.wikipedia.org/wiki/Android_(operating_system)#Memory_management .
Unless CtrlAltDelIrl edited that article...
Fortun said:
Certainly you didn't care enough about the subject before. Otherwise you would have found the same information in Wikipedia: http://en.wikipedia.org/wiki/Android_(operating_system)#Memory_management .
Unless CtrlAltDelIrl edited that article...
Click to expand...
Click to collapse
Always these days the same problem: all information exist somewwhere but it is not very easy to "locate" the information required!

Categories

Resources