I have an app, which is doing some basic operations like: download files, install files, query the phone, Using threads, HttpClient connections, etc.. (nothing too complicated).
it's also running a perm service inside(kind of Listener)
The wierd thing is: when I first intall it on my device, it's size in the memory is around 150 kb. but after a while (could be couple of days of activity), the size is growing unexpectedly, last time I check it got to 664KB.
What could be the reason? is this memory measure is realiable ?
what should I check or how sould I solve it in order to keep it small while it's extracted in the memory?
Thanks,
ray.
It's usually due to fragmentation of the heap, there are plenty of resources to research upon for regular Java VM's, you will have to check the Dalvik documentation for tools to assist with Android.
How fragmented is my Java heap?
Tips and tricks for dealing with a fragmented Java
Dalvik heap fragmentation and recovery
Related
I recently created an android application, and after I completely redid my spinner dropdown menus using a custom adapter, some devices are crashing. It's very minimal, like 3 people have experienced crashes ever, but still it's something I want to address if possible because the apps minimum SDK version is as low as 16, so I imagine it's older devices that struggle the most. Attached is a pic of the crash report! This specific device has 2 GB of memory, you would think that would easily be enough to load a spinner with a bunch of low quality images right?
Thanks for the help in advance! This is the crash report: https://i.imgur.com/Wtm5pX9.jpg
The amount of memory the device has != the amount of memory you can use. The OS takes a lot. Other apps take a good amount. And even the memory you can use is fragmented into different pools. Generally "OutOfMemoryException" means out of Java heap memory (out of native memory would be a different crash, for example). Bitmap memory goes into different buckets on different OS versions, they've changed it a few times. So it could be a variety of reasons- you have too large an image that's using insane memory, your have leaks, you have sufficient memory on the device but the heap allocation spiked for some reason, your network layer isn't efficient (if you use Volley to download images its particularly stupid about that). There's not enough info here to actually give you a suggestion. I'd try to replicate it on a simulator with the RAM purposely capped at 1GB or smaller and see if you can reproduce 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.
I'm studying about RAM memory, and I see that helloworld from the android samples uses about 13MB of android memory.
How does it happen, if the app have only an activity with a TextView?
And what to do to reduce memory usage? and which uses more memory?
I see that helloworld from the android samples uses about 13MB of android memory
You did not indicate how you are measuring this memory usage.
Please read:
Dianne Hackborn's blog post, "Process Stats: Understanding How Your App Uses RAM"
Dianne's epic StackOverflow answer on measuring memory usage, particularly the first paragraph:
Note that memory usage on modern operating systems like Linux is an extremely complicated and difficult to understand area. In fact the chances of you actually correctly interpreting whatever numbers you get is extremely low
Anything that you use that lies beyond what is written in those posts may or may not be accurate. And even interpreting what Process Stats is telling you is a bit of a challenge.
How does it happen, if the app hase only an activity with a TextView?
It is unlikely that your app has 13MB of consumed heap space. What you are seeing probably includes memory shared with other processes, for the Dalvik VM, platform libraries, and framework classes.
Android developers should be worrying about their heap space, first and foremost. Most of the memory usage beyond that is driven by the platform, not you (notable exception: NDK libraries that you load and the memory that they consume, for code and data).
what to do to reduce memory usage?
Probably nothing, because probably nothing needs to be done.
For more complex apps, as thepoosh mentions in a comment, you can generate a heap dump from DDMS and examine that in MAT to see if your app is leaking memory, resulting in an over-use of heap space.
You are welcome to try using android.os.Debug to try to get a sense of how much the heap is being utilized at runtime.
And, you are welcome to read the documentation on memory usage.
As my app is using a lof of pictures, I get the famous issue of OutOfMemoryError on older devices.
Explanations: http://androidactivity.wordpress.com/2011/09/24/solution-for-outofmemoryerror-bitmap-size-exceeds-vm-budget/
According to Android Developers your device has at least 16MB of heap
space (T-Mobile G1) for storing your application data. But as Yekmer
said in Yekmer’s Posterous , images are not stored in the heap space.
The space reserved for images in an Android application is very
small, and having a big application using a lot of images, may easily
lead to the OutOfMemoryError.
My question
Having a lot of code, I would like to know if there is a tool in Android Studio that would help me to track the memory used by images and to know which steps of my code are increasinf the most the memory used.
What I don't need
I know how to get information like ActivityManager.getMemoryInfo() or Runtime.getRuntime().totalMemory() but I guess they won't be usefull, right?
Some ideas
I tried to understand the numbers given by "adb shell dumpsys meminfo", but I don't know if that would be a great start...
Use MAT to diagnose memory leaks and other out-of-memory causes:
Android Developers Blog post
Google I|O conference video
My relatively small application for Android with nice graphics that consists mostly of 9patch drawables consumes about 10MB of the memory.
Do you think that it is OK? Or I should optimize it somehow? What is acceptable memory consumption for small applications?
To get approximate per-application memory limit for any device you can use Activity member function
public int getMemoryClass ()
There is a 16/24MB memory limit for application running in android. This thread gives you more info..
This tutorial talks about some good memory management practices..
There is no rule that small app should not take more than x mb memory. The default value of memory allocated by the Dalvik VM for each application is of 16 MB, using the Android 1.6 OS and higher. As long as your app is using memory under this limit, its perfectly fine.
If you really want to optmize your code, always make sure, you don't have any memory leaks in your app, and you are clearing your resources after use. That would only be the trick. :)
10MB has been fine in my experience. The smallest Max Heap Size you are likely to come across is 16MB, and a lot of devices have higher than that now.
I'm not sure why the drawables are taking up so much ram though. Maybe try using a zipaligned APK if you are not already. The export signed APK wizard in eclipse is an easy way of getting one - the development builds are not generally zipaligned.