I have an app that is doing a lot of work related to Bluetooth connection and displaying graphs etc.
App is using many libraries as well. App has also a background service running all the time. Now I noticed that it is taking upto 500 Mbs of Memory Usage.
What I have done was commented out. Everything on app launch and just showed splash screen (custom made) and still footprints are 60-70 Mbs. That means something is taking too much memory without even using it.
One important thing is that Android Studio's Memory Monitor is showing me that app is using only 40-50 Mbs whereas my phone's Memory manager is showing upto 500 MBs. I have tested this on 3 phones. Result remains same.
Any help should be appreciable.
You are leaking alot of memory you can go to memory monitor in android studio and use garbage collector to have an estimation of the total amount of leak you're having.
Most of the time External libraries are main Issue for the memory leakage due to their differing implementations and are quite inefficient when used for work on mobile client.
Here is a great blog regarding memory leakage.
http://blog.nimbledroid.com/2016/05/23/memory-leaks.html
Use MAT Tool to find out memory leakage and resolve that.
Once started service, if it is no needed then stop the service using intent.
And also check you have started any timer thread and not stopped it.
Related
I just try to understand the reason of it. Our app is really stable and optimized, but time to time it just switch off during the work on foreground mode. User is using it, and it' just closed without any crash or ANR messages - really bad experience. What we already did:
use UncaughtExceptionHandler and print logs to the disk for analyzing. Logs are empty, not information about crashes for these cases
used Firebase crashlityc - is empty too
checked app with help profiler and leakcanary - no leak, memory using ~200 Mb
A bit words about our app:
clear arhitecture, Kotlin, MVVM, coroutines, dagger, retrofit, room, one single activity app
app should work all time, infinitely. App is an interface for hardware terminal.
the most part of fragments are stored into the backstack and reused again, it help to make screen opening faster after first fragment using. No leak with it, no fragment or viewModels duplicates
we use glide for downloading and previewing user avatars. I'm afraid, that leaks could be a part of bitmaps or jpg. Profiler doesn't show it after 1-2 hours tests, but I didn't test it during for ex. one week
possible app interruptions happen more often, when device is uncharged or just started (first 10-20 minutes after device start)
the most part of clients has a bad WIFI connections
we have ~10 modules, the most part of them are own canvas libs
crashes happen in random moments...
we also have ANR problem for some clients, but we added ANR watchdog, so soon we will know the reason of it.
we have 50-60 singletons. I'm not sure, that is bad or good. The first plan was using much memory to make app faster.
For me it looks like a native crash or system kill, but how to repeat it? I still don't understand the real reason of it. If you faced with similar problem, please describe your experience, it could be helpful for us. Thx!
For the few days, I've been trying to find out why my app allocates massive amounts of memory and crashes. I'll open a few layouts that admittedly is not optimized. But I cant figure out why sometimes StartActivity() will allocate up to 80MB at a time, and why that memory wont release when I close the activity.
I created a test application filled with images and two layouts that call each other. Using Xamarin Profiler, I came across this memory dump, and I cant figure out what is calling this and how can I have it called more often for my real app?
Please, any insights would be lovely.
I cant figure out what is calling this and how can I have it called more often for my real app?
The Memory Profiler in Android Studio can help you to see how your app allocates memory over over time. It could also be used for xamarin android app.
And try to use IComponentCallbacks2 interface and implement Application.OnTrimMemory to incrementally release memory based on current system constraints.
You could refer to Manage your app's memory for more information.
I am trying to optimize my app which is extensively using Mapview i.e. lots of ItemizedOverlay. While trying to see an app on allocation tracker after using an app for some time I am getting below view.
Few other information,
App is extending MapActivity. App is having fix orientation.
App is not opening any other activity (activity back and forth is not
happening).
Map is showing correctly on the activity.
I have seen multiple post on memory management, seen this Google IO video as well but could not address this problem.
App is running on ICS Tab.
My questions are,
Please see the Allocation in column and android_map_conflict.. value, does it suggest that it is the case of MapView + key conflict? What should be work around in such case?
Size of the memory allocation under android_map_conflict... is keep on increasing. any work around or higher level suggestion? I know it might not needed, but any forceful GC would work? At which place?
I'm not sure that I full understand the output of allocation tracker, but I believe it only refletcts the allocated memory, which can later be released and recovered by the GC. So, if you don't have a memory leak (a object that stills referencerd longer then needed) the allocated memory will be returned to free memory.
If you are experiencing issues with memory leak, they may be coming from somewhere else as well. I suggest that you install the MAT as shown in the video you refer. I've done so, using the version Eclipse plug-in, and it worked like a charm. I found the leak in a couple of minutes (after spending a couple of hours, trying to understand how MAT should be used :-) )
good luck
I am using a native code to capture the framebuffer using the link below
http://www.pocketmagic.net/?p=1473.
But my problem is that I want continous capture. Hence I am using service in Android so that it runs in background.
But my problem is that it gives low memory and dies after some time.
Then I tried with single activity and tried to capture the sam window many a times.
This time there is no problem even after 1000 counts.
The problem arises when there is service used.
Please help.
It is hard to say without seeing your source code - you should always try to include the smallest possible application that exhibits the problem behaviour.
At a guess I would say that you have memory hungry resources that are not being cleaned up and this is happening because your memory allocation and release code is not perfectly aligned with the life-cycle of the service. You could confirm this in a couple of ways:
Log the explicit allocation and release of memory and make sure your service is actually executing those parts of the code.
Use a memory profiler to find allocations that are not being released. This might be more challenging with native code than it would be in Java.
I have an Android app with a running service.
When I look in the "Running Apps" menu in Android settings, I see that my app memory usage is
between 9-16MB .
I used DDMS Allocation Tracker to see where this is coming from, but all of the objects were less than 500 bytes.
Does it make sense? Any other ways to track my app's memory usage?
Also, I have an SQLite database opened as long as the service is running. Is that an impact on memory as well?
Thanks.
Does it make sense?
It neither makes sense nor doesn't make sense. You can get to "9-16MB" by increments of 500 as easily as you can get there by increments of 5000. Also, AFAIK that allocation tracker does not track everything (e.g., bitmaps on pre-3.0 environments).
Any other ways to track my app's memory usage?
Dump your heap (e.g., using the Dump HPROF File toolbar button in DDMS) and examine the results with the MAT plugin for Eclipse. There was a presentation on this at the 2011 Google I|O conference -- the YouTube video is online. You can use this to track memory leaks.
Is that an impact on memory as well?
Some, I'm sure.
Another issue is actually the service itself. Your objective should be to have that service in memory as little as possible, and only while it is actively delivering continuous value to the user. Ideally, your service is destroyed ~99% of the time.