I have tried profiling my app, but found that TraceView isn't that user friendly, so I didn't find out why.
I think it may be because I'm allocating too much memory somewhere. So, in the attached image, I am getting these messages once every 2 seconds. Is this a sign of bad memory allocation?
Thank you very much,
Richard Hughes
No, I don't think that's a problem. GC is just freeing its memory as per its requirement.
To know more about memory allocations, please see following: http://codelog.dexetra.com/getting-around-android-memory-blues
They have explained this wonderfully.
May be this could also be happening because of a memory leak in your app. try to find it out. you can use MAT (plugin) for eclipse, its a bit difficult to understand at the first place, but as you will use it, you will understand, its a very good software to find memory leaks in ours apps.
Related
I'm working on my first android application which is a big application though.. I have completed half of my app but what makes me worry is that the memory used by app.. Initially I faced the issues regarding out of memory exceptions.. I first started analyzing my app with MAT(Memory Analyzer Tool) of Android Studio, which was very difficult to track the memory usage.. My app would reach allocated space of 96mb and crash.. Then After Reading on internet i used Leak Canary which pointed out the static resources that was eating memory.. and now my app regularly gets Garbage collected but still i find the allocated space remains to be around 70 mb, Like my app starts with allocation of 30mb when i use app for about 2 min and come back to initial screen the allocated space is not same as initial... For beginners like me it is hard to track the memory usage to the core using MAT and is there a best approach or tool which would give me a clear picture of allocated space by objects.. Objects that are taking maximum space.. objects that are supposed get destroyed but not destroyed?? and retaining Image memory etc etc Thanks in advance
One of the main 'memory leakers' is the Bitmap. Sometimes when you load an image in a a View, it uses a lot of memory in the action. I used to recommend using libraries like Glide or Fresco which are better handling memory issues and have a lot of common features already implemented.
Also you could try to free resources for each activity in your onDestroy method.
Nevertheless, I would be great if you could give us a deeper overview of your project.
Regards.
There have been a few posts here related to memory management.
We have all been newbies at some point and thankfully experience and problems like these have proven to be excellent 'teachers'.
Like I have said in another post :
This will of course cause memory problems such as leaks, OOM and
unnecessary resource binding. There is absolutely no automatic way to
free up memory. You can not, under any circumstances, rely solely on
the Garbage Collector
Basically, you must ensure that you allocate only the required resources and deallocate them as soon as you know you wont need them anymore within the Lifecyce
I have wrote a more detailed explanation with code (that you can implement on your project) to deal with your memory issues which can be found here :
It can be found here
Regards,
I've done with developing my app, now I'm trying to find bugs. First thing I've noticed is constant memory increase in GC_FOR_ALLOC message which starts from cca 9.000k and goes to 50.000k as I scroll listView.
I'm still a novice, so my first stop was developer documentation but as I pulled these reports I'm pretty stuck as I really don't know how to proceed when I discovered what is causing memory leak. Any advice and help is appreciated.
I am new to android. I implementing one app in android. But I would like to know How much memory occupied When i execute my app. plz help me If any one got.
Getting the memory usage can be a real pain, there are MANY factors.
But here on Stackoverflow is a real great explanaition. I dont quote it because, it is the best if you read through on your own ;-)
In short: use "adb shell procrank" (but really, read the linked answer, it's a great answer ;-)
Can anyone give me few tips and also few links to follow so that i can make my android app more memory efficient and faster.
Thanks.
It really depends on your situation and how your app is built, there is no right or wrong answer, but this documentation can give you some good guidelines http://developer.android.com/guide/practices/design/performance.html
For memory leaks take a look at traceview http://developer.android.com/guide/developing/debugging/debugging-tracing.html
I have a couple quick questions. They all deal with 1 general topic, and one strategy may take care of everything, so I hope that its ok I put them under the same topic.
I have had trouble finding solid info on garbage collection, so would appreciate any help, I think perhaps I don't fully understand what I am reading in the MAT. Even if you can answer 1 question I would be super happy
What is the best strategy for finding memory leaks in Android? As best I can tell it is to get the Eclipse MAT, picking an object that isn't getting garbage collected (using the dominator tree, or whatever is easiest for you to find it with), and displaying the shortest merged paths to the gc of that object and find the furthest incoming reference to that object that you can control and killing that reference on destroy. This works to kill the references, but sometimes the object still doesn't get garbage collected
Is it good practice to null all of your handlers/runnables/threads/listeners on destroy? Some of these seem to stick around indefinitely if I don't, and sometimes even if I do.
What is the best way to ensure that a thread gets garbage collected, even if the reference is nulled (they seem to stick around sometimes)?
Why oh why can't I get the google analytics tracker to get garbage collected, even though it has no reference from my application at all. It seems to maintain a reference to my activity, so I think that might have something to do with my GC problems.
Thanks you!
The best strategy is to fully understand the implications of what you are doing from the beginning, and thus avoid memory leaks in the first place. See, for example, handling memory leaks in Java. Otherwise, that seems like a fine approach along with code inspection. Are you forcing a GC to prove that the object still isn't collected?
In general, no. This article has a good explanation as to why.
Don't hold any references to it? Follow standard coding practices as described above.
Don't know. But wouldn't you be using it throughout your application, so it doesn't really matter? Eventually Android will kill your whole process and reclaim the memory anyways.