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
Related
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.
I am trying to understand where my app is using memory, and where I can make it more efficient in this respect.
In the Android Monitor part of Android Studio, I have dumped the Java Heap, and am looking at the generated hprof.
And I see a lot categorized under FinalizerReference:
What is this? How can I understand better what is causing it, and how to keep it down? Looking into the "Instance" panel doesn't help me much... doesn't make much sense.
I have tried looking at this but it's all slightly over my head at the moment.
Also, at the moment the memory monitor is reporting (in the live chart section) an Allocated memory of 10.58 MB. But on my device, in Application Manager > Running Processes, my app is showing a memory usage of 44MB. Why the discrepancy? If it's the ~33MB I want to try and reduce, I'm not apparently even seeing that in Android Studio, so no real hope of identifying what it is?
There may not be much you can do about FinalizerReference memory usage. See this question for more details - basically some objects implement finalize() and these are handled a little differently, such that they can end up sticking around longer. I haven't looked into it too closely, but I suspect that some android sdk objects do this and there's little you can do about it except for maybe tuning up your object caching/recycling to reduce it.
I'm not sure if this would help with FinalizerReference, but one thing I like to do to track down memory leaks is to find suspicious objects' connections to the GC root.
If you're using the Eclipse hprof analyzer (independent of the actual Eclipse IDE; works with hprofs generated by android studio), this is one way to access this:
Overview
Histogram
Right-click, "List Objects"
Right-click an object you suspect is leaking, "Path to GC Roots"
Now you should see a list of nested references leading back down from the gc root to your object.
I'm not exactly sure what is owing to the discrepancy - here is a similar question on that. Apparently the memory monitor tool may only be reporting heap allocations made by Java code, whereas the device reports the entire processes's memory usage.
The Retained Size reported by the Memory Profiler for FinalizerReference is currently a meaningless number, as I argued in my answer to my own similar question.
To summarize: Treating FinalizerReference like any other class when profiling (as Memory Profiler does), leads to repeated counting of the same memory when calculating its Retained Size.
I view this as a bug in Android Studio's Memory Profiler, and have filed this issue.
Good day,
I am developing an adventure game in AIR for Android. I am instantiating levels from the library (movie clips), each containing at least one HD resolution bitmap.
When the game starts, it occupies about 150MB of memory, including the AIR runtime and the SWF. Out of this 150MB the SWF is about 12MB at this time.
As the game progresses the memory consumption of the AIR runtime increases, while the memory used by the SWF remains at around 15-20MB. When the total memory consumption reaches about 350(!)MB, the OS intervenes and kills the app.
I was careful to reuse objects whenever I could, and nullify any unused objects to make them eligible for GC. GC seems to be working as it should, as the memory used by the SWF remains steady around 15-20MB. I can see it drop from 20 to 12 from time to time when GC kicks in.
Things I've tried:
Removed all cacheAsBitmap and cacheAsBitmapMatrix properties.
Exported each level into a separate SWF and loaded them from there instead of the library.
Forced the GC hack just to see if it has any effect.
Fiddled with System.pauseForGCIfCollectionImminent(n) with different values for n.
Tried different acceleration modes (direct and auto) thinking maybe the GPU is at fault.
All failed, memory consumption just runs away.
This happens only on Android. On a PC everything is fine, the whole thing takes up about 250-300MB, and this number remains steady, no matter how many levels I load one after another. Didn't have the chance to test on iOS yet.
I would really appreciate any ideas or insights into how to make this problem go away.
Thanks.
1) Easiest way to find memory leak is to use Adobe Flash Builder. Just run profiling.
2) Also good way to exclude leaks in future: create function which will be used for "cleaning". E.g. it will null all local variables of instance and so on. Something like usual c++ destructors. Then, before nulling your object, just call this method.
GC Malloc is called on every frame when Camera.preview callback is running. I'm assuming that this adds to to slowness of myframe rate.
Does anybody have any advice on ways to reduce these calls. I've tried searching on google groups and there does not seem to be many response, so I wanted to get information from people who are building and using camera preview in their applications.
As GC Malloc is being called it seems a new piece of data is being used each time to hold a frame. Can this be predefined? - Is this what callbackwithBuffer does? Ive had trouble getting my head around this and have been unable to implement the callback with buffer properly so any help on how to do this would be appreciated.
Also could someone fully explain what is happen in memory with the frames when camera preview running.
Thanks in advanced.
The problem you are having is an issue in older versions of android where memory is allocated and garbage collected in short span of time causing performance bottlenecks .
Explanation can be found here: http://code.google.com/p/android/issues/detail?id=2794
Your issue can be fixed by using some hidden methods. However you need to expose them by using reflection (the bug link has further examples).
If I recall correctly this issue has been fixed in Froyo.
Noob question!
My whiteboard/drawing app runs fine, using a combination of simple image views and bitmaps with me rendering a path to a bitmap and copying over as needed. I have it multitasking on my ICS Transformer without problems. However, if I exit the app with the Back button and then run it again, it fails; I get a memory error on the second run when I try to draw something.
Out of memory on a 4096016-byte allocation
Although sometimes I don't get that and it runs a second consecutive time. When I run it a third time, it works, and the fourth, again it Out-of-memory's.
What manual cleanup do I have to do when an Android app exits? Should I remove all created objects and bitmaps and paths and listeners and stuff?
Looks like you have a memory leak. Make sure you follow recommendations provided here. Often Memory Analyzer Tool is very useful in such cases. Here is a video how to use it.